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


  • LAYER 8 Global Moderator

    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.


  • Banned

    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.


  • Rebel Alliance Developer Netgate

    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


  • LAYER 8 Global Moderator

    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
    shutdown

    The 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:FA

    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: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


  • LAYER 8 Global Moderator

    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.


Log in to reply