Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Late ACKs from torn-down HTTP connections

    Scheduled Pinned Locked Moved Firewalling
    6 Posts 2 Posters 2.8k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • R
      rcarr
      last edited by

      I noticed several entries like this in /var/log/filter.log:

      000077 rule 69/0(match): block in on fxp0: 209.85.171.165.80 > x.x.x.x.54337: F 0:0(0) ack 1 win 8190
      7. 971085 rule 69/0(match): block in on fxp0: 66.102.7.104.80 > x.x.x.x.53173: F 0:0(0) ack 1 win 8190

      grep 'fxp0..80.: F' /var/log/filter.log | wc -l
            20

      I think these are related to late ACKs – mostly from torn-down HTTP connections.  PF (and IPF) sometimes expire connections faster than the other end can tear them down, resulting in erroneous block msgs which clutter the logs.

      A long time ago, this was related to a known problem with IPF state code.

      http://www.sigmasoft.com/~openbsd/archive/openbsd-misc/199912/msg00906.html

      I remember PF having the same issue when PF first came out.  Maybe PF still has the issue.  (SonicWall firewalls have a similar problem -- except that they send irritating e-mails accusing you of trying to hax0r them whenever this event occurs.)

      As the above post suggests, it's easily solved with:

      block in    quick on $wan inet proto tcp from any port = 80 to any port > 1023 flags F/F
      block in    quick on $wan inet proto tcp from any port = 80 to any port > 1023 flags R/R

      However, the pfsense WebGUI doesn't let you create rules which refer to specific flags.

      Are these two rules candidates for inclusion into the default pfsense config?  Or perhaps a future version of the GUI could allow us to reference TCP flags?

      1 Reply Last reply Reply Quote 0
      • S
        sullrich
        last edited by

        Try a recent RELENG_1_2 snapshot which has the tcp.established timeout parameter fixed.  You might be able to up this value a bit.

        1 Reply Last reply Reply Quote 0
        • R
          rcarr
          last edited by

          I just noticed RELENG_1 snapshots seem to have been deprecated.  Should we start moving to 1_2?

          1 Reply Last reply Reply Quote 0
          • S
            sullrich
            last edited by

            Yep.

            1 Reply Last reply Reply Quote 0
            • R
              rcarr
              last edited by

              How/where do I access the tcp.established timeout parm?  Is it "State Timeout in seconds" in the Advanced Options of any rule?

              1 Reply Last reply Reply Quote 0
              • S
                sullrich
                last edited by

                @rcarr:

                How/where do I access the tcp.established timeout parm?  Is it "State Timeout in seconds" in the Advanced Options of any rule?

                Yep, that's the one.

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post
                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.