Firewall states bug?
-
I have installed a PFSense firewall (2.4.5-p1) and am running into a strange and disconcerting issue.
I have four interfaces on the firewall, one for Internet, one for DMZ and two for LAN interfaces (LAN1 and LAN2).
What I am seeing, is that when I open a state (e.g. ICMP) from a LAN1 computer to another computer in LAN2, then the LAN2 computer can all of a sudden respond on the same port type with the same access as it was accessed with. This continues until the state is closed, but reopens when the LAN1 computer again initiates a state through the firewall.
Now, on LAN2, I even created an explicit deny rule and removed all other rules from LAN2. Even in this state, it can respond on the same port type as it was initiated on.
To be clear, LAN1 computer has access (rule) to ping a computer on LAN2, but the LAN2 computer has a deny rule for ping to the entire (or even individual) computer(s) on LAN1. When the computer on LAN1 starts pinging the computer on LAN2, and it starts responding with replies, if I then start a ping from the computer on LAN2 that is being pinged, to the computer that is pinging it, it will respond even though there is a deny rule. If I stop the ping on the computer on LAN1 and on the computer on LAN2, wait for the firewall state to be removed (30 seconds?), then try to ping the computer on LAN1 from the computer on LAN2, it fails, as it should because of the firewall rule blocking it.
Things is disconcerting from a security perspective, because if a computer should be compromised on LAN2, then it would have reverse access to the computer(s) on LAN1 so long as a state exists.
-
I am unable to duplicate what your saying.
I started a constant ping from 192.168.9.100 (lan) to 192.168.3.32 (dmz)
While lan is allowed to talk to dmz, dmz is not allowed to talk to lan.
While 9.100 gets its ping replies. I then on 3.32 tried to ping 9.100, and they all just time out.
You can see that firewall is blocking it
-
Thanks johnpoz.
I was able to isolate this to just ICMP traffic, SMB and others do not create a reverse opening. -
I just used icmp, and was not able to duplicate this.
There should be no reverse opening..
You sure you didn't have a hanging state from before you created the block rule from your lan2?
You do have these networks on different interfaces and or vlans.. Your not just running multiple layer 3 on the same interface?
Also your rules are explicit, your not using sort of ! or negate rules? Be more than happy to try and duplicate exactly what your seeing. But from your description of what was happening, or atleast the way I understood it - I was not able to see such behavior.. And it shouldn't happen..
-
I can't reproduce that here either, but generally speaking it's not a concern. ICMP is stateless. Same with UDP.
If you ping A->B then the target can reply B->A. It's not unheard of for the state to pass that traffic but it's really meaningless to block it. What's the difference? It's still ICMP from A to B and B to A.
Same with UDP. With UDP on A:xxxx -> B:yyyy, a response from B:yyyy back to A:xxxx will be passed whether it comes from the desired service or something else on B. It's still traffic that matches the state.
It's how pretty much any stateful firewall works with stateless protocols.
-
While I concur that icmp is "stateless" pf does track it.. As you can see in the state table..
So you shouldn't be seeing reverse traffic - unless icmp had already been allowed from your vlan to the lan, and still in the state table.
-
Right what I'm saying is that for pf (or any stateful firewall) to track state on stateless protocols, it has to play fast and loose with the concept of what should be allowed in the reverse direction when a state is in the state table for it.
-
Agreed.. So any theories to why we can not reproduce what he stated he was seeing?
My theory is he had "state" lets call it left in pf from before he created the block rule for vlan to talk to lan, and that was what was allowing it.
-
I'm not 100% sure why, could be that I'm on 2.5.0 and he's on 2.4.5-p1, maybe something in pf changed on FreeBSD 12.x that blocks it now.
Or something else in the rules.
Or maybe they have some other path it's taking like one of those hosts is multi-homed and it's not even passing back through the firewall.
-
Don't think its pf 2.5 thing, since I am on 2.4.5p1
But yeah lots of info missing here to guess even.
