Rules + Schedules Ineffective?
-
I'm on 2.1.5 and the issue still persists. At 8pm I want the connections to be passed over to a 2nd vpn since the first vpn gets very slow at night.
It correctly works if I turn a machine on past 8pm, the connection goes through the 2nd vpn. However for computers already on, they don't move over.
Is there a fix without using cron?
-
-
Schedules do work properly with no hassle on 2.2 release.
Thanks pfsense devs :D -
They still don't work quite right for me in 2.2-RELEASE. I set up a schedule for 5pm to 10pm, then created two rules: one passes TCP packets, the other passes UDP packets. Outside the scheduled time the rules don't exist and the default block rule drops packets. When 10pm rolled around, the TCP rule took effect, the TCP states were reset, and further TCP connections were blocked. But the UDP states continued operating and the game the rule was intended to disable continued running.
I ran pfctl -s rules from the console and the pass rules for both TCP and UDP are gone, so it's apparently just that the existing UDP states were not reset when the schedule expired.
-
Updating that I have today moved across to 2.2 and just fixing other minor issues - such as the Console won't display options etc.
I will be watching how the Schedules go especially since I toughened them up via CRON and flushing ALL states after the start time of any set schedule.
Finger's are crossed!!!!
Oz
-
I'm on 2.2.6 and behavior persists with certain state types. I understand the logic behind the handling of states, but the schedule should work.
Have a son who has learned to use betternet vpn, which keeps a state open, unfortunately. In turn, this allows him full internet access after he's supposed to have it.
EDIT:
The bug supposed to address this (will find number and add to this post) seems not to have addressed the issue at all.In System - advanced - misc: (which BTW is a stupid place to bury this option) the option "schedule states" shows an unchecked checkbox by default. According to the explanation:
"By default, when a schedule expires, connections permitted by that schedule are killed. This option overrides that behavior by not clearing states for existing connections"
The default behaviour of schedules should be as explained, but active states remain persistent after schedule block occurs.
Is this a reopen bug issue? I don't think the bug should be closed.
-
pfsense - 2.2.6
I've removed the default allow rule and setup allow rules permitting access.
Works great for all but UDP.
There appears to be no solution so I'm now going to play with placing the default allow back in and utilising the traffic shaper to kill data flow between certain times.
I have my Fingers crossed.If there's a thread that I've missed with a solution (apart from the cron job) please let me know!
Thank you!
-
Has this been fixed or has someone found a reliable work-around?
-
I'm on 2.2.6 and still experiencing this issue.. : https://forum.pfsense.org/index.php?topic=108943.0
Waiting for a solution.. -
Any updates?
I am having an issue using a scheduled block on Steam ports -states not clearing automatically..
-
Could someone please have a look at my LAN rules?
I have Steam ports as an alias ' Steam' on 2x different schedules..
The goal is to block Steam at a scheduled time however, the states do not flush ?
Am I doing something wrong?
-
Anyone? :o
-
Anyone have an update on the UDP states issue?
-
Bump?
-
I'm another parent having this issue. I've set rules up to stop Internet access at 8pm, yet I can still hear my son playing and talking on Skype upstairs until I do a states reset.
-
I just tried it in 2.4 and it seems to work. I created a schedule for when Internet was allowed. Next, a pass rule for one host tied to the schedule, immediately followed by a block rule for that host with no schedule. Works until the time expires and then everything dies.
-
mmm, I'm on 2.3.2, wonder if it's worth an upgrade.
-
Depends on how comfortable you are running beta software.
-
I am still having issues with udp states reestablishing after the schedule expires, even with a cron task to kill the states.. The UDP states continue to reestablish until a 'reset states' is completed.
Any updates on this?
-
Bump
