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

    Scheduled blocks won't work without manual states reset

    Firewalling
    25
    71
    21.5k
    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.
    • F
      flaux
      last edited by

      I tried everything in this thread.

      This is still not fixed.

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

        I have a combo solution which works well (so far). Set your schedules for allowing instead of blocking with scheduled cron jobs (example: /usr/bin/nice -n20 /sbin/pfctl -k 192.168.1.10) for flushing states, say in every 60min, followed by a blocking rule.

        this is how my rules look like on the LAN interface

        0_1527596799306_kids.JPG

        1 Reply Last reply Reply Quote 0
        • I
          ipfftw
          last edited by

          Wow this new forums software is horrible. Doesn't work right with noscript at all, and i had to switch to chrome (Spew)....

          that said, i have stumbled upon this "bug" and am obviously trying to do the same thing as you all. I noticed that my schedule was applying, and new connections are being filtered, but if a user has a voice channel open (Discord i think), then the connection is not terminated till i do a full state reset.

          Sorry that i dont have anything new to add except that pfsense should fix this OBVIOUS BUG....

          1 Reply Last reply Reply Quote 0
          • SLIMaxPowerS
            SLIMaxPower
            last edited by

            and still current on 2.4.4-RELEASE (amd64)

            1 Reply Last reply Reply Quote 0
            • GertjanG
              Gertjan
              last edited by

              Checkout https://forum.netgate.com/topic/134145/blocking-scheduling-not-quite-working/16

              No "help me" PM's please. Use the forum, the community will thank you.
              Edit : and where are the logs ??

              I 1 Reply Last reply Reply Quote 0
              • I
                ipfftw @Gertjan
                last edited by

                Hey mr gertjan, it think you are saying that the command "/sbin/pfctl -K x.x.x.x." should be working but for me it does not work. I used an upper case -K as a switch though. I think because of the nature of this particular connection it stays established somehow. its a voice connection, discord. all other connections terminate fine with the schedule. But the non discord ones are most likely trying to establish new connections that are then blocked by the firewall (web browsing, game setup, etc)

                i was able to download the cron package from the package manager and i was able to run a command at the time of my choosing, but the -K commands do not seem to work.
                The only thing i can do that reliably works is to reboot the firewall :( . as you can imagine this is the nuclear option but what can i say, it does work.

                0_1538145456827_4745a562-0d14-4777-9503-785ec9f61471-image.png

                I dont have the default block or whatever you mention in that post either. Anyways if you can provide a concise description of the exact thing that works i will try it next week. pfctl does not seem to do it by itself.

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

                  A little late but as the threads on this are so old...
                  There is a slightly less nuclear option that seems to work
                  cron this instead, where the bit confined in the braces is the description you gave the allow rule

                  pfctl -k label -k 'USER_RULE: <description>:'
                  

                  eg

                  /usr/local]# pfctl -sr | grep TV | sed -e "s/192.*)/XXXXXXXXXX/" | head -3
                  pass in quick on LAN reply-to (LAN XXXXXXXXXX inet from <TVThings> to any flags S/SA keep state label "USER_RULE: Grownups:"
                  pass in quick on LAN inet6 from <TVThings> to any flags S/SA keep state label "USER_RULE: Grownups:" 
                  block return in quick on LAN reply-to (LAN XXXXXXXXXX inet from <TVThings> to any label "USER_RULE: Oh no bad boys"
                  
                  /usr/local]# pfctl -ss | wc -l ; pfctl -k label -k 'USER_RULE: Grownups:' ; pfctl -ss | wc -l
                       998
                  killed 29 states
                       969
                  
                  
                  S 1 Reply Last reply Reply Quote 1
                  • S
                    securvark @kraduk
                    last edited by

                    @kraduk said in Scheduled blocks won't work without manual states reset:

                    pfctl -k label -k 'USER_RULE: <description>:'

                    Drop the trailing colon, unless you actually have that in your rule description:

                    [2.4.4-RELEASE][admin@localhost]/root: pfctl -k label -k 'USER_RULE: Allowed direct WAN access:'
                    killed 0 states
                    
                    [2.4.4-RELEASE][admin@localhost]/root: pfctl -k label -k 'USER_RULE: Allowed direct WAN access'
                    killed 1 states
                    
                    1 Reply Last reply Reply Quote 1
                    • R
                      regalpaladin
                      last edited by

                      10/29/2020 still broken, tried everything in this entire thread that spans almost 6 fukin years.

                      tried scheduled allow rule, followed by unscheduled block rule, dont work.
                      tried scheduled allow & block rule,
                      unscheduled allow & scheduled block rule still nothing.

                      i have cron jobs with the useless -K option that never does anything. even typing in the command manually in the cmd prompt kills nothing ever.

                      The only way to "automatically" kill states is to setup a timer on your phone to login to the states list, and manually kill each state one by one. Nice. In all my setups when the states are killed they never return so its obviously something wrong with pfsense and how it tries to kill states automatically.

                      what the hell are we supposed to do? how is there no community patch for this yet lol?

                      A 1 Reply Last reply Reply Quote 4
                      • A
                        artgen @regalpaladin
                        last edited by artgen

                        This post is deleted!
                        1 Reply Last reply Reply Quote 0
                        • A
                          artgen
                          last edited by artgen

                          All open states are killed after rule's schedule expiration (ver. 21.02.2) but you have to pay attention to the correct setting:

                          • the option "Do not kill connections when schedule expires" under System/Advanced/Miscellaneous/Schedule must be disabled
                          • states are killed after the expiration only if schedule is set to a pass rule (a block rule works but old states are left open after expiration) and there are no other rules which would allow connections after the rule's expiration (you can use "invert match" checkbox in others)
                          • states are killed only if minutes are aligned to 0-15-30-45 (in the GUI enforced by the dropdown anyway)
                          • you can test if states have been killed correctly only after the mentioned intervals (there seems to be an internal cron job which does the killing at the intervals)
                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post
                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.