Problem with one specific internal network (172.10.y.z/16)
My company uses for years a network 188.8.131.52/16 for the internal Ip address… I know this is not a pool dedicated for LAN, but this will change soon as I setup a Cisco Backbone with multiple networks in /24 from the pool 10.x.y.z.
For the moment, the network 172.10.y.z/16 is connected direcdtly on the lan interface of the PFsense Firewall (1.2.3) and everything works great.
Yesterday, decided to make the network 172.10.y.z/16 to be connected to the backbone and the backbone has a default route to the PFsense firewall. IP of lan PFsense is now in the range 10.x.y.z/24
I also created some static routes on PFsense to allow my new networks 10.x.y.z/24 and the old network 172.10.y.z/16
The 172.10.y.z/16 can communicate with all the 10.x.y.z/24 networks connected to the backbone
All the networks of 10.x.y.z/24 connected to the backbone can communicate with the network 184.108.40.206/16 and they can also co to the internet.
But the network 172.10.y.z can access to the firewall, can ping the Wan IP of the forewall but cannot access to the internet (cannot ping the Wan Gateway). It is blocked.
If I change the PFsense firewall with a Fortigate 60, the network 172.10.y.z/24 can reach the internet
If I change the network 172.10.y.z/16 by 172.176.y.z/16, this network can access to the internet
So, can anyone help me to solve this issue? This is so so strange
The default LAN rule only allows traffic sourced from the LAN subnet, if you haven't changed that you need to.
All my rules are personalised
Non of them are using the "Interface network" parameter.
I always defined the network for each rule.
Are you using manual outbound NAT? If so you need outbound NAT rules for all your internal subnets. If you're using automatic it'll take care of that.
I am using automatic outbound NAT… and it works for all networks, excepted this specific 172.10.y.z/16 network
Here are some updates:
I installed yesterday a second pfSense 1.2.3 server, to check from a clean install.
I allowed all traffic from the LAN and created static routes like this:
- one for the 220.127.116.11/16
- one for the 18.104.22.168/16
- one for the 172.16.0.0/16
On my backbone (layer 3 Cisco C3550-12G, last FW), I create a static route sending all unknow traffic 0.0.0.0 0.0.0.0 to the pfSense and 3 VLAN interfaces:
when I am connected on the 22.214.171.124/16 or the 126.96.36.199/16 VLAN networks, I can access everywhere inside the network, can ping the WAN IP of the pfSense, but cannot go outside (cannot ping my WAN gateway)
when I am connected on the 172.16.0.0/16 VLAN network, I can access everywhere inside the network, can ping the WAN IP of the pfSense and cannot go outside (can ping my WAN gateway or other WAN IP, like the DNS servers of OpenDNS 188.8.131.52, for example)
When I test with same settings but on a Fortigate 60 firewall instead of the pfSense, everything work with all the VLAN networks.
So, it seems pfSense is really the reason of the problem.
Please, let me know if you have a solution.
Next monday, I may try with a pfSense 2.0 to check, but I would prefer stay on a stable release, for safety.
2.0 isn't going to behave any differently, you're missing something in your configuration. Sounds like the routes are fine based on your description, so ensure you're on automatic outbound NAT, and check your rules and firewall logs. Also check states and ensure you're seeing the traffic NATed as well as passed.
If you started on 2.0, there is one difference in it that could be the cause. 184.108.40.206/16 and 220.127.116.11/16 are not within private IP space, and the default automatic outbound NAT only NATs private IP space (in the 172 range that's 172.16.0.0/12). In 1.2.3, all internal networks are NATed by the automatic outbound NAT regardless of whether they're proper private subnets.
Thank you for the info.
All you said is already in my 1.2.3 version
But I suspect that not only 2.0 but also 1.2.3 has the problem you just told regarding the automatic outbound as on the 1.2.3, i reinstalled a clean new server and all works excluding the no-Lan RFC5819 networks
Also, I check in 2.0 and same issue.
I will let you know after I try to create Outbound rule for 18.104.22.168/16 network
Edit: I just tested on my 2.0 by creating the Outbound rule on the Wan for the network 22.214.171.124/16… and no changes to my problem
Regarding the firewall log and the states, nothing regarding requests coming from my client computer (it sends icmp request to the outside) excluding the access to the web interface (as I use it to do the settings on the firewall...)
Hi I found that I have this in my states on the 2.0 when I ping from a computer 126.96.36.199/16 to an OpenDNS server 188.8.131.52:
icmp 184.108.40.206:1 <- 220.127.116.11 0:0
icmp 18.104.22.168:1 -> 22.214.171.124 0:0
But I suspect that not only 2.0 but also 1.2.3 has the problem you just told regarding the automatic outbound as on the 1.2.3
It's not a problem, it's really the best default behavior in 2.0 if people followed the requirements on how to properly address systems. Though I've been debating switching back to 1.2.3's behavior (which definitely NATs all internal networks regardless of whether they're RFC1918) because too many people like you abuse public IP space that should never be used on private networks in this fashion. You really should not do what you're doing, you're going to have connectivity problems to parts of the Internet that your network thinks are local.
If the states you listed in your last post are the only two you have, then you are not NATing traffic from that subnet. All traffic that gets NATed has two states something like this:
icmp 126.96.36.199:12 <- 188.8.131.52 0:0
icmp 184.108.40.206:12 -> x.x.x.x:14287 -> 220.127.116.11 0:0
where x.x.x.x is your real public IP.
In fact, it should be NATed, this is why I am confused
But as I told in the past, I want move everyone in 10.x.y.z networks to have no problem (as I know also the problem using Public IP for internal use…)
I just wanted to make the move to the new network smooth
But as I discussed with my boss, he finally agreed with me to move directly to the new network, so it will not be an issue anymore for us.