pfSense Gold Subscription

Author Topic: Wrong source address used in response to 1:1 NAT packets after 2.0 → 2.3 upgrade  (Read 223 times)

0 Members and 1 Guest are viewing this topic.

Offline slatt

  • Newbie
  • *
  • Posts: 9
  • Karma: +0/-0
    • View Profile
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:
Code: [Select]
# 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.

Offline slatt

  • Newbie
  • *
  • Posts: 9
  • Karma: +0/-0
    • View Profile
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.

Offline jimp

  • Administrator
  • Hero Member
  • *****
  • Posts: 21379
  • Karma: +1432/-26
    • View Profile
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.
Need help fast? Commercial Support!

Co-Author of pfSense: The Definitive Guide. - Check the Doc Wiki for FAQs.

Do not PM for help!

Offline slatt

  • Newbie
  • *
  • Posts: 9
  • Karma: +0/-0
    • View Profile
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.

Offline jimp

  • Administrator
  • Hero Member
  • *****
  • Posts: 21379
  • Karma: +1432/-26
    • View Profile
Add the VIP to localhost, that should be enough to see if it's the same or a similar issue.
Need help fast? Commercial Support!

Co-Author of pfSense: The Definitive Guide. - Check the Doc Wiki for FAQs.

Do not PM for help!

Offline slatt

  • Newbie
  • *
  • Posts: 9
  • Karma: +0/-0
    • View Profile
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?

Offline jimp

  • Administrator
  • Hero Member
  • *****
  • Posts: 21379
  • Karma: +1432/-26
    • View Profile
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.
Need help fast? Commercial Support!

Co-Author of pfSense: The Definitive Guide. - Check the Doc Wiki for FAQs.

Do not PM for help!

Offline slatt

  • Newbie
  • *
  • Posts: 9
  • Karma: +0/-0
    • View Profile
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 :)