OPNsense Forum
Archive => 20.1 Legacy Series => Topic started by: pv2b on June 26, 2020, 01:44:44 pm
-
Hello!
I have the following scenario. A firewall with two LAN interfaces, one for printers, and one for the PC LAN.
Printers will be receiving new IP addresses, but some clients are still configured with old IP addresses. For this reason, we want to set up NAT so that if a device on the LAN tries to reach one of the old printer IP's, NAT is used to translate the destination address to the new printer ip.
As such the following 1:1 NAT rule has been created:
Disabled: OFF
Interface: LAN
Type: NAT
External network: <old printer IP>/32
Source/Invert: OFF
Source: LAN net
Destination/Invert: OFF
Destination: Single host or network (<new printer IP>/32)
NAT reflection: <use system default>
This results in the following entry in /tmp/rules.debug:
nat on lagg0 from (lagg0:network) to <new printer IP> -> <old printer IP>/32
But this to me looks like it's backwards somehow... I would expect instead it being old->new? But it doesn't work even if I external network and destination... whatever I do I just get the untranslated packet egressing on WAN (default route) instead...
Am I missing something?
-
I was able to make this scenario work correctly using BINAT, but I'm confused as to why I needed to use BINAT and not just NAT. It's not clear to me what exactly just a 1:1 NAT (not BINAT) does...
-
No, I spoke too soon. BINAT doesn't work properly, because if a client tries to talk to the NEW IP, the ICMP ping responses get translated to have the old IP as its source IP....
So I think I need only NAT in one direction
-
OK, sorry for the forum spam, but I think I figured out what's going on.
"NAT" will not be usedul because it's only doing SOURCE NAT when what I actually want is DESTINATION NAT. (I think?)
BINAT is not neccessary, only DNAT. Which I can do using a PORT FORWARD (a bit misleading name in this case)
But I noticed that in this case, I run into an edge case where I cannot ping both the old IP and the new IP at the same time because both packets belong to the same "state"... so pfsense does not know what to do with the ICMP echo response packets coming from the pinged machine, if bothp ings ar running it doesn't know where to send the responses... so that's why I can't ping both at the same time. I can ping one, or the other. Theoretically I think the same should be true also for UDP. Hopefully, though, TCP only should work for what they need to do in this transition period so this is probably fine.