Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login
    Introducing Netgate Nexus: Multi-Instance Management at Your Fingertips.

    Rules not apply immediately

    Scheduled Pinned Locked Moved Firewalling
    11 Posts 6 Posters 4.6k Views 1 Watching
    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 Offline
      anhnv
      last edited by

      Hi every body,

      i just use pfsense few day, i'm current use bridge mode with esxi
      But when i apply change rules, it's not immediately apple with current connect

      Example:
      I connected to VPS with SSH, and apply change block all connect to vps. But i need re-connect again with new windows putty to can't connect to vps. And current session still use normal.

      Sorry my bad english !

      1 Reply Last reply Reply Quote 0
      • DerelictD Offline
        Derelict LAYER 8 Netgate
        last edited by

        Firewall changes do not apply to existing states.  If you want to force such behavior you have to clear the firewall states in question manually.

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

        1 Reply Last reply Reply Quote 0
        • A Offline
          anhnv
          last edited by

          Thanks Derelict,

          So how i can "clear the firewall states in question manually".
          If you can, please show me step by step.
          Thanks you so much

          1 Reply Last reply Reply Quote 0
          • P Offline
            phil.davis
            last edited by

            Diagnostics->States, Reset States tab.

            As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
            If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

            1 Reply Last reply Reply Quote 0
            • A Offline
              anhnv
              last edited by

              Thanks  phil.davis !
              Problem now sloved !

              1 Reply Last reply Reply Quote 0
              • H Offline
                Harvy66
                last edited by

                Don't forget that clearing the states will kill all of the current connections. Users may be interrupted, but they can reconnect.

                1 Reply Last reply Reply Quote 0
                • P Offline
                  phil.davis
                  last edited by

                  It would be nice to have logic built into "pf" so you could tell it "reevaluate all existing states against the just-loaded ruleset and remove any states that would have been blocked if they had started with the just-loaded ruleset".
                  That actually seems a reasonably easily computable thing. I wonder why there is not an option on "pf" when loading a new ruleset, to process state matching to rules and clear states that no longer pass.

                  As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
                  If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

                  1 Reply Last reply Reply Quote 0
                  • J Offline
                    jondoe364
                    last edited by

                    I have a similar issue, but I have relied on a schedule to cut off specified sources on my LAN at 10:00pm.  I want to block Skype after 10:00pm, hence I created a rule on the LAN with a schedule, and I know the rule works as long as a connection attempt is made while the rule is active.  If the source is using Skype while the schedule is set to change from inactive to active, the rule does not block the established connection.  I currently reboot my access point to force the source to reconnect, and the rule blocks since it's a new connection attempt, but it seems silly to have to coordinate so many devices to implement a rule.  Clearing the states makes sense, but I would have to do that manually every day.  Am I missing something here, or will I have to create a cronjob to reset the states, and if so, what would that be, pfctl ?

                    Thank you

                    1 Reply Last reply Reply Quote 0
                    • P Offline
                      phil.davis
                      last edited by

                      As long as it is a pass rule being disabled, then pf knows all the states that match that rule. From the man page:

                      It is also possible to kill states by rule label or state ID. In this mode the first -k argument is used to specify the type of the second argument. The following command would kill all states that have been created from rules carrying the label “foobar”:

                      # pfctl -k label -k foobar

                      pfSense should be able to have a label for each rule, and the code that looks for and processes rule schedule changes every 15 minutes could see what rules are now off-schedule and kill any states that matched those rules.

                      I will not work if implemented the reverse way - e.g. if you normally allow all on LAN but have a "block FaceBook" rule that is active during office hours. The Facebook states currently active at 9am, when the block cuts in, are just states against the "allow all on LAN" rule. So no way to easily select them.

                      But scheduled rules can always be implemented positively - e.g. put a "Facebook allow" rule for evening and early morning, followed by an "always block Facebook" rule that has no schedule.

                      I will have a play some time and see if this would be reasonably easy to implement.

                      As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
                      If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

                      1 Reply Last reply Reply Quote 0
                      • ? This user is from outside of this forum
                        Guest
                        last edited by

                        @jondoe364:

                        …..Am I missing something here, or will I have to create a cronjob to reset the states, and if so, what would that be, pfctl ?

                        Thank you

                        Try this:

                        • Have your scheduled block rule in the LAN firewall rules

                        • Install Cron package

                        • Create a Cron job to be run 1 minute after the block becomes effective with the command:

                        /sbin/pfctl -k >IP on the block list<

                        (afaik the aliases won't work for Cron, so one job for each IP)

                        works for me now:
                        https://forum.pfsense.org/index.php?topic=76053.msg424483#msg424483

                        To monitor the states I also have an eMail Report for the states of the respective IPs, sending the output for the command

                        /sbin/pfctl -ss | grep >IP on the block list<

                        enjoy… ;-)

                        1 Reply Last reply Reply Quote 0
                        • J Offline
                          jondoe364
                          last edited by

                          phil.davis: I had not thought about allowing a rule during specific hours.  I was able to kill the state with a cronjob, but if I change the schedule, I have to change the cronjob time too.  I may try it your way.  It's seems like less work.  Thanks.

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post
                          Copyright 2026 Rubicon Communications LLC (Netgate). All rights reserved.
                          Privacy Policy · Cookie Policy