1:1 NAT Can't pass traffic
dg last edited by dg
I am new with pfSense and have a Checkpoint background so that mindset may be throwing me off.
In a test environment (DMZ'd, main firewall handling security, no security wanted on the pfSense at this point) I am trying to set up 1:1 NATs. This is to simulate remote devices at customer sites that are behind extra NATs which have funky configs when being NAT'ed. The pfSense and Test-PC are VMware VMs. Once the current setup is done I might add another pfSense behind the current one to add another level of NATing.
If I have a host on the pfSense LAN side without NAT config it can access hosts beyond the WAN subnet via the WAN IP. If I set up a 1:1 NAT the traffic stops.
Floating Firewall Rules (Protocol is Any, not TCP) Pass all traffic both ways.
WAN Firewall Rules (Protocol is Any, not TCP) Pass all traffic both ways.
LAN Firewall Rules (Protocol is Any, not TCP) Pass all traffic both ways.
1:1 NAT Rules
DHCP is set for 192.168.169.111-119.
My testing is:
- Pinging from the Test-PC to a desktop on the inside (172.20.32.101)
- Pinging from the Test-PC to 126.96.36.199
- Http to a web server inside the main network (172.20.10.10). that reports the IP the client is coming from.
- When Test-PC is set to DHCP it gets 192.168.169.111 and tests successfully. Web server reports 172.20.4.10 (WAN IP).
- When Test-PC is set to a LAN IP that is not part of DHCP nor 1:1 NAT (such as 192.168.169.201) it tests successfully. Web server reports 172.20.4.10 (WAN IP).
- When Test-PC is set to an IP that is listed under the 1:1 NATs all above tests fail. It can still ping the WAN IP (172.20.40.10)
Since tests #1 and #2 pass all my setups in VMware and physical switching/firewalls appear to be correct. Does something else have to be configured so that the pfSense will handle the additional IPs on the WAN interface (ex: 172.20.40.200)?
dg last edited by
As another test, I set Test-PC to 192.168.169.200 (a nat'ed address, so the tests weren't working). I then deleted the NAT for .200, hitting save/apply. Test-PC was still failing. Rebooted the pfSense and once that came back up my pings started working again without doing anything else.
I've also disabled the Floating Rule, no change in test results, even with a reboot.
KOM last edited by
Yeah, your rules need some work. Floating rules are typically used for controlling QoS. Otherwise, you apply rules to the interface that the data enters. Rules for traffic coming from your LAN into the LAN interface should be put on the LAN tab. Also, you shouldn't have a WAN rule that allows all traffic. WAN should be locked down except for NATs.
chpalmer last edited by
You need to research Virtual Addresses. For each one of your port forwards you need a virtual address to match on your WAN.
dg last edited by
Thanks for the responses, problem solved!
Thanks for the info on the Floating Rules. I hoped it could have been used to handle rules for both directions. As I mentioned in the second post it's been disabled.
"Also, you shouldn't have a WAN rule that allows all traffic. WAN should be locked down except for NATs."
Normally I fully agree and that's how our main firewall is set. For this case as I mentioned in the OP security isn't a concern on the pf initially because it is all behind our main firewall. The clock vendor's docs are short on reliable details. Priority is to get full functionality to the NAT'ed clocks then start locking it down.
Virtual IP was the missing link. In the OP I mentioned a Checkpoint mindset might be throwing me off. In CP the Virt IP is made for you when the NAT is assigned. I added the virtual IPs and all tests work now. Thanks!