Scheduled blocks won't work without manual states reset
-
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. -
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.0Earlier 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
-
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.
-
Did you have any limiters on your rules for the Ipod?
-
I don't have any limiters on the iPod. Initially I was using a schedule I had created. At this point for testing I've gotten rid of the schedule completely, and I'm just using the block rule. When I disable it for any length of time, and re-enable it, the imessage stuff still works.
I'm going to test it some more over the weekend, I moved the ipod block to be the very first rule in the list. See if that makes much of a difference.
-RYknow
-
I am really confused now, I deleted all pass/block rules and now the schedule works on one host but not the other?
I even copied the rule and just changed the alias to suit the new rules…
I'm going to default my router one more time and if that doesn't fix it, I'm going to try another product.
-
I've tried several variations I found online for using a Cron job to kill the states after a rule becomes active and none of them work. The only way to ensure Skype and active game sessions get killed after the scheduled block rules kick in is to manually reset the states in the Diagnostics menu. It's a brand new install.
If someone can suggest the exact spelling with the full path of the Cron job other than what I already tried or maybe a different way other than Cron jobs if there is a way? I've tried the following Cron commands:
/sbin/pfctl -F state
/sbin/pfctl -k >IP on the block list< -
I can confirm:
/sbin/pfctl -F state works sometimes (cron task)
pfctl -F state works sometimes (cron task)/sbin/pfctl -k >IP on the block list<works sometimes="" (cron="" task)<br="">pfctl -k >IP on the block list <works sometimes="" (cron="" task)<br="">Both also seem to work in the Diagnostics/Command Prompt however, nothing reliably clears established UDP states.
After the PASS schedule expires, all states are cleared and then a few (Steam and Teamspeak in my case) immediately re-establish.</works></works>
-
Thanks to alot of my own trial and error I have figured out why it doesn't work for me and how I can make it work.
If I have the schedule block at 10pm at night and schedule the cron job to clear a specific IP states at 10:01pm it doesn't work.
If I change the cron job to run at 1 minute past the hour for every hour, it works!
To confirm the obvious, yes my computer time and pfsense times are correct and i've run the test several times. I've run now at 4pm scheduled block with cron to block at 1 minute past every hour and it worked immediately. I had it try before at 3pm scheduled block with 3:01pm run same cron job. It doesn't work.
So for some reason, cron doesn't recognize the specific hour! It's in 24 hour clock military time. I haven't checked if I can do 12 hour clock time if it's possible. But I obviously have the Cron job programmed correctly and everything else correct as the only difference that makes it work is specify to run the job every hour at 1 minute past the hour, rather than at the specific time. This is not a good solution as it can cause interrupts every hour.
I expect to be the first person to find the solution to this as no one has an answer anywhere I could find. Please prove me wrong and beat me to it.
-
I managed to get cron to work without saying * for the hour. I found out that although the schedule runs at 1800 hours (6pm) I have to schedule Cron to run at 2201 hours for it to think it is 1 minute past the hour. It then successfully runs the cron job 1 minute after the scheduled job and clears the state table. So for Cron to run the job 1 minute after the scheduled rule, I have to actually program Cron to run 4 hours and 1 minute after the scheduled rule.
My question now is why does Cron think it is 2200 hours when it is 1800 hours? In other words, why does Cron think the time is 4 hours ahead of what the schedule does?
-
I managed to get cron to work without saying * for the hour. I found out that although the schedule runs at 1800 hours (6pm) I have to schedule Cron to run at 2201 hours for it to think it is 1 minute past the hour. It then successfully runs the cron job 1 minute after the scheduled job and clears the state table. So for Cron to run the job 1 minute after the scheduled rule, I have to actually program Cron to run 4 hours and 1 minute after the scheduled rule.
My question now is why does Cron think it is 2200 hours when it is 1800 hours? In other words, why does Cron think the time is 4 hours ahead of what the schedule does?
Have you set the timezone correctly? - System/General Setup.
-
I managed to get cron to work without saying * for the hour. I found out that although the schedule runs at 1800 hours (6pm) I have to schedule Cron to run at 2201 hours for it to think it is 1 minute past the hour. It then successfully runs the cron job 1 minute after the scheduled job and clears the state table. So for Cron to run the job 1 minute after the scheduled rule, I have to actually program Cron to run 4 hours and 1 minute after the scheduled rule.
My question now is why does Cron think it is 2200 hours when it is 1800 hours? In other words, why does Cron think the time is 4 hours ahead of what the schedule does?
Have you set the timezone correctly? - System/General Setup.
Yes, the time zone is correct in General setup.
-
I saw another discussion someone wrote to use the following code but it doesn't work for me.
pfctl -k x.x.x.x/24 ; pfctl -k 0.0.0.0/0 -k x.x.x.x/24
I assume if my pfsense box is 192.168.1.1 that the x.x.x.x should be that IP address? Or is there something else I should be doing? That threat is closed to comments or I'd ask there.
-
Since killing the state table by IP, even manually pressing the button, is unreliable and the only method is resetting the entire firewall state table manually, I've set a scheduled reboot using Cron which works perfectly. I know it's not the idea solution rebooting the server every night, but I need results and this is the only reliable method.
/sbin/shutdown -r nowI hope pfsense will have a patch to fix clearing the state tables by ip address.
-
Since killing the state table by IP, even manually pressing the button, is unreliable and the only method is resetting the entire firewall state table manually, I've set a scheduled reboot using Cron which works perfectly. I know it's not the idea solution rebooting the server every night, but I need results and this is the only reliable method.
/sbin/shutdown -r nowI hope pfsense will have a patch to fix clearing the state tables by ip address.
I can't believe we are the only people who want this 'feature', I would expect pfsense to be capable of what the $100 routers seem to do quite well.
-
You are not alone and this is a very old problem on pfsense… only this thread is 3 years old.
In time what you can't fix you learn to live with that or if you can't, then you will try to find a solution that work to your needs.This is how it finally work for my kids, see the attachment:
- allow DHCP only to this VLAN/firewall.
- allow DNS & NTP only to this firewall.
- deny access to this firewall for all client except admin IP...
legend:
inet lucia = Mon-Sun 12:00-12:30 / Mon-Fri 19:00-20:30 / Mon-Sun 14:30-17:00 ( school )
vacanta = every day 06-23 ( no school )
zilnic = every day 06-22:15p.s.
extra cron script to kill states,
don't forget to make the script x
...
15-30 22 * * * root /usr/local/bin/pf_stop_tablete_copii.sh#!/bin/sh /sbin/pfctl -K 192.168.101.111 /sbin/pfctl -K 192.168.101.112
-
@ecfx:
You are not alone and this is a very old problem on pfsense… only this thread is 3 years old.
In time what you can't fix you learn to live with that or if you can't, then you will try to find a solution that work to your needs.This is how it finally work for my kids, see the attachment:
- allow DHCP only to this VLAN/firewall.
- allow DNS & NTP only to this firewall.
- deny access to this firewall for all client except admin IP...
legend:
inet lucia = Mon-Sun 12:00-12:30 / Mon-Fri 19:00-20:30 / Mon-Sun 14:30-17:00 ( school )
vacanta = every day 06-23 ( no school )
zilnic = every day 06-22:15p.s.
extra cron script to kill states,
don't forget to make the script x
...
15-30 22 * * * root /usr/local/bin/pf_stop_tablete_copii.sh#!/bin/sh /sbin/pfctl -K 192.168.101.111 /sbin/pfctl -K 192.168.101.112
Thanks, I'm not sure this all makes sense to me but it looks like an uppercase K where I was using a lowercase k?
Also, to specify allowe DHCP, DNS, NTP only to this firewall, i'm not sure where to set those rules? -
see the attachment.
I have also a DNS server in another lan 192.168.22.16 for kids that filter dns with pihole and forward requests to opendns ( family shield… adult content... ) so I had to allow also open DNS directly just in case my server is offline.
Local DNS/NTP is your LAN interface IP and 127.0.0.1
-
Odd thing, my router didn't reboot tonight at 10:05pm as scheduled (which I put 2:05am because it was working 4 hours in ahead previously). I tried setting the correct time and now it works. It seems to have fixed itself. Very weird but thought I'd share that problem is solved.
Just need to test more with rules to avoid rebooting. -
Have you tried Opnsense? It has the latest BSD.
-
Have you tried Opnsense? It has the latest BSD.
I haven't tried Opnsense, but honestly I just setup pfsense and want to give it a fair shot. I switched from ipfire which was having more problems. pfsense seems much better than ipFire so far, although it has the same challenges with removing states after scheduled blocks without rebooting. The good news is with pfsense I can at least schedule a reboot where ipfire I couldn't do that.
With more time I'll learn more tricks I can share. :)
-
Have you tried Opnsense? It has the latest BSD.
With more time I'll learn more tricks I can share. :)
Looking forward to it as I am almost out of hair! ;)