Wireguard Site to Site problem with clients

[Nemesis8]

Hi!
Wireguard mesh Site to Site connection working ok in all routers



Hope this example clarifies:
R1, R2, R3, all connected as Wireguard mesh.


LAN1 (R1) can ping any R2 or R3 subnet.
LAN2 (R2) can ping any R1 or R3 subnet.
LAN3 (R3) can ping any R1 or R2 subnet.


So far, so good.

>>> Here is the problem:


When a client (outside those buldings) connect with WG VPN to R1, it can ping LAN1 only.

How can I solve this?
I'll appreciate your help!

 

[ZebMcKayhan]

When a client (outside those buldings) connect with WG VPN to R1, it can ping LAN1 only.

How can I solve this?

Doesn't look like any firewall issues for any wgs1 client to be forwarded to any other wgs1 peer:

admin@RT-AX86U_Pro:/tmp/home/root# iptables -nvL WGSF
Chain WGSF (1 references)
 pkts bytes target     prot opt in     out     source        destination
    0     0 ACCEPT     all  --  *      wgs1    0.0.0.0/0        0.0.0.0/0
20209 1583K ACCEPT     all  --  wgs1   *       0.0.0.0/0        0.0.0.0/0

The problem is likely to be found in each other AllowedIPs.

How are your wg ips, lan ips setup on each site?

And what ip is your roaming device connecting to R1?

Site-2-multisite or combined mesh-star quickly gets complicated: https://github.com/ZebMcKayhan/WireguardManager?tab=readme-ov-file#site-2-multisite--mesh

 

[Nemesis8]

Doesn't look like any firewall issues for any wgs1 client to be forwarded to any other wgs1 peer:

admin@RT-AX86U_Pro:/tmp/home/root# iptables -nvL WGSF
Chain WGSF (1 references)
 pkts bytes target     prot opt in     out     source        destination
    0     0 ACCEPT     all  --  *      wgs1    0.0.0.0/0        0.0.0.0/0
20209 1583K ACCEPT     all  --  wgs1   *       0.0.0.0/0        0.0.0.0/0

The problem is likely to be found in each other AllowedIPs.

How are your wg ips, lan ips setup on each site?

And what ip is your roaming device connecting to R1?

Site-2-multisite or combined mesh-star quickly gets complicated: https://github.com/ZebMcKayhan/WireguardManager?tab=readme-ov-file#site-2-multisite--mesh

i be more specific in r1 is the wireguard server wit lan 192.168.1.1
r2 is client with 192.168.2.1
r3 is client with 192.168.3.1
if i connect to r1 with computer or any other device i can acces for example to dvr in r2 and i can acces from all the device in r3, r2 and r1, the problem is if i connect to r1 from out of office in 4g band with android phone i cant reach anything of r2 or r3 only the r1 devices but if i connect the android phone via wifi to r1 i can acces to all again
not pro in this, sorry i try to understand

 

[eibgrad]

Well the one big difference w/ the Android phone over 4G is that the client is using a *public* IP. Do the r2 and r3 networks have 0.0.0.0/0 for Allowed IPs? Or else you may have to NAT access to r2 and r3 from r1 (you usually DON'T NAT w/ site-to-site).

 

[Nemesis8]

Well the one big difference w/ the Android phone over 4G is that the client is using a *public* IP. Do the r2 and r3 networks have 0.0.0.0/0 for Allowed IPs? Or else you may have to NAT access to r2 and r3 from r1 (you usually DON'T NAT w/ site-to-site).

in r2 and r3 i have the options in wg client
Enable nat= no
inbound firewall = allow

 

[eibgrad]

in r2 and r3 i have the options in wg client
Enable nat= no
inbound firewall = allow

Fine. But if access to r2 and r3 is coming via r1, and if r1 is NOT NAT'd, then the public IP of the Android client makes its way to the remote networks of r2 and r3. At that point, the replies to that public IP from r2 and r3 are likely to be routed over the default gateways of r2 and r3 (!), and NOT back over the WG connection to r1 and back up to the Android client. IOW, it *seems* like a routing problem. NAT'ing the r1 connection would force those replies back to r1.

 

[Nemesis8]

Fine. But if access to r2 and r3 is coming via r1, and if r1 is NOT NAT'd, then the public IP of the Android client makes its way to the remote networks of r2 and r3. At that point, the replies to that public IP from r2 and r3 are likely to be routed over the default gateways of r2 and r3 (!), and NOT back over the WG connection to r1 and back up to the Android client. IOW, it *seems* like a routing problem. NAT'ing the r1 connection would force those replies back to r1.

and how i do that?

 

[eibgrad]

I don't use (nor do I even have access to) WG on my AC68U. So I don't know what your GUI options may be. In the case of the OpenVPN client, NAT is a GUI option, and for this very reason. But if this isn't a GUI option w/ WG, you'd have to create the NAT rule yourself w/ a nat-start script.

Something like the following ...

iptables -t nat -I POSTROUTING -o <wg-network-interface> -j MASQUERADE

... where you replace <wg-network-interface> w/ the actual network interface for the WG client as seen from a dump of ifconfig (e.g., wg0).

You could test the command from ssh first, then if it solves the problem, make it persistent w/ a nat-start script.

 

[ZebMcKayhan]

i be more specific in r1 is the wireguard server wit lan 192.168.1.1
r2 is client with 192.168.2.1
r3 is client with 192.168.3.1
if i connect to r1 with computer or any other device i can acces for example to dvr in r2 and i can acces from all the device in r3, r2 and r1, the problem is if i connect to r1 from out of office in 4g band with android phone i cant reach anything of r2 or r3 only the r1 devices but if i connect the android phone via wifi to r1 i can acces to all again
not pro in this, sorry i try to understand

So this is actually a hub-and-spoke (star) topology where r1 is the hub.

Well, one problem is that any roaming wg device will not be on r1 lan. So if you made everyone aware of respective lan only, this will be the outcome. But this is just speculations.

To make it clear, the roaming device ip must be added to r1 VPNDirector on r2 and r3.

It's very hard to figure out without knowing how you set it up. Perhaps you can post a picture of your VPNDirector rules on r2 and r3?

So if your wireguard server ip on r1 is 10.6.0.1, lan is 192.168.1.1/24 and your external connected wg device is 10.6.0.4 you will need to adjust VPNDirector on r2 and r3 to make also destinations 10.6.0.4 to be routed to r1.

Masquerading as @eibgrad proposed is another way to do it but it will likely end up nat to source ip 10.6.0.1 (wg server ip) which may not do what you want if r2 and r3 is not aware or wireguard ip on each site (which it does not have to be for lan-2-lan)

 

[Nemesis8]

So this is actually a hub-and-spoke (star) topology where r1 is the hub.

Well, one problem is that any roaming wg device will not be on r1 lan. So if you made everyone aware of respective lan only, this will be the outcome. But this is just speculations.

To make it clear, the roaming device ip must be added to r1 VPNDirector on r2 and r3.

It's very hard to figure out without knowing how you set it up. Perhaps you can post a picture of your VPNDirector rules on r2 and r3?

So if your wireguard server ip on r1 is 10.6.0.1, lan is 192.168.1.1/24 and your external connected wg device is 10.6.0.4 you will need to adjust VPNDirector on r2 and r3 to make also destinations 10.6.0.4 to be routed to r1.

Masquerading as @eibgrad proposed is another way to do it but it will likely end up nat to source ip 10.6.0.1 (wg server ip) which may not do what you want if r2 and r3 is not aware or wireguard ip on each site (which it does not have to be for lan-2-lan)

Thanks i try

 

[Nemesis8]

Thank you all, the problem is now resolved.

 

[ZebMcKayhan]

Thank you all, the problem is now resolved.

Care to explain what the issue was and how you resolved it?

A picture of your vpndirector rules of r2 and r3 may help others....