TCP:S vs TCP:FA
-
Hello,
I have whitelisted Google IP addresses with Alias List but sometimes the rules forced with the default deny rule with protocol TCP-Fa and it blocks also. I see that TCP-S everytime bi allowed. What is exactly the TCP-S and TCP-fa and how can completely allow Google IP addresses?
-
TCP:RA = RST, ACK
TCP:FA = FIN, ACK
TCP:PA = PSH, ACK
TCP:S = SYN
TCP:SEC = SYN, ECE, CWRhttps://docs.netgate.com/pfsense/en/latest/firewall/troubleshooting-blocked-log-entries-for-legitimate-connection-packets.html
This is likely due to a TCP FIN packet arriving after the connection’s state has been removed
out of state packets are always blocked -
@kiokoman how can i solve this problem sos that IP not be blocked because i have whitelisted it?
This happened after i have reset the states on pfsense. Do i need to reboot the client maybe?
-
did you read the link ?
This happens because on occasion a packet will be lost, and the retransmits will be blocked because the firewall has already closed the connection.
It is harmless, and does not indicate an actual blocked connection
-
@kiokoman ok i understand now. It is harmless and the connection will not be blocked. But because this logs at this manner not so important are, how can i hide this logs?
-
If your seeing a ton of these all the time... You have something going on.. Best to look into why that is happening vs just not logging it.
Do you see a flood of these now and then.. Or is your log full of them all the time?
Looks like to me, there was a syn for the connection.. And then after that a flood of FA for the same connection.. Same source and port.. BTW there is little reason to hide rfc1918 space, those 192.168 addresses
Out of state can be a indication of asymmetrical traffic flow.. Or a network with lots of packet loss, or loss in 1 direction.
To answer your question directly, but I would suggest you investigate before going this route is to turn off the block default deny option.. And then set a block rule that only logs SYN packets at the bottom of your rule set... This will remove the logs of out of state blocks from the default deny. But new traffic that is syn, and not allowed by above rules would not be logged.
I do this on my wan, because I don't need to see all the udp blocks, and or odd out of state blocks inbound to the wan.. I only interested in seeing new unsolicited traffic to my wan..
On my lan side interfaces, I only want to log what I want to log - no need to see all the default denies. Unless troubleshooting something.. Which if needed its a simple checkbox to toggle.
-
@erbalo said in TCP:S vs TCP:FA:
This happened after i have reset the states on pfsense
that's pretty normal if it's after a state reset, his log will certainly be full of it
-
@erbalo said in TCP:S vs TCP:FA:
This happened after i have reset the states on pfsense
As @kiokoman has correctly stated, if your resetting the states on pfsense.. Then yeah for a bit you will see a flood of these sorts of out of state blocks..
It's odd that your just seeing FA, maybe you didn't post section with just the A that are blocked. If you reset states you should see a bunch of A, and then sure some FA, and then maybe even a RA.. As the client says WTF why isn't this guy answer me.. And sends retrans, and says ok lets close this connection and start over..
-
I thing the logs settings which you have done should be ok for me if i can only see the S flags if that is the legit and working logs are.
See my screenshots;
-
Do i just need to set a rule on any interface and also on the WAN interface?
-
Soruce:any and Destination:any and then block?
-
And then at the bottom of the rules and tick Logs?
-
Which flags do i need to tick here? Set /out of and SYN?
-
And lastly here do i need to untick log packets?
-
-
@johnpoz Thats right i have checked my logs and there are lot of logs with FA / A etc.. and i see very low S flags.
-
Before you turn off logging of this noise.. You shouldn't be seeing them - it points to a problem that should be fixed vs just ignored..
Do these comes in spurts or it just constant flood of them?
-
@johnpoz i will check it 2 days and let you know. 2/3 days before i did changed some settings on pfsense related pfblocker as dnsbl settings and it happened directly after i reset the states on pfsense. So it happens now every minute 10/20 times.
I would like to solve this problem and what can i check more?
Also by last changing of my settings no more ads blocks by browser but i did checked dns resolver with nslookup but this works well.Maybe that can help to find the problem or from where to startup.
-
@erbalo said in TCP:S vs TCP:FA:
it happened directly after i reset the states on pfsense
Yeah after you do that - sure you could see a flood of out of state traffic. But that flood should of contained Acks, just A not only just FA... But if you were seeing both A and FA.. it could of just been the flood you would see after a reset of all states on the firewall.
-
@johnpoz I am just seeing A , FA, FPA, RA, PA
I have checked if there a S was but on the last 1000 entries o don't see any S flags.. What will be next and is it dangerous i mean is it a DDOS attack or something like that? I hope you can help me to solve this problem.
-
@erbalo said in TCP:S vs TCP:FA:
I have checked if there a S was but on the last 1000 entries o don't see any S flags
Currently your seeing them? You reset the states again? If not then you have asymmetrical traffic flow most likely...
-
Yes, currenty i am seeing them except S flags also after resetting states again.
I checked also NTOP,
IOT Interface:
Lan Interface:
Wan Interface:
Zero dropped packets -
@erbalo said in TCP:S vs TCP:FA:
after resetting states again.
Why are you resetting states.. There is almost never reason to do that.. If your creating a rule and need, just reset the state for the IPs in question of that new rule. And only time you have to reset state on a new rules, is in the case where traffic already there that would match your rule.. Say you want to block port X.. And device A was talking to something already on port X.. You might want to kill that specific state, vs waiting for that session to end or time out so the rule would block new traffic to that port.
IPS dropping shit is not in your firewall log. You would need to look into IPS to why its dropping stuff. If the firewall dropped the packet, it would of never made it to the ips to even look at.
-
@erbalo Can you please advice me to where tick or untick on these settings as your advice. It is now clear by me that these logs what i am seeing there are out of states logs and i don't really to see that, it filling my logs only with full of entries.
-
Oh my gawd... You need to see them because there is something wrong! Why are you resetting states?
We already went over how not to see them..
-
If it is something wrong i have no idea how i can solve this problem. I have followed your advice and NOT already reset the states.
