Disabling certain traffic (eg. gaming) for X amount of time before enabling?
-
Or, how about this:
- schedule monday- friday 10pm-7pm, leaving only 3 hrs so that they can game
- instead of Pass, i choose Block for the IPs, enable schedule
When you do it that way, pfSense has no way to kill the existing pass states when the block timer fires because they weren't created by the timer rule.
You would also have to deal with midnight-spanning time definitions, which can be a PITA.
When you set a timer on a Pass rule, pfSense knows what states have been created by the rule so when the end of the period comes, pfSense knows which states to kill.
I think. Or at least I think that's how it's supposed to work.
-
Like DoktorNoktor says, it works best if the scheduled rule is a Pass rule.
- Make the schedule for the times you want to allow gaming.
- Add a Pass rule first for the site/s and using the schedule.
- Put a Block rule next for the site/s.
Then when the schedule is in effect the Pass rule is seen first and access is good.
When the schedule is not in effect the pass rule disappears from the rule set, the block rule gets hit and no gaming.
When the system transitions at the end of a schedule period it can easily match any states that are due to the Pass rule, and kill them. This should effectively terminate the game at the scheduled time. -
Or, how about this:
- schedule monday- friday 10pm-7pm, leaving only 3 hrs so that they can game
- instead of Pass, i choose Block for the IPs, enable schedule
When you do it that way, pfSense has no way to kill the existing pass states when the block timer fires because they weren't created by the timer rule.
You would also have to deal with midnight-spanning time definitions, which can be a PITA.
When you set a timer on a Pass rule, pfSense knows what states have been created by the rule so when the end of the period comes, pfSense knows which states to kill.
I think. Or at least I think that's how it's supposed to work.
Dare I say it, Dangling states irrespective of the presence of block rules or not?
-
Dare I say it, Dangling states irrespective of the presence of block rules or not?
Yup. Normal behavior. Use something else if you don't like it.
-
Dare I say it, Dangling states irrespective of the presence of block rules or not?
Yup. Normal behavior. Use something else if you don't like it.
So like the OP has asked, how do you stop traffic upon a schedule when existing states remain after a schedule change, or has a newer version addressed the dangling states issue since these were posted?
https://forum.pfsense.org/index.php?topic=94619.msg525625#msg525625
https://forum.pfsense.org/index.php?topic=93336.msg518375#msg518375
-
You use a scheduled pass rule not a scheduled block rule.
Your first link is not about scheduled rules at all.
-
You use a scheduled pass rule not a scheduled block rule.
Your first link is not about scheduled rules at all.
I've tried all methods, ie just a pass over a daytime time period, and a pass over a daytime time period with block schedules on the same day before the pass rule with an accompanying block rule after the pass on the same day.
Its like I say here https://forum.pfsense.org/index.php?topic=94619.msg525660#msg525660
You even admit yourself in the post from the same thread https://forum.pfsense.org/index.php?topic=94619.msg525688#msg525688
Everyone knows deleting/changing rules doesn't kill existing states. Not a bug.
The scheduler changing rules wont kill existing states, unless this has now been fixed?
-
Yeah. Deleting/changing rules is not a schedule firing that kills a pass rule.
Just made an ssh pass rule for 17:00 to 17:15 from LAN to a specific host.
SSH'd in:
The rule that triggered this action is:
@200(1438819160) pass in log quick on em0_vlan223 inet proto tcp from 192.168.223.0/24 to 172.22.81.8 port = 22 flags S/SA keep state label "USER_RULE: Testing a schedule rule"
Here's the state pair:
LAN tcp 172.22.81.8:22 <- 192.168.223.6:63082 ESTABLISHED:ESTABLISHED
COLOVPN tcp 192.168.223.6:63082 -> 172.22.81.8:22 ESTABLISHED:ESTABLISHEDAfter 17:15:
$ Write failed: Broken pipe
State killed. Automatically.
Note that none of the OTHER ssh sessions from the same host to the same host were killed. ONLY the one created by the scheduled rule. ssh sessions to that host stay up for days. All the keepalives work.
This was on 2.2.4. To my knowledge it has behaved this way forever.
-
This was on 2.2.4. To my knowledge it has behaved this way forever.
I'll give this another test s I'd like to use this feature, and post back the results. :)
-
Well tested it so far with 2.2.3 and its killing off the internal interfaces states in effect working as I'd expected it to work doing the same youtube test as before, but as I write its still not killed off the WAN interface established states some 20mins later with Firewall Optimization Options set to normal.
If you have a fixed IP, I wonder if these wan side states will ever get killed off?
I know those on a variable ip will get killed when the ISP forces a new IP address, but how will the fixed IP established:established states work if they have scheduled vpn connection between sites? Will we see a build up of established:established states or will they eventually disappear?
Edit. The wan side established state to youtube got killed off after 25mins, so google/youtube keep their states open for 25mins, but the vpn situ will be an interesting test.
