Automatic outbound NAT rules did not work. Could someone please explain why?
-
Last week i was faced with problem i had never seen before. Neither with monowall nor with pfSense.
I could not explain why this behaviour occured at allThe Task:
There are some subnets wich had to be connected together and a PPTP Remote Access should be possible to this subnets.
The solution:
Remote Access to the networks should be offered using an embedded pfSense (on Alix) with PPTP server active.
Connection between the subnets where made using VLAN routing on a HP switch.The setup:
Do not complain about the IP addresses. The former "project manager" decided to take theese because they "looked" nice! ^^
They used public ip addresses in their private lan!!So far so good - basically it looked like:
VLAN 189
192.190.189.1 192.190.189.254
[INTERNET] <-> [pfSense] <–--------> [HP Switch with VLAN routing enabled]
| | |
| | |
| | +–--- VLAN 190 : 192.190.190/24
| +------- VLAN 191: 192.190.191.0/24
+--------- VLAN 168: 192.168.0.0/24Static routes on pfSense for the VLAN pointing to the HP Switch:
192.190.190.0/24 -> 192.190.189.254
192.190.191.0/24 -> 192.190.189.254
192.168.0.0/24 -> 192.190.189.254The Problem:
Routing between the subnets was ok.
Also accessing pfSense was ok.What did not work was to access anything on the public side of the pfSense from within the 192.190./16 VLANs.
When using tcpdump on the pfSense it looks like there was no NAT done for traffic origination from the 192.190./16 VLANs.
Traffic from 192.168.0.0/24 was NATed correctly.This was quite confusing to me because i alway thought that NAT will happen for any "internal" address,
regardless what ip it will have. As long as routing in the private lan is ok.I only expected real problems when someone from the internal VLAN 190 would try to access the public ip from that range!
We where only able to solve the situation with disabling "Automatic outbound NAT rule generation" and creating explicit rules
for the 192.190/16 VLANS.The Final Question.
Why happended this behavour?
Do i always have to manually create outbound NAT rules for additional subnets on the LAN side of a pfSense configuration?
Is the problem based on the use of public ip addresses on the LAN side? If "Yes" please explain why?
regards
Andi -
This shouldn't happen.
Directly attached or via static route defined subnets should have their traffic NATed to the WAN.But why would you want to NAT your public IPs?
I mean after all they are public :) -
No they are not my public IP.
The former project manager took theese IP for private use, because they looked nice or whatever, without knowing that there are special ip ranges reserved for private use.
So she/he accidenly took the 192.190.190.0/24 range w/o knowing that theese ip are registered to "Westfal Larsen Shipping" (whois 192.190.190.1).
And we could not shift this internal ip ranges to, lets say 192.168.1.0/24, 192.168.2.0/24, … w/o reconfiguring programmable logic contollers for a plant.
But for shure... the current project manager now is aware about the fact that using public IP in private lans could lead to trouble. ;-)
-
Ah.
That would explain it.
Usually when i had public IPs behind my pfSense i enabled AoN to disable outbound NAT.What you describe, sounds like the default behaviour of the automatic NAT is:
NAT all interfaces, either directly connected or defined via a static route to WAN, unless it's a public subnet. Public subnets are routed.At least this would make sense.
If you want to be sure about this, you could try to temporarily add a private subnet to your switch and see if this gets NATed automatically to the WAN.
-
You hit it.
That's what i originally thought when i was faced to this problem. As if the NAT thing would know about "public" ip ranges.
I will try to test this once more.
