Arch Linux

la_croix

Member

Registered: 2024-01-19

Posts: 4

Wireguard via Network Manager not used by default locally

I use a wireguard VPN to connect my laptop to my home network, both for security on dodgy wifi networks, and to access some services that I self-host.

I have imported a wireguard configuration, with allowed hosts: `0.0.0.0/0` and it _seems_ to work fine (at least, traceroute is different with and without the VPN, so I'm guessing it is routing traffic through it). DNS also goes via the VPN, and works fine, including the the self-hosted stuff on my network.

For information, most of my self-hosted stuff is on 192.18.1.0/24, and the VPN assigns addresses to clients on 192.168.4.0/24 (there is no firewall blocking traffic between these subnets).

The weird bit, is that if I am on a wifi network that assigns IP addresses that do not overlap with my home network subnets (e.g. 10.0.0.0/0), everything works perfectly, I can access my self-hosted stuff, and the public internet. If I am on a network that assigns me an IP address that does overlap with my home network (e.g. 192.168.1.10), I cannot connect to any self-hosted stuff (DNS checks out, but I get no route to host), although connection to the wider internet works fine.

I can only surmise that after getting an IP address from DNS, the wifi network is 'prioritised', and only if the host is not in the subnet used by that wifi network, will it try to route via the VPN. I am not clear on how to configure it such that regardless of your assigned IP address, _all_ traffic needs to go through the VPN, so even if there happens to be a 192.168.1.100 on the wifi network, you should still connect to the 192.168.1.100 that can be reached via the VPN.

I am sure that I am vastly abusing terminology here - I appreciate the patience!

-thc

Member

Registered: 2017-03-15

Posts: 639

Re: Wireguard via Network Manager not used by default locally

[...]_all_ traffic needs to go through the VPN, so even if there happens to be a 192.168.1.100 on the wifi network, you should still connect to the 192.168.1.100 that can be reached via the VPN.

Your laptop in the WiFi abroad gets an IPv4 address (e.g. 192.168.1.243) via DHCP and has to communicate with the WiFi router abroad  (e.g. 192.168.1.1) to reach the internet and your VPN endpoint. Imagine after connecting to your VPN all traffic (including 192.168.1.X) will be routed through your VPN. It will stop working because now the WiFi router abroad is no longer reachable.

AFAIK you can not resolve this by VPN configuration alone.

Use "uncommon" IP number schemes (192.168.0.X, 192.168.1.X and 192.168.2.x are extremely common) for your home network and your VPN transit network. Or use IPv6 for communicating with your home resources.

la_croix

Member

Registered: 2024-01-19

Posts: 4

Re: Wireguard via Network Manager not used by default locally

Interesting. I assumed that all traffic from my laptop would be directed towards the wireguard endpoint (i.e. the external ip address of my home network), and that the router on the wifi network would therefore view it as external traffic. Only after reaching my home network via the wireguard tunnel would it be viewed as local traffic.

If that is not the case, does it mean that VPNs cannot hide the traffic destination from the router, only the actual data transmitted? I was under the impression that when tunnelling all traffic through wireguard, the router on the network only sees my machine communicating with the wireguard endpoint, not any of the ip addresses that it accesses _over_ that wireguard connection.

progandy

Member

Registered: 2012-05-17

Posts: 5,240

Re: Wireguard via Network Manager not used by default locally

By default, the ip address range of your local subnet will not be redirected to the VPN. Everything else is, though and the router does only see the VPN ip in that case.
If your local network and your home network use the same subnet, then those ip addresses will not be routed through the VPN.

You could force it by creating manual routes thar send everything to the VPN except packages destined for the gateway (take care that the gateway address does not shadow an address you want to reach in your home network). You'll have to be careful if there is another ip used for e.g. a captive portal as well.

Another option may be to use network namespaces, but I do not know how to set that up in your scenario.

Changing the subnet for your home network is probably the most robust solution, I think the IPs in the 172.16/12 range like 172.27.0.0/16 are less used in most publicly accessible networks.

Last edited by progandy (2024-04-25 11:49:54)

---

| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

-thc

Member

Registered: 2017-03-15

Posts: 639

Re: Wireguard via Network Manager not used by default locally

Interesting. I assumed that all traffic from my laptop would be directed towards the wireguard endpoint (i.e. the external ip address of my home network), and that the router on the wifi network would therefore view it as external traffic. Only after reaching my home network via the wireguard tunnel would it be viewed as local traffic.

If that is not the case, does it mean that VPNs cannot hide the traffic destination from the router, only the actual data transmitted? I was under the impression that when tunnelling all traffic through wireguard, the router on the network only sees my machine communicating with the wireguard endpoint, not any of the ip addresses that it accesses _over_ that wireguard connection.

Each packet with a non-local destination address will be sent to the tunnel interface (on your laptop), encrypted (inner packet: address headers and payload), packaged as a payload into a local IP packet with the destination address of the (abroad) router and routed as such (outer/tunnel packet). Packets with a local destination address will only be sent though the VPN if the destination address is not reachable (ARP).

After arriving at your VPN endpoint (tunnel packet) it's payload will be decrypted, emerges from the tunnel interface on your endpoint as an IP packet destined to one of your home nodes (inner packet) and will be sent there.