undesired NAT translation over wireguard tunnel
-
I am using pfsense 2.5.2 rc on one side of the tunnel and pfsense plus 21.05 on the other side.
Both are using the wireguard package from netgate package GUI: 0.1.1.
The tunnels are up and I've created gateways and can reach both sides bidirectionally.
The problem is that all of my traffic is coming out of the tunnel with the tunnel address and not the private IP address of the device originating the traffic. Basically it's performing NAT functions which is breaking all the firewall rules on the devices behind the router. I do not have any manually created outgoing NAT rules.
Any idea what's causing this. My openvpn gateways do not have such behavior.
The peer's are set to allow 0.0.0.0/24 and I am using policy based routing.
Tunnel A end 1 is 10.3.102.1/30
Tunnel A end 2 is 10.3.102.2/30172.20.1.3:(Device behind tunnel end 2)#:ping 172.20.0.3
PING 172.20.0.3 (172.20.0.3) 56(84) bytes of data. 64 bytes from 172.20.0.3: icmp_seq=1 ttl=62 time=14.7 ms 64 bytes from 172.20.0.3: icmp_seq=2 ttl=62 time=17.3 ms 64 bytes from 172.20.0.3: icmp_seq=3 ttl=62 time=10.1 ms 64 bytes from 172.20.0.3: icmp_seq=4 ttl=62 time=13.2 ms172.20.0.3:Device behind tunnel end 1)#: tcpdump icmp
00:09:50.407617 IP 10.3.102.2 > server1: ICMP echo request, id 11183, seq 1, length 64 00:09:50.407689 IP server1 > 10.3.102.2: ICMP echo reply, id 11183, seq 1, length 64 00:09:51.412634 IP 10.3.102.2 > server1: ICMP echo request, id 11183, seq 2, length 64 00:09:51.412691 IP server1 > 10.3.102.2: ICMP echo reply, id 11183, seq 2, length 64 00:09:52.411027 IP 10.3.102.2 > server1: ICMP echo request, id 11183, seq 3, length 64 00:09:52.411087 IP server1 > 10.3.102.2: ICMP echo reply, id 11183, seq 3, length 64 00:09:53.411123 IP 10.3.102.2 > server1: ICMP echo request, id 11183, seq 4, length 64 00:09:53.411182 IP server1 > 10.3.102.2: ICMP echo reply, id 11183, seq 4, length 64The speed of wireguard is 2.5x openvpn on an SG-1100 but I can't make it work perfectly yet. Any help appreciated.
-Devan
-
In typical fashion, once I typed out my question I saw the problem "0.0.0.0/0"
For anyone else with this problem:
In contrast to OpenVPN, when I entered the destination networks for each peer in wireguard, the route was not automatically created in the pfsense routing table. That's a good thing since I am using policy based routing. I assumed it would be the same as openvpn.
-
-
I have the same issue. On the remote site the IP hitting the firewall is the tunnel IP of originating site.
Should we adjust the outgoing NAT settings?
edit:
I was tweaking outbound NAT and got it to not translate the LAN ip to tunnel IP for wireguard link.
Make sure no outbound NAT is set on the Wireguard interface.
Create a outbound NAT on WAN (that wireguard uses to connect to remote tunnel) source IP set as subnet of your wireguard network and use interface address. -
Actually I don’t think you even need the wireguard ip subnet in NAT.
I just deleted that NAT and still have connection to peer along with local LAN ip showing on remote site states table. -
@dcgibby looks like you found the fix. You don’t NAT the near side through the WireGuard interface. Set your static routes, set up your policy routing, and PfSense does the rest. I had this issue/misunderstanding early on as well.
-
If you have automatic outbound NAT it adds the wireguard interface and it looks like all “Allowed IPs” entered for peers are included as sources of outbound NAT.
Thus it looks like accessing those remote IPs via wireguard will cause a NAT and stick you with your local wireguard IP as source on remote.So you need to do manual outbound NAT and remove the wireguard interface and “Allowed IPs” from source IP on WAN.
Since the wireguard tunnel is setup over the WAN, I don’t want/need to NAT the peer links over the internal wireguard subnet.
-
@dcgibby my setup is site-to-site so everything in wireguard tunnel is internal.
If you want to access the internet via the wireguard tunnel to remote site, then you would need a proper outbound NAT setup. -
@dcgibby that’s as simple as an outbound NAT rule on the remote WAN interface for your near side LAN subnet. Works like a charm for me for Netflix etc and getting around geo blocks while I travel overseas. I haven’t had automatic NAT rules forever due to all my VPN hocus pocus.
-
@dcgibby said in undesired NAT translation over wireguard tunnel:
So you need to do manual outbound NAT and remove the wireguard interface and “Allowed IPs” from source IP on WAN.
This sounds like a bug since VTI and OpenVPN Do not perform like this. Do you know if there is an issue somewhere to track this?
-
Ahhh! This explains so much!
I had tried to copy my existing rules across from IPSEC tunnels to Wireguard and it just wasn't working like I expected.
I hadn't considered the gateway interface was doing NAT - make sense I guess when you think about it. Switching to Manual Outbound NAT and then disabling the WireGuard interface fixed it.
This really gets pretty messy when you're doing multiple site to site IPSEC migrations to wireguard (I was having poor performance using IPSEC / Starlink for what ever reason - Wireguard just seemed to work)
Can anyone recommend a pfsense / Wireguard guru that would we available to look over a proposed setup and provide best practice? Happy to pay - Id rather do it once correctly than introduce unnecessary workarounds and fixes to get it going. approx 20 sites, DC, Azure (pfsense)