Wrong source address used in response to 1:1 NAT packets after 2.0 → 2.3 upgrade
-
Hello,
I just upgraded a very old pfSense running 2.0 to 2.3.5 and I am running into an issue with the NAT setup.The router is running an OpenVPN client and I have assigned a name to the related interface.
I have a 1:1 NAT rule that redirects traffic sent to this OpenVPN interface to my LAN interface : 10.100.0.0/24 → 172.16.0.0/24. I have not disabled BINAT and I am not using any manual outbound NATs.
I currently do not have any devices connected to the LAN interface but I'm pretty sure I will be able to reach the devices through the VPN using this NAT.However, when I try to reach my pfSense's LAN interface address using this NAT to manage it, it doesn't work. The LAN interface address is 172.16.0.254, so I try to reach 10.100.0.254 through the OpenVPN tunnel and my return packet does not have 10.100.0.254 as source address, it has 172.16.0.254:
# tcpdump -ni ovpnc1 icmp and host 192.168.100.10 18:08:42.431451 IP 192.168.100.10 > 10.100.0.254: ICMP echo request, id 8544, seq 249, length 64 18:08:42.431551 IP 172.16.0.254 > 192.168.100.10: ICMP echo reply, id 8544, seq 249, length 64
When the router was running pfSense 2.0, the ICMP reply had 10.100.0.254 as source address, as expected. Is there a way to restore this behaviour? I've tried changing the NAT mode in advanced settings but so far I have not been able to make this work.
I know I could also reach pfSense's management interface via the OpenVPN address, however it is not static and I can't easily make it static without changing a bunch of other stuff so I'm trying to see if there is a way to restore the old behaviour first.
I hope my explanation is clear enough, feel free to ask me if you need more info.
-
I have been performing more tests, even if I create a Port Forward NAT, it doesn't work, even with NAT reflection.
In the case where I have a device which is connected to the LAN interface and has address 172.16.0.1, I can reach it through the VPN with 10.100.0.1, the NAT is properly applied to the return packet.
-
It sounds like you might be hitting this: https://redmine.pfsense.org/issues/6220
Do you have 10.100.0.254 defined as an IP alias VIP? If not, that should let you reach the firewall.
-
Hi jimp, thanks for the reply.
No, I do not have this address defined as a VIP. I can't add a VIP to my OpenVPN interface so should I try adding it to my LAN interface?
Also, the linked issue states that "portforwarding/outgoing nat rules" rules can work but I tried that and the return packet still had the wrong source address.
Do you know why my rule would work when reaching a device on the LAN but not on pfSense's LAN address itself? I have also tried using a /32 NAT but I encountered the same problem.
-
Add the VIP to localhost, that should be enough to see if it's the same or a similar issue.
-
Add the VIP to localhost, that should be enough to see if it's the same or a similar issue.
This worked, thanks!
Is there anything that can be done to have this bug fixed? -
I'm not sure on that. It's something that changed at the OS level in FreeBSD 10.x and later.
Since the workaround is fairly easy by adding a VIP, and the problem appears to be quite deep in the OS/pf, the benefits of fixing it haven't yet outweighed the amount of effort it would take to solve.
-
Yeah, the workaround is quite easy but it wasn't the first thing I thought of. I wish it had been mentioned somewhere, not sure where though…
Anyway, thanks for your help :)