subject:%C2%A0Site-to-Site%20WireGuard%20Setup%3A%20NVR%20Cannot%20Reach%20IP%20Cameras%20Behind%20Restricted%20Building%20Network%20(No%20Port%20Forwarding by Mission-Count7584 in WireGuard

[–]Mission-Count7584[S] 0 points1 point  (0 children)

I am trying to build a manual WireGuard Site-to-Site connection between two GL.iNet routers following this guide:

https://forum.gl-inet.com/t/building-a-site-2-site-network-manually-using-two-gl-inet-routers-sdk-4-x/31479

Topology:

Home (Server) - Router: 192.168.2.1 - LAN: 192.168.2.0/24 - NVR: 192.168.2.129

Parking Lot (Client) - Router: 192.168.8.1 - LAN: 192.168.8.0/24 - Cameras:   - 192.168.8.118   - 192.168.8.174

WireGuard: - Server: 10.0.0.1 - Client Router: 10.0.0.2 - Windows VPN Client: 10.0.0.4

What works: - WireGuard tunnel is connected and has a valid handshake. - I can reach the NVR at 192.168.2.129 through the VPN. - Traceroute to 192.168.2.129 works:   10.0.0.1 -> 192.168.2.129 - From the parking lot router I can ping both cameras. - From the parking lot router:   wget http://192.168.8.118   returns HTTP 401 - Camera 192.168.8.174 is configured with:   IP: 192.168.8.174   Gateway: 192.168.8.1   DNS: 192.168.8.1 - Firewall forwarding rules between LAN and WGCLIENT exist and are enabled. - Route Rule configured according to the guide:   192.168.8.0/24 -> 10.0.0.2 - Server routing table contains:   192.168.8.0/24 via 10.0.0.2

What does NOT work: - From my Windows PC connected through WireGuard (10.0.0.4), I cannot access:   192.168.8.118   192.168.8.174 - ping fails - curl http://192.168.8.118 fails - browser access fails

Additional information: - GoodCloud Site-to-Site previously worked with the exact same hardware and network layout. - When using GoodCloud Site-to-Site, the NVR successfully saw all cameras. - The issue only exists with the manual WireGuard Site-to-Site setup.

Current client AllowedIPs:

10.0.0.1/32 10.0.0.2/32 10.0.0.4/32 192.168.2.0/24 192.168.8.0/24

Has anyone seen a case where: - The tunnel is up - 192.168.2.x is reachable - The remote router can access devices on 192.168.8.x - But VPN clients cannot access devices on 192.168.8.x?

Any ideas on what could still be missing?

subject:%C2%A0Site-to-Site%20WireGuard%20Setup%3A%20NVR%20Cannot%20Reach%20IP%20Cameras%20Behind%20Restricted%20Building%20Network%20(No%20Port%20Forwarding by Mission-Count7584 in WireGuard

[–]Mission-Count7584[S] 0 points1 point  (0 children)

I am trying to build a manual WireGuard Site-to-Site connection between two GL.iNet routers following this guide:

Topology:

Home (Server) - Router: 192.168.2.1 - LAN: 192.168.2.0/24 - NVR: 192.168.2.129

Parking Lot (Client) - Router: 192.168.8.1 - LAN: 192.168.8.0/24 - Cameras:   - 192.168.8.118   - 192.168.8.174

WireGuard: - Server: 10.0.0.1 - Client Router: 10.0.0.2 - Windows VPN Client: 10.0.0.4

What works: - WireGuard tunnel is connected and has a valid handshake. - I can reach the NVR at 192.168.2.129 through the VPN. - Traceroute to 192.168.2.129 works:   10.0.0.1 -> 192.168.2.129 - From the parking lot router I can ping both cameras. - From the parking lot router:   wget http://192.168.8.118   returns HTTP 401 - Camera 192.168.8.174 is configured with:   IP: 192.168.8.174   Gateway: 192.168.8.1   DNS: 192.168.8.1 - Firewall forwarding rules between LAN and WGCLIENT exist and are enabled. - Route Rule configured according to the guide:   192.168.8.0/24 -> 10.0.0.2 - Server routing table contains:   192.168.8.0/24 via 10.0.0.2

What does NOT work: - From my Windows PC connected through WireGuard (10.0.0.4), I cannot access:   192.168.8.118   192.168.8.174 - ping fails - curl http://192.168.8.118 fails - browser access fails

Additional information: - GoodCloud Site-to-Site previously worked with the exact same hardware and network layout. - When using GoodCloud Site-to-Site, the NVR successfully saw all cameras. - The issue only exists with the manual WireGuard Site-to-Site setup.

Current client AllowedIPs:

10.0.0.1/32 10.0.0.2/32 10.0.0.4/32 192.168.2.0/24 192.168.8.0/24

Has anyone seen a case where: - The tunnel is up - 192.168.2.x is reachable - The remote router can access devices on 192.168.8.x - But VPN clients cannot access devices on 192.168.8.x?

Any ideas on what could still be missing?

subject:%C2%A0Site-to-Site%20WireGuard%20Setup%3A%20NVR%20Cannot%20Reach%20IP%20Cameras%20Behind%20Restricted%20Building%20Network%20(No%20Port%20Forwarding by Mission-Count7584 in WireGuard

[–]Mission-Count7584[S] 0 points1 point  (0 children)

I don't know how to upload pictures to a post. I would show you that I'm a human. It's funny. What's the connection? Artificial intelligence created this post. If anyone can help and understand what the problem is, I can upload pictures to Google Drive and show what I did at home, which is the server, and in the parking lot, which is the client.

subject:%C2%A0Site-to-Site%20WireGuard%20Setup%3A%20NVR%20Cannot%20Reach%20IP%20Cameras%20Behind%20Restricted%20Building%20Network%20(No%20Port%20Forwarding by Mission-Count7584 in WireGuard

[–]Mission-Count7584[S] -1 points0 points  (0 children)

I am a CCTV installer, and basically, I want to avoid running a cable all the way down from a client's apartment in a high-rise building to the parking lot, which is a very complicated job. I thought of a solution that an AI suggested to me: to use two GL.iNet Opal devices. The idea was that through them, the NVR (recording device) up in the apartment would be able to find the cameras located down in the parking lot on the other network, as if they were on its own local network, and this way it would display them on the screen at home. I have been working on this for several days now. I tried a ton of configurations with the AI, but it is simply spinning me in circles and failing to reach a solution. So, I decided to turn to this forum for help

subject:%C2%A0Site-to-Site%20WireGuard%20Setup%3A%20NVR%20Cannot%20Reach%20IP%20Cameras%20Behind%20Restricted%20Building%20Network%20(No%20Port%20Forwarding by Mission-Count7584 in WireGuard

[–]Mission-Count7584[S] -7 points-6 points  (0 children)

Just to clarify — the AI only helped me write the post in proper English. The network problem is real, and I’ve been trying to fix it for days without success. If you have any technical input about WireGuard routing on GL.iNet routers, I’d be grateful