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

    Dangling states problem

    Scheduled Pinned Locked Moved Firewalling
    5 Posts 3 Posters 940 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.
    • A
      AmbrSb
      last edited by

      pf consults its states table before the rule set. So even after adding a rule to block certain connections, the ones that have a corresponding entry in the state table will continue uninterrupted.

      Correct me if I am wrong, but it seems that pf does not have any built-in/native mechanism to automatically terminate states that go against the current rule set.

      Sifting through the states and manually "pfctl -k"ing unwanted states does not look like a sustainable solution to this problem.

      I am writing a python script to automate this process, as much as possible.

      Do you know any other projects aiming at this?

      Is there anything on the roadmap for the pf project to address this issue?

      Are there any major road blocks to implementing this directly in pf?

      Can someone please shed more light on this.

      Thanks.

      1 Reply Last reply Reply Quote 0
      • M
        mer
        last edited by

        That's pretty much the way a stateful firewall works.  Packet comes in, if it does not match existing state, the rules get evaluated.  If a permit/allow rule is matched, state is created.
        If rules were evaluated before state, state becomes irrelevant and then you are evaluating rules for every single packet, which would be a performance hit.  As it is, evaluating rules for the first packet in a given stream, you take a "hit" for only the first packet, which becomes noise over the life of the stream.

        One can always go to the web interface and reset all states after adding block rules (Diagnostics, States, Reset States).

        1 Reply Last reply Reply Quote 0
        • A
          AmbrSb
          last edited by

          @mer:

          One can always go to the web interface and reset all states after adding block rules (Diagnostics, States, Reset States).

          But wouldn't that kill all legitimate connections, too?
          There are other h.323/ftp/http download connections/etc going on. Flushing the state table will disrupt them too.
          AFAIK, new TCP states are usually added only when seeing S/SA packets, right?

          1 Reply Last reply Reply Quote 0
          • M
            mer
            last edited by

            Yes, that would kill legitimate connections too.
            Technically new states are added on the first packet of any stream that matches a pass rule that says keep state (which is the default).  But for TCP rules, yes, they are added when the S out of the SA flags are set.
            But what you are describing is you already have state established for a stream due to existing pass rules, now you add a block rule that affects only that stream and you want to kill the state for that stream but not others.

            man pfctl looks like it can take a a bunch of different options on the -k and -K commands, so combined with creative use of pfctl -s state -vv and grep/awk/sed you may be able to make it "easy" to kill the states.  I'm guessing (because I'm just a user of pfSense) that something like that could be offered back up to the project for potential inclusion, because when you're adding the block rule you pretty much have both sides of everything needed to kill existing states (at least at a host level).  If you have multiple streams from a single host but you don't want to kill all of them, it becomes a little bit more difficult.

            1 Reply Last reply Reply Quote 0
            • K
              kpa
              last edited by

              Evaluating whether any of the existing states "goes against" the current ruleset is a non-trivial problem. To do so you'd have to simulate the creation of every existing state with rules that are currently loaded. PF was not designed for such use and that's why there are no provisions built-in for that.

              Edit: It also gets very hairy when you have states from rules that are triggered by not just IP header information but also by rate limiting options. PF does not keep track of  (for example) the timing information of packets that created the state.

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