Disabling certain traffic (eg. gaming) for X amount of time before enabling?



  • Hey guys,

    Looking for tips on how to throttle/disable certain types of traffic (eg. online gaming/steam) for a specific amount of time before it automatically is re-enabled? Trying to find a way to limit this traffic, while still permitting normal web browsing open, for a certain timeframe during the day and have it automatically disable this rule after a certain time. Want to ensure kids are not playing games during study time, without affecting overall web browsing (so that they can still research online). Is this possible within pfSense? If so, what would be the cleanest/effective way to set this up?

    Thank you!



  • Once you have a way to identify the traffic (Alias XYZ of IP addresses or …) then make a schedule for the time you would like to allow the access.
    Then make rules on LAN:

    1. Pass traffic with destination XYZ alias and select the schedule you created.
    2. As the next rule after the pass, Block all with destination XYZ.

    Doing it this way makes it easy for pfSense to stop the access at the scheduled time. pf can match any states that were for the pass rule and kill them when the time finishes. This prevents smart kids from having a game running over the end time and just keeping it running.



  • @phil.davis:

    Once you have a way to identify the traffic (Alias XYZ of IP addresses or …) then make a schedule for the time you would like to allow the access.
    Then make rules on LAN:

    1. Pass traffic with destination XYZ alias and select the schedule you created.
    2. As the next rule after the pass, Block all with destination XYZ.

    Doing it this way makes it easy for pfSense to stop the access at the scheduled time. pf can match any states that were for the pass rule and kill them when the time finishes. This prevents smart kids from having a game running over the end time and just keeping it running.

    Has something be done to kill the states now since the behaviours change in FreeBSD10?#

    8 used to kill states on schedule, 10.1 doesnt in all my tests, and at least one other has also reported this on here iirc.



  • @firewalluser:

    @phil.davis:

    Once you have a way to identify the traffic (Alias XYZ of IP addresses or …) then make a schedule for the time you would like to allow the access.
    Then make rules on LAN:

    1. Pass traffic with destination XYZ alias and select the schedule you created.
    2. As the next rule after the pass, Block all with destination XYZ.

    Doing it this way makes it easy for pfSense to stop the access at the scheduled time. pf can match any states that were for the pass rule and kill them when the time finishes. This prevents smart kids from having a game running over the end time and just keeping it running.

    Has something be done to kill the states now since the behaviours change in FreeBSD10?#

    8 used to kill states on schedule, 10.1 doesnt in all my tests, and at least one other has also reported this on here iirc.

    Thank you for the tip Phil,

    Just to make sure i understand your steps correctly:

    • create schedule that i want to block w/n Firewall > Schedules (e.g.. monday -frday 7-10pm)
    • in Firewall > Rules > Lan, set up Pass as Action (so that they can game during only 7-10pm), input the specific IPs in "Destination" along with it's associated ports, then enable Schedule and match it to above rule.

    Would that be the way?

    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

    Which way would you prefer, or am i off the mark?


  • Netgate

    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.



  • @Derelict:

    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?


  • Netgate

    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.



  • @Derelict:

    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


  • Netgate

    You use a scheduled pass rule not a scheduled block rule.

    Your first link is not about scheduled rules at all.



  • @Derelict:

    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

    @Derelict:

    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?


  • Netgate

    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:ESTABLISHED

    After 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.



  • @Derelict:

    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.