Disable TCP:FPA TCP:FA logging
-
How can I disable logging of these useless stateless block messages in the firewall log?
I use pfSense on a fairly busy organizational network, and even with 2000 entry capacity, the firewall log ends up being essentially useless because it is just flooded with these pointless block messages. I can only see about 15 minutes of log activity in 2000 lines, and all of it is these messages.
Essentially pfSense is DDOSing its own firewall log, rendering it nonfunctional for the purpose of actually finding and diagnosing problems.
,
This issue has been repeatedly asked about in the forums for years now.
Why isn't there simply an option in the settings:
"Disable all stateless TCP:FA and TCP:FPA firewall block messages as it offers no useful information for logging purposes and floods out other potentially important logging information." -
Are they being blocked by any of the default rules? If so, there's a config option to disable logging for them. Status:system logs: settings
-
Disable the default block rule and create a block rule that only logs SYN blocks.. If you don't like the default log all function.
But to be honest your log should not be full of out of state blocks unless you have some sort of problem with your network (asymmetric routing comes to mind) or you have clients that connect and disconnect all the time without creating new sessions until their old session gets block and falls, wireless devices can do this a lot.
Do you have lots of wireless clients that move to different networks via different SSIDS or something. If you want to get the noise down in your logs - best to look to what is generating the noise and ways to remove the noise vs just not logging the noise. Just because pfsense doesn't log it doesn't it means its not there anyway.
Asymmetric routing can cause huge floods of out of state traffic that would be logged by default block rule.. If that the case removal of the asymmetric routes would remove the noise and your clients would be happier in better functioning network as well.
As to the out of state blocks not providing useful information - just not true this can be very using in seeing spotting problems in the network, why are you seeing so much out of state traffic is what you should be using the log to discover.
-
Well, this depends. If you have tens of mobile phone & co. on your network, it becomes enough of an annoyance to get rid of the logging. They behave completely retarded when switching between wifi and cellular data.
-
Usually it's a sign of a problem, so it's good to be logged, but not always.
Like others have said, make your own rules to block and not log what you don't want to see.
You can make a rule to block TCP and select the flag combination(s) you want handled by the rule in the advanced options.
Or add rules to pass the traffic anyhow. https://doc.pfsense.org/index.php/Asymmetric_Routing_and_Firewall_Rules
-
Agree dok - phones switching from cell to wifi can be completely retarded in what they do for connections and can cause lots of problems with noise in the log.
Which is why asked why its good to look to what is causing the flood, agree with you if its cellphones then yes not logging it might be best option.
-
Yes asymmetric routing is occurring. It was a battle between moving to a very difficult to manage command line driven Cisco 3750 switch for routing/firewalling, or staying with the easy to manage pfSense.
There are asymmetric pfSense routes back for the subnets on the 3750
Network Gateway Interface Description
10.16.0.0/15 HS3750 - 10.0.0.1 LAN to 10.16 and 10.17
10.32.0.0/16 HS3750 - 10.0.0.1 LAN===========================
interface Vlan1
description Building LAN
ip address 10.0.0.1 255.255.0.0
!
interface Vlan20
description Phones
ip address 172.16.1.17 255.255.255.0
!
interface Vlan116
description Network Management
ip address 10.16.0.1 255.255.0.0
!
interface Vlan117
description Wireless Management
ip address 10.17.0.1 255.255.0.0
ip helper-address 10.0.0.10
!
interface Vlan132
description Internal Wireless
ip address 10.32.0.1 255.255.0.0
ip helper-address 10.0.0.10
!
interface Vlan148
description Unrouted Guest Wireless
no ip address
shutdownThe guest wireless is not managed by the 3750, pfSense Interface plugs into it and manages that VLAN directly by itself.
As suggested, I enabled "Bypass firewall rules for traffic on the same interface" but the logging continues.
1000 entries today for TCP:FA
Sep 29 13:10:50 GUESTWIRELESS 10.48.11.186:57164 205.213.114.30:443 cache.google.com TCP:FA
Sep 29 13:10:51 GUESTWIRELESS 10.48.11.186:53111 216.58.216.197:443 ord31s21-in-f5.1e100.net TCP:FA
Sep 29 13:10:51 GUESTWIRELESS 10.48.11.186:45376 205.213.114.27:443 cache.google.com TCP:FA
Sep 29 13:10:51 GUESTWIRELESS 10.48.11.186:44459 206.31.248.33:80 Cannot resolve TCP:FA
Sep 29 13:10:51 GUESTWIRELESS 10.48.11.186:46496 205.213.114.27:80 cache.google.com TCP:FA
Sep 29 13:10:51 GUESTWIRELESS 10.48.11.186:58989 74.125.70.189:443 il-in-f189.1e100.net TCP:FA
Sep 29 13:10:51 GUESTWIRELESS 10.48.11.186:54948 216.239.32.20:443 google.com TCP:FA
Sep 29 13:10:51 GUESTWIRELESS 10.48.11.186:45379 205.213.114.27:443 cache.google.com TCP:FA
Sep 29 13:10:52 GUESTWIRELESS 10.48.11.186:36619 173.194.117.159:443 nrt04s09-in-f31.1e100.net TCP:FA
Sep 29 13:10:54 GUESTWIRELESS 10.48.1.39:50430 216.239.32.20:443 google.com TCP:FA
Sep 29 13:10:54 GUESTWIRELESS 10.48.11.186:37239 74.125.202.95:443 io-in-f95.1e100.net TCP:FATCP:FPA:
Sep 29 16:58:32 GUESTWIRELESS 10.48.16.248:49517 216.58.216.238:443 ord31s22-in-f14.1e100.net TCP:FPA
Sep 29 16:58:32 GUESTWIRELESS 10.48.16.248:49517 216.58.216.238:443 ord31s22-in-f14.1e100.net TCP:FPA
Sep 29 16:58:33 GUESTWIRELESS 10.48.16.248:49517 216.58.216.238:443 ord31s22-in-f14.1e100.net TCP:FPA
Sep 29 16:58:35 GUESTWIRELESS 10.48.16.248:49517 216.58.216.238:443 ord31s22-in-f14.1e100.net TCP:FPA
Sep 29 17:00:04 GUESTWIRELESS 10.48.1.3:42151 74.125.69.95:443 iq-in-f95.1e100.net TCP:FPA
Sep 29 17:00:04 GUESTWIRELESS 10.48.1.3:42151 74.125.69.95:443 iq-in-f95.1e100.net TCP:FPA
Sep 29 17:00:05 GUESTWIRELESS 10.48.1.3:42151 74.125.69.95:443 iq-in-f95.1e100.net TCP:FPA
Sep 29 17:00:13 GUESTWIRELESS 10.48.1.3:42151 74.125.69.95:443 iq-in-f95.1e100.net TCP:FPA
Sep 29 17:00:26 GUESTWIRELESS 10.48.1.3:44097 209.85.146.95:443 Cannot resolve TCP:FPA
Sep 29 17:01:12 GUESTWIRELESS 10.48.16.248:49517 216.58.216.238:443 ord31s22-in-f14.1e100.net TCP:FPA
Sep 29 17:03:37 GUESTWIRELESS 10.48.1.3:42151 74.125.69.95:443 iq-in-f95.1e100.net TCP:FPA
Sep 29 17:05:03 GUESTWIRELESS 10.48.16.248:49517 216.58.216.238:443 ord31s22-in-f14.1e100.net TCP:FPA
Sep 29 17:06:42 GUESTWIRELESS 10.48.1.3:42151 74.125.69.95:443 iq-in-f95.1e100.net TCP:FPA
Sep 29 17:10:12 GUESTWIRELESS 10.48.16.248:49517 216.58.216.238:443 ord31s22-in-f14.1e100.net TCP:FPA
Sep 29 17:18:40 GUESTWIRELESS 10.48.1.3:42151 74.125.69.95:443 iq-in-f95.1e100.net TCP:FPA -
Well why don't just fix your asymmetric routing.. Simple enough to do with a transit network.
Why don't you draw your network - drawing is worth a 1000 words as they say.
