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

    Scheduled Rules Don't Work With Established Connections

    Scheduled Pinned Locked Moved 2.0-RC Snapshot Feedback and Problems - RETIRED
    9 Posts 4 Posters 2.4k 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.
    • P
      piziks
      last edited by

      Anyone else having problems using scheduled rules? I have set up some rules to block internet access for the early morning. The rules work for any new connection, but for any connection that is already established when the schedule starts, it continues. In particular, any streaming audio connection survives the scheduled internet block, and continues streaming. It appears the state is not reset when the scheduled rules are applied. As a workaround, I have set up a cron job 1 minute after the scheduled rules are applied, with a pfctl -F state. That certainly kills the streaming audio, but it also kills other connections I didn't want killed. Maybe I should look into using pfctl -k …

      Is anyone else having similar problems, and if so, have you found a better workaround?

      I am using 2.0-Beta4 (amd64) Nov 22 snapshot.

      1 Reply Last reply Reply Quote 0
      • D
        danswartz
        last edited by

        As far as I know, this is by design.  Established connections are not affected by rule changes unless you kill the state table as you are doing…

        1 Reply Last reply Reply Quote 0
        • E
          eri--
          last edited by

          Under system->advanced->miscellanous there is
          By default schedules clear the states of existing connections when expiry time has come. This option allows to override this setting by not clearing states for existing connections

          Have you checked that by any chance?

          1 Reply Last reply Reply Quote 0
          • P
            piziks
            last edited by

            No, the check box is not checked.

            1 Reply Last reply Reply Quote 0
            • E
              eri--
              last edited by

              Well can you get copies of /tmp/rules.debug when rule is active and when rule is not?
              Mostly because the schedule is not right!?

              1 Reply Last reply Reply Quote 0
              • P
                piziks
                last edited by

                Here is a diff of the /tmp/rules.debug, just before the schedule kicked in, and during.

                diff rules.debug.before_schedule rules.debug.after_schedule
                237c237
                < # schedule finished -  label "USER_RULE"
                –-

                block  in log  quick  on $LAN  proto { tcp udp }  from  192.168.64.17 to  !192.168.64.1/24  schedule "4cec554a4eae9"  label "USER_RULE"

                1 Reply Last reply Reply Quote 0
                • E
                  eri--
                  last edited by

                  I am sorry but you are missing the point here :).
                  How is pfSense supposed to know what to kill when the schedule becomes active?

                  I would do the other way to get the functionality you want.
                  Create a pass rule for the time you need and then either let the normal policy take place or put the block rule, shown before, just after it.

                  This makes sure the states created by that schedule rule to be cleared otherwise it is not a good idea to drop all connections just because you can.

                  1 Reply Last reply Reply Quote 0
                  • C
                    cmb
                    last edited by

                    If you use pass rules, when they become inactive, the states should be killed. Using block rules with a schedule, existing matching connections aren't killed as there is no reliable way to match in all circumstances. You should use a pass rule on the schedule in that case.

                    1 Reply Last reply Reply Quote 0
                    • P
                      piziks
                      last edited by

                      Thanks to everyone for your help. I have switched the scheduled rules to pass rules instead of blocking rules, and everything works as expected now.

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