Private networks and bogons not being blocked?!?!
I'm running PFsense 2.3.4 and just found out that RFC 1918 addresses are not being blocked by the firewall.
I have Block Private Networks selected in my WAN interface config and I can see the associated rules in the Firewall, but I can ping a 10. IP that is being used by my ISP. I can also do web requests on port 80.
WTF? Shouldn't this be blocked?
Is there a major bug here or am I just missing something?
built on Wed May 03 15:13:29 CDT 2017
![Screen Shot 2017-08-22 at 19.47.35.png](/public/imported_attachments/1/Screen Shot 2017-08-22 at 19.47.35.png)
![Screen Shot 2017-08-22 at 19.47.35.png_thumb](/public/imported_attachments/1/Screen Shot 2017-08-22 at 19.47.35.png_thumb)
![Screen Shot 2017-08-22 at 19.47.57.png](/public/imported_attachments/1/Screen Shot 2017-08-22 at 19.47.57.png)
![Screen Shot 2017-08-22 at 19.47.57.png_thumb](/public/imported_attachments/1/Screen Shot 2017-08-22 at 19.47.57.png_thumb)
Those rules block connections inbound from those addresses, not outbound connections to those addresses.
Since inbound connections are blocked anyway, what's the point of these check boxes?
I guess I'll have to add explicit outbound rules?
This became an issue yesterday when I was testing a network config that used 10. net addresses and some of tests that we're deliberately designed to fail resulted in replies from the ISP's equipment. This really confused me for a few minutes.
Okay, to answer my own question, the purpose would be to block access to port forwards and VPNs that are exposed on the outside.
So it appears that the key point that I missed is that PFsense allows packets that are authorized by connections in the state table, even though there are rules that would otherwise block the packet. I'll have to think through the implications of this in my rule design, although at first thought, I don't think it'll change anything.
(more replying to myself)
The more I think about it, having the state table have a higher priority than the rules would pretty much be a requirement of any firewall.
This has been an exercise in clearing a false assumption.