What's new

Wireguard Site-to-Site Complications

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

meat

New Around Here
Hello all! And apologies in advance for the noob question.

I am running Merlin 388.1 on two RT-AX86Us routers with a Wireguard (WG) site-to-site connection established for backups between NAS units. It works great. Configuration as follows:
- WG Server: 10.6.0.1/32, local IPs 172.24.0.X
- WG Peer: 10.6.0.4/32, local IPs 192.168.50.X. WG Allowed IPs (Server): 10.6.0.4/32,192.168.50.0/24

I have a PC on the WG server-side network which I have routed via VPN Director to a third-party VPN provider where I want all of the PC's WAN traffic to go. When this in rule is active, the PC cannot connect to 192.168.50.x.

What am I doing wrong?

(As an aside, I earlier had a non-elegant solution with OpenVPN for site-to-site with two parallel tunnels - each router having an OVPN server - with a rule VPN Director. With WG in site-to-site mode, this does not seem to be possible from the server side.)
 
I have a PC on the WG server-side network which I have routed via VPN Director to a third-party VPN provider where I want all of the PC's WAN traffic to go. When this in rule is active, the PC cannot connect to 192.168.50.x.

What am I doing wrong?
Probably nothing, this is the way it is I believe. Since both vpn connections have their own routing table. You need to get the site2site routing information into the main routing table instead of policy routing table.

If you could change your site2site peer to apply to all traffic instead of selected traffic then it should work but it may not be possible.

It is possible to setup a script that copies the relevant routes to the main routing table but it makes future maintenence more difficult.
 
Probably nothing, this is the way it is I believe. Since both vpn connections have their own routing table. You need to get the site2site routing information into the main routing table instead of policy routing table.

If you could change your site2site peer to apply to all traffic instead of selected traffic then it should work but it may not be possible.

It is possible to setup a script that copies the relevant routes to the main routing table but it makes future maintenence more difficult.
Thanks Zeb! Your observation about the routing table prompted me to have a look: there already is an entry for the site-to-site. So on a whim, I added a rule on the WG server-side router in VPN Director for the offsite 192.168.50.0/24 on the WAN interface. And presto! The PC can access offsite and simultaneously direct "legitimate" WAN traffic via the third-party VPN service.

The situation seems illogical and my solution not elegant, but I am a total noob. Probably a good reason it is the way it is, so I wonder if I am going to run into some issues later.

Thanks again for the help!
 
Last edited:
added a rule on the WG server-side router in VPN Director for the offsite 192.168.50.0/24 on the WAN interface
Good spot! Im doing the same in wgm for similar purpose (YazFi guest routing to vpn).

The problems comes from policy routing in general. The kernel manages and updates the main routing table but any routing table is only destination based. So in order to have different routing based on source adress you will have to use ip rule and point source address to a different routing table (policy routing table). This table are populated by whatever software that created the table. This means it may not be complete and at times it may be out of date.

You can check your policy rules in action by ssh command
Code:
ip rule
where each rule will point to a routing table associated with its selected destinations.
When you know the table number you can check the routing table, ie
Code:
ip route show table 221

So if you have 2 wg clients with 2 different routing table you will most like NOT have client 1 routes in client 2 table as it will create a conflict.

But when we are talking about server routes to clients (or site2site routes) this probably should be added into the main routing table AND be copied over to policy tables, which I thought it was but you just proved it is not.

But your workaround is solid and logical and will continue to work.
 
Thanks again for the help! I am not comfortable in the terminal environment, but can confirm that the WG client routing table for the third-party VPN does NOT contain my WG server site2site. It looks as if all other lines from the main routing table are present, however not entires to do with my WG server (peers included). My VPN Director rule for offsite shows in the "ip rule" response and I can follow now the logic where this refers the routing for the site2site to the main table.

I am so happy to have this solved. The speeds over WG are so much better than OVPN. And I am happy to have dispensed with two parallel tunnels. The only thing I miss now is the possiblity to communicate between WG peers... but that is a topic for another day.
 

Similar threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top