The wireguard client configuration in v3 enables NAT. I found the line in /etc/init.d/wireguard that sets masq ‘1’ in the firewall configuration as a wireguard interface is enabled. It would be nice if this were a configuration option. Don’t most wireguard servers already manage NAT if needed as traffic exits the remote WAN interface?
I confirmed that setting the masq value to 0 in /etc/init.d/wireguard works, so it appears to just be a configuration problem.
Surely GL should know this and not be asking us?
I did a thorough test of firewall settings outlined in this post (note - these tests were done using OpenVPN and not Wireguard):
Quoted from said post: “I noticed that disabling Masquerading on the WAN interface (recommended by Air VPN) appears to fix the IP leaks on boot (ie. before the VPN connects).” Note: GL seems to have now plugged these leaks with an alternative means (don’t know how).
My conclusion “Hopefully the developers will implement these changes as defaults (unless I am missing some reason why not?)”
I use my GL router exclusively to route ALL my traffic (I use wireless only) through a VPN (no internet if VPN drops) and have changed my firewall settings thus:
It’s already set to 1 – hard wired in /etc/init.d/wireguard. This forces NAT to be on. Glitch argues that forcing NAT on is a poor choice as a default. Personally, I don’t care what the default is as long as the configuration scripts are updated to make it a configurable option.
Fair comment about it being configurable (actually it is easy to do in Luci) but since nobody (including GL) has yet explained what it does exactly and the related security implications, then I don’t really agree that this is a “dummies” option that should be accessible in the GUI. And surely the default should be “0”.
Actually it was a VPN provider (more than one) that advised unchecking the Masquerading option.
masq is the standard NAT enable bit. See https://openwrt.org/docs/guide-user/firewall/firewall_configuration. Setting it to 1 on the Wireguard link causes all outbound IPv4 traffic to look as though it is coming from the Wireguard client-side private IP address. Setting it to 0 causes outbound traffic to be routed, coming from the client’s LAN IP addresses.
One argument for keeping 1 as the default and making it an option to set masq to 0 is that with NAT disabled the Wireguard server side must have “allowed ips” properly configured so that traffic is routed back to the client-side LAN.
Let’s not overgeneralize. There are cases where NAT is useful on the Wireguard interface and cases where it is not. That’s why I think you should add a configuration option to the Wireguard setup, find a place to store the choice in the config file, and update the /etc/init.d/wireguard script to use the configured setting instead of forcing masq (NAT) to 1.
To reduce support requests you should probably make the default be 1. This may result in double NAT, but it will work more often.
If masq is disabled (0) then the server end is responsible for setting up routing back to the client subnet. This may be done by setting the allows IPs on the server side. It may also be done by setting up the routing table on the server side. The server might also be responsible for NAT, depending on the addresses being used for the Wireguard interface. I suspect your inability to reach the Internet with masq disabled is due to improper routing setup.
If masq is enabled (1) than all requests coming from the client LAN over Wireguard appear to come from the IP of the Wireguard client interface.
The only change I made on the AR750S was to set uci set firewall.wireguard.masq=‘0’ in /etc/init.d/wireguard.
There are two key steps to make it work:
The client and server LAN IP subnet addresses must be disjoint.
The server’s allowed IPs must list the client’s LAN IP subnet. This adds an entry to the server-side routing table to forward packets back to the client.
In my case the client is an AR750S and the server is a Ubiquiti EdgeRouter. You should be able to get an OpenWRT server to work, too. The client LAN IP subnet has to be different than the server LAN subnet. E.g., 192.168.2.0/24 for the client and 192.168.1.0/24 for the server. On the server, add 192.168.2.0/24 to allowed IPs in the peer wireguard configuration.
On the server side you could check the following:
That the client LAN subnet (e.g. 192.168.2.0/24) is listed in the routing table with the next hop being the wg interface.
Use tcpdump on the server-side wg interface to see what IPs are coming from the client and whether responses are going back. Note that when masq is 1 you will see only the private IP of the client’s wg interface. When masq is 0 you will see client-side LAN IPs. (This is all IPv4.)
Obviously, there are more things you have to get right on the server side when masq is 0. That’s why you are probably better off leaving the default at 1 but making it an option in the wireguard configuration.