Scheduled blocks won't work without manual states reset
-
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! ;)
-
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. :)
Anything new?
-
I tried everything in this thread.
This is still not fixed.
-
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
-
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....
-
and still current on 2.4.4-RELEASE (amd64)
-
Checkout https://forum.netgate.com/topic/134145/blocking-scheduling-not-quite-working/16
-
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.
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.
-
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 rulepfctl -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 -
@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 -
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?
-
This post is deleted! -
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)
