Enabling Wireguard using wg-quick blocks connections from another subnet

I've managed to set up Wireguard using wg-quick running as a service on Ubuntu 20.04. Wireguard is connected to a VPN service provider and it works just fine. LAN access to and from the Ubuntu machine from other machines on the same subnet (10.0.100.0/24) also works fine when Wireguard is running. However, once Wireguard is brought up (using wg-quick up wg0) connectivity is lost with other subnets.

To elaborate, the other subnet in question is for a different VPN connection used for connections to the LAN through a firewall. The firewall takes care of routing between machines on the LAN in subnet 10.0.100.0/24 and machines on the VPN in subnet 10.88.220.0/24. In the absence of Wireguard, everything works swimmingly and all machines on the LAN can be accessed by a machine on the VPN. But once Wireguard is brought up, that connection disappears.

I've reviewed the man page for wg-quick and have reviewed quite a few posts on how to configure Wireguard but haven't been able to figure out a solution. Amongst the things I've tried were to add the PostUp = ip route add 10.88.220.0/24 dev eth0 to /etc/wireguard/wg0.conf. In reviewing the commands executed by wg-quick, I suspect my issue has something to do with some of the ip commands executed by wg-quick - specifically:

[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0

My understanding is that these commands (in combination with some others) create a separate routing table that points to wg0 as the default, then diverts traffic other than LAN traffic to be routed thought that table. I imagine what is happening is that traffic that is supposed to be going to 10.88.220.0/24 though eth0 is instead being redirected by the rules above to table 81820 and going out on wg0. I also tried adding PostUp = ip route add 10.88.220.0/24 dev eth0 table 51820 just to see if that might work (but understanding that it's not a permanent solution as the number changes from session to session), but perhaps not surprisingly it didn't.

I've tried reviewing the pages for the ip route and ip rule commands, but haven't been able to figure out how to modify or supplement the rules and/or routing tables to re-enable connection between the LAN and the VPN. Any advice or suggestions on how this might be done would be most appreciated.

5

1 Answer

The fix was embarrassingly simple. All I needed to to was to add via [gateway] to the first rule I had tried:

PostUp = ip route add 10.88.220.0/24 dev eth0 via 10.0.100.1

Your Answer

Sign up or log in

Sign up using Google Sign up using Facebook Sign up using Email and Password

Post as a guest

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

You Might Also Like