[solved] Allow rule not working?!
-
Hello,
I'm facing a strange problem (pfSense 2.5.2) and I can't really figure out, what is happening here.
My VLAN20 should have access to everything (for testing). However connections from only one client are caught by the default deny rule all the time. When debugging I also introduced a reject all after the allow all rule (which I would assume should never be reached). However als you can see, the reject all still gets triggered.
Am I stupid? Did I do something obviously wrong? I can't figure this out myself...Ruleset:
Firewall log:
The ruleset seams to be loaded (pfctl -sr excerpt):
pass in quick on igb1.20 inet all flags S/SA keep state label "USER_RULE: Allow access to everything else" pass in quick on igb1.20 inet6 all flags S/SA keep state label "USER_RULE: Allow access to everything else" block return in log quick on igb1.20 inet all label "USER_RULE: test: explicit reject everything else" block return in log quick on igb1.20 inet6 all label "USER_RULE: test: explicit reject everything else" -
@b_chris said in Allow rule not working?!:
My VLAN20 should have access to everything (for testing). However connections from only one client are caught by the default deny rule all the time. When debugging I also introduced a reject all after the allow all rule (which I would assume should never be reached). However als you can see, the reject all still gets triggered.
Am I stupid? Did I do something obviously wrong? I can't figure this out myself...Check the TCP flag. The packets are out of state and therefor not caught be the filter rule.
-
@viragomann
Thanks! Honestly I completely ignored the TCP-Flags and until now I don't have an extended knowledge about them.
Do you know any easy digestible source where I can read about that? I'm not really sure whether the PSH, ACK (that's what the PA means, right?) should not really happen (and the device has some faulty implementation) or if this is some kind of valid special use case. -
I think I found a resource for that: https://docs.netgate.com/pfsense/en/latest/troubleshooting/log-filter-blocked.html
I'll do some reading on this. But seams like pfSense is exactly doing what it should do ;)
-
PA doesn't really mean anything other than just ack other than the PSH flag also set..
Here is some info on the PSH flag
https://packetlife.net/blog/2011/mar/2/tcp-flags-psh-and-urg/The real issue is that as @viragomann has stated is its out of state.. Why that is - could just be that your states have been reset, say on loss of wan pfsense can be set to flush all states. Or if this is wireless and your client moved from say cell to wifi and just trying to use the same connection, etc.
If you see lots of these - or you see them with SA, ie syn,ack - that yeah that could mean you have asymmetrical routing issue..
Could just be your device has not really sent enough data to keep the state open and pfsense has closed it.. If you see these now and then I wouldn't worry about it too much.. Is when you see them all the time, or floods of them then yeah I would look into it. I don't even log such traffic either on my wan or my lan.. I only log stuff that is blocked via SYN blocks.. Out of state traffic now and then can happen with a stateful firewall and devices that try and use the same session even if hasn't sent traffic in ages.. Phones can be horrible at this for example.
-
@b_chris
https://en.wikipedia.org/wiki/Transmission_Control_ProtocolThe filter rules only affects only the initiating SYN packet. If the SYN does not pass pfSense, there is no entry in its state table for that connection and all other regarding packets are blocked anyway.
So seeing this in you filter log can mean, that the SYN packet doesn't pass pfSense (asymmetric routing) or that pfSense removed the alreay the entry from the stat table due to timeout.
-
@johnpoz
Thanks for replying. The WAN connection is stable and the client is wired. But when I think about it, it wouldn't surprise my, if the client is the problem. It also seams to be bit buggy regarding the communication with the DHCPv6 on pfSense.
--> pretty sure the network stack of the client is the problem here. I'll report that to the manufacturer (and probably won't get a reply ;)) -
@viragomann
Thanks for explaining! I'll so some reading. As stated in the other reply, I'm pretty sure, that this client is buggy. Had some network problems with it before (and with no other client in my network)... -
Yeah see my edit..
Lets say for example you had a website in some tab or app in the background, and hasn't done anything in a long time.. And then you bring it to the foreground and it tries to just use the same session even though nothing has been sent in hour or more, etc.. The stateful firewall will close states that have not seen any traffic.
Its not a big deal - since the client upon seeing that session no longer working should open a new session via sending syn, etc. When then the firewall if the traffic is allowed would open a new state for.
Edit: another example of this is say a device coming out of standby or sleep mode.. If it tries to use an old session which the firewall has closed because of no traffic in X amount of time than yeah that would be blocked, and the client would have to open a new connection via sending syn.
-
@johnpoz
I see. That would explain why I don't see any degradation of the function of the client --> it probably just opens a new session and continues.
If I find the time I'll get some traces and have a look at them via wireshark to learn something.Thank you @johnpoz and @viragomann !
-
Why a firewall has to close states.. Is only so many states can ever be open.. Since it uses resources to track these states.. There is many issues where the state is not properly closed via fin or rst, etc. If the firewall never closed these states than at some point you would run out of firewall resources to track them.
Say your pc just losses power, or application bad programming or crash, or say your phone just drops off the wifi.. So tcp has timeouts that will auto close states with no traffic seen on that state after specific amount of time.. These can be edited - but would not suggest you mess with the defaults..
So again - unless you are seeing floods of these, or always seeing SA blocks (major hint of asymmetrical traffic) I wouldn't worry about it too much.
-
It's definitely not a flood of entries.
With the explicit reject rule it was pretty exactly one block an hour as TCP:PA. With the default deny rule it's a burst of the following sequence every hour: 1* TCP:PA, 2* TCP:FA, 8* TCP:FPA.Won't worry anymore about these :) But definitely good to understand, what's causing the messages!
-
@b_chris said in [solved] Allow rule not working?!:
2* TCP:FA, 8* TCP:FPA.
Yeah that would be normal - when the client tries use a session, and the state is closed.. Then it would try and close it via FIN.. I would expect, if it doesn't get an answer to its FIN, that at some point it would send a RST.. Basically saying ok, not sure if your getting my FINs - but I am done with this connection - so if you happen to get this RST you can close the connection ;)
Here is quick image found showing open and close of a tcp connection. You quite often see the FIN,ACK together.. Seems this image also has a typo of massage vs message ;) But it gets the idea across of how a connection is opened, and then closed..
