VPNDirector routing setup to server connections (WGS for example)

[Fynjy9]

Hi everybody.

While setting up AX86U-AX88U site-to-site connection using WigeGuard I have the following problem with the VPNDirector configuration on server side:
Some subset of IP on the wireguard server router (say 172.16.22.50-100) should send all their traffic through wg vpn to client side router (say 192.168.100.1) and after that to its wan (ISP link).
If the goal is opposite (from client router to server router) - no troubles, I just chose in GUI WGC<X>.
But there is no option to choose WGS[server]<X>

Now I've built two tunnels AX86U=>AX88U and reverse AX88U=>AX86U, but it seems like a bit messy solution.

Does anyone have any idea how to implement this?
Or probably better to ask to extend the VPNDirector popup list?

 

[ZebMcKayhan]

If the goal is opposite (from client router to server router) - no troubles, I just chose in GUI WGC<X>.
But there is no option to choose WGS[server]<X>

There are no policy routes for a server instance. Wireguard uses AllowedIPs for routes but these are only destination based. And you cannot put 0.0.0.0/0 (all destinations) on a server peer since some things are missing.
This is all very possibly by doing your own script but then you need to maintain this yourself.

I think your solution with a server and a client on each side is the only way to do this without scripting the rules manually.

 

[Fynjy9]

There are no policy routes for a server instance. Wireguard uses AllowedIPs for routes but these are only destination based. And you cannot put 0.0.0.0/0 (all destinations) on a server peer since some things are missing.
This is all very possibly by doing your own script but then you need to maintain this yourself.

I think your solution with a server and a client on each side is the only way to do this without scripting the rules manually.

Thank you for your time. I've been silent for a year, but now i've turned back to the case.
It's probably OK to have now two tunnels between them, but I found that there is another trouble with part of my description:

Some subset of IP on the wireguard server router (say 172.16.22.50-100) should send all their traffic through wg vpn to client side router (say 192.168.100.1) and after that to its wan (ISP link).

I found that it's not working for subset of IP addresses.
my local network 172.16.72.0/24 and I've expect that traffic from .192 - .199 will be passed to router2 to go to ISP
so
- I've add a rule

- set static IP for the client1 172.16.72.192 (connected by wire)

Unfortunately nothing happen (also tried with empty "Remote IP" - no difference) - traffic still flow to local ISP.
While looking to command "route" output on router1 and client1, and iptables output on router1 - I've got no idea how my local IP subset setup from VPNDirector applied (and how and where it should be applied) to affect the routing for particular subset of IP's


Have you any idea or hint where to dig?

 

[ZebMcKayhan]

Thank you for your time. I've been silent for a year, but now i've turned back to the case.
It's probably OK to have now two tunnels between them, but I found that there is another trouble with part of my description:

I found that it's not working for subset of IP addresses.
my local network 172.16.72.0/24 and I've expect that traffic from .192 - .199 will be passed to router2 to go to ISP
so
- I've add a rule
View attachment 58567
- set static IP for the client1 172.16.72.192 (connected by wire)

Unfortunately nothing happen (also tried with empty "Remote IP" - no difference) - traffic still flow to local ISP.
While looking to command "route" output on router1 and client1, and iptables output on router1 - I've got no idea how my local IP subset setup from VPNDirector applied (and how and where it should be applied) to affect the routing for particular subset of IP's


Have you any idea or hint where to dig?

Look at the routing rules using ssh:

ip rule

Wgc1 uses its own routing table as shown in the previous command, conveniently named wgc1. To check it use

ip route show table wgc1

If you post it here I may be able to help but remove any public ip and such.

 

[ZebMcKayhan]

Note, routing rules are traversed from prio 0 first and upwards. Table local is only addresses destined for the router itself. If a rule is matched the route table appointed will be used. If no routes are found in the routing table the rules will continue to be processed.
In Asus merlin, all route tables will have a default route so a route will always be found in any routing table.

You may end up having problems will reverse path filtering. Since data could be requested one path and replies another. But that would appear as a broken connection...

If you end up with broken connection for these you can loosen the reverse path filtering. But it probably needs to be done on both sides:

echo 2 > /proc/sys/net/ipv4/conf/wgc1/rp_filter
echo 2 > /proc/sys/net/ipv4/conf/wgs1/rp_filter

 

[Fynjy9]

You may end up having problems will reverse path filtering. Since data could be requested one path and replies another. But that would appear as a broken connection...

Seems not that trouble, due
- I'm able to ssh from router1_local_network to router2
- I had test VNC from router1_local_network to router2_local_netwok Mac

agenda:

router1 local address/network 172.16.72.1/24, just one isp - ISP1
router1 guest wifi 192.168.101.0/24
testing machine 172.16.72.192

broot@titanium:/tmp/home/root# netstat -anp tcp | grep :22 | grep .192
tcp        0     64 172.16.72.1:22          172.16.72.192:9924      ESTABLISHED 19504/dropbear

router2 local address/network 192.168.50.1/24, just one isp - ISP2

broot@titanium:/tmp/home/root# ip rule
0:      from all lookup local
90:     from all to 10.6.0.2/24 lookup main
90:     from all to 192.168.50.0/24 lookup main
90:     from all to 10.6.0.3 lookup main
90:     from all to 10.6.0.4 lookup main
90:     from all to 10.6.0.5 lookup main
90:     from all to 10.6.0.6 lookup main
90:     from all to 10.6.0.7 lookup main
90:     from all to 10.6.0.8 lookup main
11210:  from 172.16.72.192/29 lookup wgc1
32766:  from all lookup main
32767:  from all lookup default

seems ok, for all 172.16.72.192/29 table wgc1 applied first

broot@titanium:/tmp/home/root# ip route show table wgc1
default via router1_ISP1_WAN_GW dev eth4
router2_ISP2_public_IP via router1_ISP1_WAN_GW dev eth4
10.7.0.0/16 dev wgc1 scope link
ISP1_mail_addr via router1_ISP1_WAN_GW dev eth4 metric 1
ISP1_WAN_pool/23 dev eth4 proto kernel scope link src router1_ISP1_public_IP
router1_ISP1_WAN_GW dev eth4 proto kernel scope link
ISP1_some_addr via router1_ISP1_WAN_GW dev eth4 metric 1
127.0.0.0/8 dev lo scope link
172.16.72.0/24 dev br0 proto kernel scope link src 172.16.72.1

looking to that
- some of lines quite strange - why they are here
- no idea from my side what will trigger forwarding the packets to router2 to let them out via ISP2
so I've look at

broot@titanium:/tmp/home/root# ip route show table main
default via router1_ISP1_WAN_GW dev eth4
10.6.0.0/24 dev wgs1 proto kernel scope link src 10.6.0.1
10.6.0.3 dev wgs1 scope link
10.6.0.4 dev wgs1 scope link
10.6.0.5 dev wgs1 scope link
10.6.0.6 dev wgs1 scope link
10.6.0.7 dev wgs1 scope link
10.6.0.8 dev wgs1 scope link
10.7.0.1 dev wgc1 scope link
ISP1_mail_addr via router1_ISP1_WAN_GW dev eth4 metric 1
ISP1_WAN_pool/23 dev eth4 proto kernel scope link src router1_ISP1_public_IP
router1_ISP1_WAN_GW dev eth4 proto kernel scope link
ISP1_some_addr via router1_ISP1_WAN_GW dev eth4 metric 1
127.0.0.0/8 dev lo scope link
172.16.72.0/24 dev br0 proto kernel scope link src 172.16.72.1
192.168.50.0/24 dev wgs1 scope link
192.168.101.0/24 dev br1 proto kernel scope link src 192.168.101.1

seems that

default via router1_ISP1_WAN_GW dev eth4
...
ISP1_mail_addr via router1_ISP1_WAN_GW dev eth4 metric 1
ISP1_WAN_pool/23 dev eth4 proto kernel scope link src router1_ISP1_public_IP
router1_ISP1_WAN_GW dev eth4 proto kernel scope link
ISP1_some_addr via router1_ISP1_WAN_GW dev eth4 metric 1
127.0.0.0/8 dev lo scope link
172.16.72.0/24 dev br0 proto kernel scope link src 172.16.72.1

is just copied from table main to table wgc1 and that's an answer for question what for they happen in wgc1 - "just because"

meditation on that give me an idea

probably that's the trouble - Peer Allowed IP not allowed 0.0.0.0 so no packets to internet IP's may be passed via this link

But! I don't want to pass all the traffic though router1->router2->ISP2, just for dedicated IP's

Expirement: add to Server1 Peer Allowed IP everybody -> 192.168.50.1/24,10.7.0.0/16,0.0.0.0/0
- connection to router2 still working
- connections to anything else broken, not reached and so on

may be it's somehow limited on server side (router2 WGS setup)?

here is my traditional stuck
- Server Allowed IP's - it's the list of targets allowed to client to interact? Seems no, elsewise how connection from router1 clients to 192.168.50.1 was established? If so - Client Allowed IP's is the list where Clients allowed to send packets = 0.0.0.0/0 - more that enough to open something like whereismyip.com. (Probably here I'm wrong)

After that I've found on router2 in VPN Director rule to use WGC1 for all targets 172.16.72.0/24 and said "common, it's useless!", drop it... and lost connection to router2

That lead me to think that your guess mentioned by me in the beginning of that reply was partly true - request packets flow via router1_wgc1/router2_wgs1 BUT response packets flow via router2_wgc1/router1_wgs1 based on rule I've removed AND somehow on routers side everything quietly matches

Now I need some time to found a person to restore the rules on router2

Based on that story of studies - may you give me some hint?

 

[Fynjy9]

Now I'm quite close to idea that VPN Director (or any GUI-based setup) is not my case and I should prepare configuration using just one tunnel and scripts upon it.
Or separate tunnels - one for intra-networks communication, and separate for machines "act like residents of another router location"

 

[ZebMcKayhan]

Now I'm quite close to idea that VPN Director (or any GUI-based setup) is not my case and I should prepare configuration using just one tunnel and scripts upon it.
Or separate tunnels - one for intra-networks communication, and separate for machines "act like residents of another router location"

In wgm site-2-site was setup using a server peer on each side. And to route internet data I wrote this as an example of creating your own policy table: https://github.com/ZebMcKayhan/WireguardManager?tab=readme-ov-file#route-site-2-site-internet-access

But if your sole purpose is to join the 2 networks together and don't need roaming peers perhaps you could make a client on each side that connect together? Yes, it works, you could repurpose your server keys and make your client config file and import. Use other site endpointort if possible. If not possible, use whatever and let the other side make the connection.
Wireguard has no such thing as server or client, it's just peers.

 

[ZebMcKayhan]

Server Allowed IP's - it's the list of targets allowed to client to interact? Seems no, elsewise how connection from router1 clients to 192.168.50.1 was established? If so - Client Allowed IP's is the list where Clients allowed to send packets = 0.0.0.0/0 - more that enough to open something like whereismyip.com. (Probably here I'm wrong)

Here is some to read on AllowedIPs: https://www.snbforums.com/threads/question-on-wireguard-tunnel-configuration.89680/post-902916 It is one of the more difficult part to understand, but if a destination is not in allowedIPs it will not be allowed over the tunnel. If you plan on having internet data over the tunnel, it has to be 0.0.0.0/0 on the source side. You will have to work around any consequences.
I think that setting up a client on each sides would be the simplest for you. But you may need to fiddle with dnsmasq if dns is needed.
It will probably be some tinkering but I'm sure you will learn a great deal from it.
I will try to assist when I can.