Filtering out TCP:A, TCP:FPA, etc. packets (again)

[bldnightowl]

Re: TCP:RA/FA/FPA Flooding logs

@johnpoz I've seen your response to this in a bunch of posts, about setting the Advanced flags in a logging rule to only pickup initial SYNs and let all the rest fall through to the default non-logging blocking rule. I can't seem to get that to work:

I still see this rule log things like TCP:A, TCP:RA, TCP:FPA etc.

I think I'm misunderstanding the configuration UI -- do I need to check all of the boxes in the "out of" row to achieve the desired result?

P.S. I'm still not quite sure why I occasionally see so many of these on local subnet outbound traffic. All of my subnets are separate VLANs, and I'm pretty certain there is no asymmetrical routing going on.

[johnpoz]

Where did you place this rule? And did you name the rule? And that is what is being shown in the logs?

Or is default rule still logging?

Here are my logs showing this logging, and its only ever SYN

Here is my wan, and the cleanblock rule and the setting in it.

You would have to make sure default log is off

Or you would have to create your own block rule under the clean block rule that does not log..

[johnpoz]

@bldnightowl said in Filtering out TCP:A, TCP:FPA, etc. packets (again):

I'm still not quite sure why I occasionally see so many of these on local subnet outbound traffic.

The states could of cleared on the firewall - that would be a reason you would see those.. If you have it set to clear states on loss of wan, then yeah you could see a lot of those.

Also phones are horrible at creating them - when they switch from say cell to wifi and don't try and create a new session, etc..

Seeing a few of them now and then no big deal - but if your seeing a lot of them - then something not right. How many do you see, and do they come in bunches? Layout your network - you sure your not asymmetrical? If you have anything downstream doing routing - and devices on your transit network, then yeah that would be asymmetrical

[bldnightowl]

@johnpoz

My rule is the last one on a VLAN local interface.

And I see log messages on this interface that say "Explicitly block and log" -- so it's definitely my rule which is matching.

[johnpoz]

And its logging what exacty? Lets see the log entry.. You sure your rules reloaded? You can view the full set, look at the debug.

https://docs.netgate.com/pfsense/en/latest/firewall/pf-ruleset.html

For example here is my clean block rule

[2.4.5-RELEASE][admin@sg4860.local.lan]/root: pfctl -sr | grep "Clean Block"
block drop in log quick on igb1 reply-to (igb1 64.x.x.x) inet proto tcp from any to 64.x.x.x flags S/S label "USER_RULE: Clean Block"
[2.4.5-RELEASE][admin@sg4860.local.lan]/root: 

You can see the flags set s/s

what pfsense version are you running?

Do you happen to have some rule with the same label in floating?

[bldnightowl]

@johnpoz Unfortunately, I had just reset the firewall logs and will have to wait for the problem to recur. But....thanks for the command-line output tip.

block drop in log quick on mvneta1.35 inet all label "USER_RULE: Explicitly block and log"
block drop in log quick on mvneta1.35 inet6 all label "USER_RULE: Explicitly block and log"

Changing it to TCP only:

block drop in log quick on mvneta1.35 inet proto tcp all flags S/S label "USER_RULE: Explicitly block and log"
block drop in log quick on mvneta1.35 inet6 proto tcp all flags S/S label "USER_RULE: Explicitly block and log"

So to be explicit -- it appears rules which match any protocol disregard TCP flag filters, even when the match is TCP. That's unfortunate -- and if correct, it would be nice if the UI prevented the flag settings from even being available.

[johnpoz]

Well yeah - didn't catch that, if you have it just set for IPv4, then you would not be able to set tcp flags.. So yeah that would explain it.

But now that you have it changed to tcp and flags set you won't see any more non syn blocks - so kind of hard to track down if you are aysmetrical or if it happens when your states are being reset?

You don't have any downstream routers? Then be hard to have asymmetrical traffic.. Unless you have a problem with your vlans and vlan X can talk to say vlan Y without going through pfsense, and then pfsense sees say the syn,ack on vlan Y..

[johnpoz]

@bldnightowl said in Filtering out TCP:A, TCP:FPA, etc. packets (again):

it would be nice if the UI prevented the flag settings from even being available.

You could put that in as a feature request I would think.