Scheduled blocks won't work without manual states reset



  • I configured an alias for some devices, then a schedule for said devices.  My rules are (in order from top to bottom) block hosts access using the schedule, then pass hosts traffic using the limiter, then the two default allow and rules.

    When the schedule came today, traffic continued to pass for the blocked hosts.  Once I manually reset states, the block took effect.

    Tonight when the schedule ends, I’ll see if traffic starts passing again.

    What could I be doing wrong?



  • I have asked this question many times and NEVER gotten a response.  I have been using pfSense for 5+ years and this issue has been COMPLETELY ignored.  I have a hard time even finding anyone else that has ever tried the scheduled filter changes.

    I have found that the filter reload process is very unstable.  Once you get everything set, try a reboot.  The schedules should work, but making more than one of two changes to any pfSense configs seems to cause the demise of the scheduling thread and thus, the failure to function.

    I also tried setting a manual cron script to reload the filters one minute after each of my schedule changes, but this causes all sort of issues generally resulting in 30-60 second outages every time the script runs.

    Good Luck.



  • I am having this EXACT same issue.  Basically I turn the internet off for my kids at 10:30.  However, any existing connections will stay open.  For example, if my  son is skyping his girlfriend, skype will continue to work.  If he exists skype, and restarts it however, it will not work.  Would there be some way to cron something that resets the states, or something of that nature?



  • I believe that virtually all pf functions can be used by pfctl.  In fact, I think pfSense is merely a wrapper for the pf commands in BSD unix.

    You might google for pfctl command line examples as I’m pretty sure there is a way to reset the states table from the command line.  This would “clear” any active connections.



  • Thank you.  pfctl -F state did in fact kill it.  I will investigate to see if there is a more granular way to do it.



  • Please check option in setting Settings / Advanced / Miscellaneous: “Schedule States” which was set as the default “clear the states of existing connections when expiry time has come” make sure its not check.

    And do note also block rules does not relates to states. meaning the settings above does not effected if you have block rules in schedule  you just have to add scheduled alllow rule for the states to reset.

    Have mine working effectively without resetting states manually.

    Regards,
    Rocel



  • kryptos,

    That box is not checked in my config.

    My rules are attached.  I know I probably need to post the specifics, but at least you can see the order.  Two on top for blocking based on schedule, two in the middle for allowing but with bandwidth limits, and the two default on bottom.

    Right now for example the schedule should not be running – clients should have access.  But they do not.




  • Despite trying many things, putting rules in various orders, etc., I am wholly unable to get this to work.

    Can anyone offer any other solutions?



  • @kryptos:

    Please check option in setting Settings / Advanced / Miscellaneous: “Schedule States” which was set as the default “clear the states of existing connections when expiry time has come” make sure its not check.

    And do note also block rules does not relates to states. meaning the settings above does not effected if you have block rules in schedule  you just have to add scheduled alllow rule for the states to reset.

    Have mine working effectively without resetting states manually.

    Regards,
    Rocel

    But if I have to have allow rules (instead of block rules), I basically have to allow any, any, but in general I have only very few things allowed at all (most things not available from LAN). How to implement that with scheduled access for some users?

    Edit: I have now an alias for the ports to allow and a scheduled allow rule, let’s see how this works!

    With the block rule and 3 minutes later a “pfcrtl -F state” (via Cron job) these guys managed (with an open browser…) to re-establish states and play on 2 hours after the scheduled block had started…

    EDIT: There was a syntax error in the pfcrtl command that didn’t make it work, with the correct “pfcrtl -F state” it’s definitely GAME OVER; however, all other users get their states killed, too. Only killing states for the respective user(s) with “pfctl -k <ip>” doesn’t do the job…

    PS: Some general remarks by a pro, as usual that general (“You may need to use the -k twice, etc.”) that the NOOB fraction can’t get where they want to without 2 hours of man pages and trial and error and and and…

    https://forum.pfsense.org/index.php?topic=76053.msg418139#msg418139</ip>



  • @tucansam:

    kryptos,

    That box is not checked in my config.

    My rules are attached.  I know I probably need to post the specifics, but at least you can see the order.  Two on top for blocking based on schedule, two in the middle for allowing but with bandwidth limits, and the two default on bottom.

    Right now for example the schedule should not be running – clients should have access.  But they do not.

    Your rules should be fine. what is schedule details?

    What are your goals for this be specific.

    Regards,
    Rocel



  • Specifically:

    I have an alias created called “kids_devices.”  This contains assigned IPs for iPods, Kindles, and other crap devices I wish the kids didn’t have.  Also, the Nintendo Wii, and the family PC.

    I want all of these devices to be limited to 300k down/250k up, except the Wii, at 500k down, 250k up.  That worked until today, when suddenly one of the Kindles was doing 20mbps downstream.  I reset the states table and it went back to being limited.  First problem: my limiter works most of the time, not always.  Why I can’t get it to work 100% of the time is totally beyond me, seems simple enough.

    Anyway, either with the limiter rules as separate rules, or adding them to schedule rules, I want to create schedule that allow “kids_devices” to access the internet from 1200-1500 and 1900-2200 hrs.  I want no internet access for and of those devices outside of these times.

    I’m not sure how many rule sets I need to create (ie one for allow during said times, a separate one for block during opposite times, etc) and what order to put them in.  I’ve tried various combinations of all of it (rules for block, rules for allow, block rules on top in the stack, allow rules on top in the stack, etc) and nothing ever worked (everything was either blocked all the time or allowed all the time).  I guess maybe the simplest would be to create a block rule that blocks “kids_devices”, and under that create an allow rule for the specified times?  Again I have no idea how to do it or what order to use, but everything I’ve tried to this point doesn’t work.

    And resetting my states table has become a daily thing for any number of reasons which seem to break the network, rules are ignored, limits are ignored, etc.

    Which is annoying.



  • What I learned throughout the last weeks: Nobody is interested to make something like this really work. I have a simple block rule for the time, when internet is off-limits. Doesn’t work, as the states stay alive.

    Next I tried a Cron ob to kill the states for the IPs blocked, didn’t work and a Cron job to kill all states doesn’t work, either. Also an eMail report (which basically works via a Cron job) is not working properly. Re-installing the Cron package didn’t change anything. I could try a fresh install, but I don’T have the time.

    Only thing that helps: Filter the states under Diagnostics -> States and kill them.

    Block or allow rules made no difference to me. I have the block rule for the kids very high in the list of firewall rules and subsequently the “allow” rules for all LAN IPs for certain ports.



  • Sad.  I continue to have problems with the limiter, rules, and I’ve given up on schedule times.

    Certainly you and I are not the only ones who would like to use this feature.  Wonder why its not a priority?



  • Best guess: “Repressive parents” are the bad guys in this play, “little children looking for freedom” the good guys?  😉



  • @chemlud:

    Best guess: “Repressive parents” are the bad guys in this play, “little children looking for freedom” the good guys?  😉

    Ha.  Well what about someone who wants to keep an ftp server running on his LAN, but only open it up for WAN access during certain hours?  Or shutdown the internet completely when he’s not home (without powering down the cable modem) to minimize attacks?

    Surely there is more use for these schedules than repressive parents stealing freedom away from their young’ns.  If only the schedules worked….



  • 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<

    You could configure the block rule to start e.g. at 20:59
    At 21:00 you could run the Cron for killing the states and for reporting the states, to see how it works (I have to check if the states killer runs before the eMail Report job, I’ll try this evening).

    😉

    Edit: Work’s fine with the kill and subsequent eMail Report 🙂



  • This is my understanding, which could be wrong.

    Firewall rules only apply to new connections, it would be crazy expensive to check every packet against every rule.

    When a packet comes in on an interface, it firsts checks to see if an existing state exists, which is fast because of hash functions for constant time look ups. If the state does not exist, it then goes to the firewall rules to decide if a state will get created, where it does a linear time check.

    Existing states: O(1)
    New states: O(n)



  • Might be correct, but me as an idi** expects a scheduled block rule to BLOCK EVERYTHING when the schedule is due. So the block rule should kill automatically the respective states (which it is supposed to do in pfSense, as there is an option NOT to kill the states for firewall block rules).

    To me it’s a mystery why my pfSense doesn’t kill the states automatically…



  • Agree.
    Even a cheap TP-Link home router is able to block everything when the schedule is due. There’s a nice option in their firmware’s web interface to do that.



  • I’m dealing with this same issue trying to shut off internet to two IPs on my lan at 11pm through 10am.

    The System/Advanced/Misc check box for “Schedule States” says:

    "By default schedules clear the states of existing connections when the expiration time has come. This option overrides that behavior by not clearing states for existing connections. "
    

    Note that what I’m describing below requires the above checkbox to be UNchecked, which is the default.

    The point is that there actually IS an Automatic reset of the related states from the state table like you (we ) desire, but this state reset only occurs at rule expiration time. This makes sure that any connections that are being allowed by the rule are killed when the rule goes away.

    So the logic we need to use is that the traffic of interest is normally BLOCKED by an always active rule, and during the scheduled interval a preceding rule will ALLOW the traffic.  When the ALLOW rule is active it will allow the packets and prevent the always active Blocking rule from being hit.

    When the scheduled rule expires, the states (any active connections that were being allowed) will be reset and both existing and new connections will be prevented by the always active block rule which is below the scheduled rule.

    When the scheduled rule goes active again at the next scheduled interval start, it will allow connections and not care about the “state of the state table”.

    Seems logical anyway… here’s a screenshot of what I’m about to try(it’s outside the schedule time in this view):
    (Also note that I had IPv6 enabled on the kids dekstops and they could still get to google etc that had an IPv6 site… so turn of ipv6 on the hosts or add duplicate rules for ipv6)



  • “So the logic we need to use is that the traffic of interest is normally BLOCKED by an always active rule, and during the scheduled interval a preceding rule will ALLOW the traffic.”

    Yeah, but with your setup you allow each and everything within the kids hours, I allow only very specific things (http, https, smtps, imaps and very few other ports) and this setup is rather difficult to obtain with your kind of rules, as you would need a rule for every port (or some/ a lot of additional aliases for the IPs/ports allowed…).



  • @chemlud:

    “So the logic we need to use is that the traffic of interest is normally BLOCKED by an always active rule, and during the scheduled interval a preceding rule will ALLOW the traffic.”

    Yeah, but with your setup you allow each and everything within the kids hours, I allow only very specific things (http, https, smtps, imaps and very few other ports) and this setup is rather difficult to obtain with your kind of rules, as you would need a rule for every port (or some/ a lot of additional aliases for the IPs/ports allowed…).

    that’s true, but you must already have the appropriate allow rules as you explain… so just make those scheduled, and follow them with a single block rule… you can block all right? not just block the ports of interest, so you only need the one block rule.



  • But I have very different blocking times for different user groups. I tried it once with your setup, but gave up after some hours and found the solution described above, which works fine for me now… 😉 I still think it’S the better option for complex situations and restrained internet access with a general block rule and isolated services allowed.



  • Now in my Case things are working totally differently

    An Alias called Block_Access with IPs = 192.168.0.12 and 192.168.0.13

    Schedule :  Mon to Sun 6:30 PM to 9:00PM and Mon-Sun 10:00PM to 23:59PM

    FW rule on LAN :  IPV4  block  Source= Single host or Alias = Block_Access

    I get access blocked no issue when clock hits the scheduled time my device can’t do anything; but when block schedule expires my device still stays blocked and never gets access to internet.
    only way so far i have tried is simply disable the rule; as in block there is no state that i need to clear.



  • @jabbasi:

    Now in my Case things are working totally differently

    An Alias called Block_Access with IPs = 192.168.0.12 and 192.168.0.13

    Schedule :  Mon to Sun 6:30 PM to 9:00PM and Mon-Sun 10:00PM to 23:59PM

    FW rule on LAN :  IPV4  block  Source= Single host or Alias = Block_Access

    I get access blocked no issue when clock hits the scheduled time my device can’t do anything; but when block schedule expires my device still stays blocked and never gets access to internet.
    only way so far i have tried is simply disable the rule; as in block there is no state that i need to clear.

    I believe it works better if you create a ‘PASS’ rule with the scheduled time for when you want to ‘ALLOW’ access and also create another ‘BLOCK’ rule for the alias/IP.

    You also need to pay attention to the order of the rules… the ‘BLOCK’ rule needs to be below the scheduled ‘PASS’ rule…



  • The relevant code that kills states when a scheduled rule expires is this pfSense project patch to the FreeBSD pf code: https://github.com/pfsense/FreeBSD-src/commit/49045005c714cd18a0f844d1a70047abaab7523a

    The code keeps track of states that are part of a schedule rule by tagging them as they are created, so it is a trivial matter to remove them when the schedule expires. It seems it would be a bit more complicated to dig through all the states looking for the ones that match a scheduled block. I had hoped to tackle this with a patch; maybe some day.

    Apologies for posting an apology with no action, but I wanted to leave a lasting note here of where the relevant code is so that I or someone else can find it in the future.

    P.S. I am using the “pass rule that expires” work-around to make sure that states get killed when my scheduled reject rule begins.



  • How can I apply the patch?
    My pfsense version is 2.3.2-RELEASE-p1  and use the web interface patches, How much do test, the result is:
    Patch can NOT be applied cleanly (detail)
    Patch can NOT be reverted cleanly (detail)

    /usr/bin/patch –directory=/ -t -p1 -i /var/patches/586c4515ba093.patch --check --forward --ignore-whitespace

    Hmm…  Looks like a unified diff to me…
    The text leading up to this was:

    |From 49045005c714cd18a0f844d1a70047abaab7523a Mon Sep 17 00:00:00 2001
    |From: Renato Botelho
    |Date: Mon, 17 Aug 2015 13:52:56 -0300
    |Subject: [PATCH] Importing pfSense patch schedule_label.RELENG_10.diff
    |
    |–-
    | sbin/pfctl/parse.y        | 44 +++++++++++++++++++++++++++++++++++++++++±-
    | sbin/pfctl/pfctl.c        | 32 ++++++++++++++++++++++++++++++±
    | sys/net/pfvar.h          |  7 +++++++
    | sys/netpfil/pf/pf_ioctl.c | 24 ++++++++++++++++++++++++
    | 4 files changed, 104 insertions(+), 3 deletions(-)
    |
    |diff --git a/sbin/pfctl/parse.y b/sbin/pfctl/parse.y
    |index 2991473…62a78d1 100644
    |— a/sbin/pfctl/parse.y

    +++ b/sbin/pfctl/parse.y

    No file to patch.  Skipping…
    Hunk #1 ignored at 235.
    Hunk #2 ignored at 343.
    Hunk #3 ignored at 446.
    Hunk #4 ignored at 491.
    Hunk #5 ignored at 1913.
    Hunk #6 ignored at 2371.
    Hunk #7 ignored at 3722.
    Hunk #8 ignored at 5123.
    Hunk #9 ignored at 5132.
    Hunk #10 ignored at 5185.
    Hunk #11 ignored at 5196.
    Hunk #12 ignored at 5459.
    Hunk #13 ignored at 6091.
    13 out of 13 hunks ignored while patching sbin/pfctl/parse.y
    Hmm…  The next patch looks like a unified diff to me…
    The text leading up to this was:

    |diff --git a/sbin/pfctl/pfctl.c b/sbin/pfctl/pfctl.c
    |index 64b4a05…1e957f6 100644
    |— a/sbin/pfctl/pfctl.c

    +++ b/sbin/pfctl/pfctl.c

    No file to patch.  Skipping…
    Hunk #1 ignored at 78.
    Hunk #2 ignored at 118.
    Hunk #3 ignored at 656.
    Hunk #4 ignored at 2024.
    Hunk #5 ignored at 2138.
    Hunk #6 ignored at 2352.
    6 out of 6 hunks ignored while patching sbin/pfctl/pfctl.c
    Hmm…  The next patch looks like a unified diff to me…
    The text leading up to this was:

    |diff --git a/sys/net/pfvar.h b/sys/net/pfvar.h
    |index 0b8f0ac…ba8b1d9 100644
    |— a/sys/net/pfvar.h

    +++ b/sys/net/pfvar.h

    No file to patch.  Skipping…
    Hunk #1 ignored at 488.
    Hunk #2 ignored at 1288.
    Hunk #3 ignored at 1373.
    3 out of 3 hunks ignored while patching sys/net/pfvar.h
    Hmm…  The next patch looks like a unified diff to me…
    The text leading up to this was:

    |diff --git a/sys/netpfil/pf/pf_ioctl.c b/sys/netpfil/pf/pf_ioctl.c
    |index 96abf2c…23b9efc 100644
    |— a/sys/netpfil/pf/pf_ioctl.c

    +++ b/sys/netpfil/pf/pf_ioctl.c

    No file to patch.  Skipping…
    Hunk #1 ignored at 1709.
    1 out of 1 hunks ignored while patching sys/netpfil/pf/pf_ioctl.c
    done

    /usr/bin/patch --directory=/ -f -p1 -i /var/patches/586c4515ba093.patch --check --reverse --ignore-whitespace

    Hmm…  Looks like a unified diff to me…
    The text leading up to this was:

    |From 49045005c714cd18a0f844d1a70047abaab7523a Mon Sep 17 00:00:00 2001
    |From: Renato Botelho
    |Date: Mon, 17 Aug 2015 13:52:56 -0300
    |Subject: [PATCH] Importing pfSense patch schedule_label.RELENG_10.diff
    |
    |–-
    | sbin/pfctl/parse.y        | 44 +++++++++++++++++++++++++++++++++++++++++±-
    | sbin/pfctl/pfctl.c        | 32 ++++++++++++++++++++++++++++++±
    | sys/net/pfvar.h          |  7 +++++++
    | sys/netpfil/pf/pf_ioctl.c | 24 ++++++++++++++++++++++++
    | 4 files changed, 104 insertions(+), 3 deletions(-)
    |
    |diff --git a/sbin/pfctl/parse.y b/sbin/pfctl/parse.y
    |index 2991473…62a78d1 100644
    |— a/sbin/pfctl/parse.y

    +++ b/sbin/pfctl/parse.y

    No file to patch.  Skipping…
    Hunk #1 ignored at 235.
    Hunk #2 ignored at 342.
    Hunk #3 ignored at 444.
    Hunk #4 ignored at 489.
    Hunk #5 ignored at 1911.
    Hunk #6 ignored at 2366.
    Hunk #7 ignored at 3710.
    Hunk #8 ignored at 5106.
    Hunk #9 ignored at 5114.
    Hunk #10 ignored at 5165.
    Hunk #11 ignored at 5173.
    Hunk #12 ignored at 5434.
    Hunk #13 ignored at 6065.
    13 out of 13 hunks ignored while patching sbin/pfctl/parse.y
    Hmm…  The next patch looks like a unified diff to me…
    The text leading up to this was:

    |diff --git a/sbin/pfctl/pfctl.c b/sbin/pfctl/pfctl.c
    |index 64b4a05…1e957f6 100644
    |— a/sbin/pfctl/pfctl.c

    +++ b/sbin/pfctl/pfctl.c

    No file to patch.  Skipping…
    Hunk #1 ignored at 78.
    Hunk #2 ignored at 117.
    Hunk #3 ignored at 654.
    Hunk #4 ignored at 2003.
    Hunk #5 ignored at 2117.
    Hunk #6 ignored at 2325.
    6 out of 6 hunks ignored while patching sbin/pfctl/pfctl.c
    Hmm…  The next patch looks like a unified diff to me…
    The text leading up to this was:

    |diff --git a/sys/net/pfvar.h b/sys/net/pfvar.h
    |index 0b8f0ac…ba8b1d9 100644
    |— a/sys/net/pfvar.h

    +++ b/sys/net/pfvar.h

    No file to patch.  Skipping…
    Hunk #1 ignored at 488.
    Hunk #2 ignored at 1287.
    Hunk #3 ignored at 1367.
    3 out of 3 hunks ignored while patching sys/net/pfvar.h
    Hmm…  The next patch looks like a unified diff to me…
    The text leading up to this was:

    |diff --git a/sys/netpfil/pf/pf_ioctl.c b/sys/netpfil/pf/pf_ioctl.c
    |index 96abf2c…23b9efc 100644
    |— a/sys/netpfil/pf/pf_ioctl.c

    +++ b/sys/netpfil/pf/pf_ioctl.c

    No file to patch.  Skipping…
    Hunk #1 ignored at 1709.
    1 out of 1 hunks ignored while patching sys/netpfil/pf/pf_ioctl.c
    done

    Is this solution included in a beta version or binari files compiled?

    Thanks for any help.



  • Sorry to mislead. The link I posted is not a patch to add this feature, it is the CURRENT pfSense code that implements state killing for expiring pass rules.

    The code works by finding states that have been marked by the scheduled pass rule. To implement state killing for scheduled block rules, new code would be needed to find all not marked states that match the block rule, which this code doesn’t do at all.



  • Searching the forum I ran into this thread. Seems my post from this morning relates to this issue.
    In my case even a (UDP) state returns after manual kill of state enabling Skype to keep running. Please have a look at: https://forum.pfsense.org/index.php?topic=125534.0

    Earlier in this thread I read about same issue (Skype keeps running).



  • Good luck, I have been chasing this for months…

    I find the rules work until you modify the schedule portion of the rule… If you manually clear states for the target IP after changing the schedule, they do re-establish, even though people on this forum swear this shouldn’t happen.

    I find the only way to fix is to try to reset all states and if that doesn’t fix, reboot.

    Seems to be something broken with the schedules and how they relate to the rules.



  • So in my hunting it would appear that setting up a schedule with pfsense isn’t very likely to happen? I’m messing with this here at home first, as I have a customer with a similar request. So at home my daughters ipod has become the guinea pig.

    Basically I have created a static mapping for her device. I’ve also created a schedule. I’ve created a block rule for the IP of the ipod, as well as an allow rule, which has the schedule selected. It appears to be working for the most part, however imessage continues to work.

    I downloaded the cron package, and I was going to use the pfctl -F command. Is this going to work, or am I beating a dead horse here with this setup?

    -RYknow



  • I have had hit and miss success with the cron task and filtering Steam.

    My setup is to BLOCK the ALIAS and then place an ALLOW rule with schedule ABOVE the BLOCK rule in the LAN tab.

    The wheels fall off if I modify a schedule. I find clearing states does not work as expected and a full reboot is required to get things back on track after adjusting the schedule.



  • I’ll need to double check how I have things setup.

    I’m wondering if my issue is IPv6 related? Does that make any sense?

    -RYknow



  • Possibly but I have blocked IPv6 on my network.



  • That’s my next step. I’ll just block it and see if it fixes my problem.

    EDIT: IPv6 seems to have been the ticket. Since disabling IPv6 traffic on my network, all the devices are working correctly with the above mentioned schedule.

    -RYknow



  • @-RYknow:

    That’s my next step. I’ll just block it and see if it fixes my problem.

    EDIT: IPv6 seems to have been the ticket. Since disabling IPv6 traffic on my network, all the devices are working correctly with the above mentioned schedule.

    -RYknow

    Have you modified schedules, waited until the next schedule change and found the states remain on some UDP packets?



  • Yes. I was never able to get it to work correctly with the ipod. I ended up just creating the schedule via the unifi software… but I would like to get it sorted at the router level instead.

    -RYknow



  • The thing that surprises me the most is how long this issue has been floating around without being addressed… Surely there would be others who could use this feature?



  • Yeah, you triggered my memory about this and I went and played with it last night… I set an ipod up with just strickly a block rule, (picked block… and chose the IP). and imessage still works… I have I have ipv6 disabled, as I was thinking maybe the traffic was using ipv6… but imessage still works. Very strange.

    -RYknow



  • Yeah, I can get this working on a test laptop reliably with a cron task to kill off states after the schedule expires but it doesn’t work on the existing rules.

    I will delete all the rules and start fresh.


 

© Copyright 2002 - 2018 Rubicon Communications, LLC | Privacy Policy