Rules + Schedules Ineffective?

podilarius · May 6, 2013, 9:59 AM

There is a cron scheduler, I wander if you could setup a state flush just a minute after your block rule goes into effect.

MikeGreer2000 · Sep 17, 2013, 2:05 AM

Just thought I'd check in and see if anyone has been able to get pfSense to disconnect active sessions once the allowed time has expired. I read through the info on 2.1 but didn't see any mention of it.

I'll be trying it out next week sometime and will post back with the results but by the looks of the documentation the problem will still exist with 2.1… Sadly....

The scheduling feature is a good one for anyone trying to get control of their kids Internet access but it is also important in the business world... I have a client that wants to keep an open network during business hours but then shut it down when the office closes at 5:00. They still want certain machines to be live on the Internet after hours.

I have been unable to get pfSense to close the correct sessions but allow others to continue...

Here's hoping it was somehow addresses in 2.1.

firewalluser · Sep 18, 2013, 9:45 PM

I havent tested whether active sessions can be closed, but an alternative might be to throttle back to just 1 bit per sec as you cant throttle back to 0 which might be as good as.

Have you also seen this thread?
http://forum.pfsense.org/index.php?topic=7406.0

I'm trying to find the webpage I found a while back when I wanted to do some traffic shaping which allowed me to set up rules so my website traffic has priority over lan users on a schedule and this worked well for me.

If I find it again, I'll post the link.

Edit:
I think this was the webpage I used, also note in the comments a mention of using schedules.
http://www.hammerweb.com/blog/2011/09/traffic-shaper-in-pfsense-2-0/

pere · Dec 12, 2013, 9:42 AM

My solution look like this (attached image) using :

2.1-RELEASE (i386)
built on Wed Sep 11 18:16:22 EDT 2013

First created aliases for local ip addresses that is affected with time based restrictions. Created 2 aliases, one for allow internet and the second for stop internet. In the both aliases I put the same ip addresses. Of course dont forget to put those addresses in static DHCP lease.

Then created 2 schedules and in first added time range (05:00 - 23:59) when internet is allowed. In the second schedule added time range when internet is not allowed (00:00 - 05:00).

Be sure that option in System->Advanced->Miscellaneous - Schedules is NOT checked.

In Firewall->Rules->Lan created 2 new rules right after default anti-lockout rule.

First rule allow trafic (PASS) on interface LAN, IPv4, protocol : any, Source : alias for allow, and with schedule to allow internet. Second rule is to (BLOCK) on interface LAN, IPv4, protocol : any, Source : alias for stop, and with schedule to stop internet.

phil.davis · Dec 12, 2013, 10:28 AM

Does it also work without the "Allow_Internet" rule?
Without the "Allow_Internet" rule, traffic will be allowed by the ordinary "allow all on LAN" rule at times when it is not blocked. But maybe in that case the system will not know which are the states that need to be "switched off" when the block rule comes into effect.
Would be interesting to know - I should try it myself ;)

pere · Dec 12, 2013, 11:50 PM

@phil.davis:

Does it also work without the "Allow_Internet" rule?
Without the "Allow_Internet" rule, traffic will be allowed by the ordinary "allow all on LAN" rule at times when it is not blocked. But maybe in that case the system will not know which are the states that need to be "switched off" when the block rule comes into effect.
Would be interesting to know - I should try it myself ;)

I tried it without that ""Allow_internet" rule and then open states remain open…. somehow.

Also I noticed that some states from floating rules remain open (sometimes) with that both allow and stop rules active.

Thinking of moving those allow-stop rules to floating or wan area to see what will happen.

Derf · Dec 23, 2013, 1:14 PM

@podilarius:

There is a cron scheduler, I wander if you could setup a state flush just a minute after your block rule goes into effect.

Well, that's exactly what I did!

My solution is as follows:

Create an alias with all the IPs that should be blocked. Be also sure that you defined the corresponding static mappings in your DHCP server configuration. Let's call this alias 'Children'
Create a schedule named 'AccessDenied' and define it to whatever you need. In my case it's 22:00 - 07:00, each and every day.
Create a rule on your WAN interface like this: Action Block / Protocol Any / Source Any / Destination 'Children' / Schedule 'AccessDenied'
Create the reverse rule on you LAN interface: Action Reject / Protocol Any / Source 'Children' / Destination Any / Schedule 'AccessDenied'
As some of you already noted it, these rules will only block/reject new connections but won't kill existing one. This is because pfSense is doing 'statefull packet inspection (SPI)'. This means that, to determine if a packet should pass thru, it will first look at the existing states and then look at the firewall rules. If states shows that the packet is an answer to a previously authorized packet, it will pass thru, regardless any rule.

So, in addition of the rules we already put in place, we also need to kill all the states from any IP belonging to the 'Children' list.
I wrote the following (quick and dirty) script to do the job…


for i in `pfctl -t Children -Ts`
do
	echo "Killing states from/to $i"
	pfctl -k $i
done

… and put in /etc as pf_KillStates. (be also sure to chmod it with the value 777)

Finally, create a new cron job to launch /etc/pf_KillStates every day at 22:01 (1 minute after the beginning of the 'AccessDenied' schedule).

Note that it seems that the command```
pfctl -t Children -Ts

pfctl: Table does not exist.


Hope this will help some dads  ;)

PS: You may have a useful look at the pfctl manpage (as I did!)
http://www.openbsd.org/cgi-bin/man.cgi?query=pfctl

phil.davis · Dec 24, 2013, 4:37 AM

Create a rule on your WAN interface like this: Action Block / Protocol Any / Source Any / Destination 'Children' / Schedule 'AccessDenied'

Note: This rule is not needed in any normal installation. The WAN will already have a general block at all times, and in any case there will be no traffic initiated from the real public internet with destination IPs in 'Children', because 'Children' is a bunch of private IP addresses in the LAN behind pfSense.

Derf · Dec 25, 2013, 5:50 PM

Thanks for your precision Phil.
It will help me to simplify my ruleset a bit.

Merry X-Mas :)

OzRattler · Dec 29, 2013, 1:55 AM

@podilarius:

There is a cron scheduler, I wander if you could setup a state flush just a minute after your block rule goes into effect.

Hello One and All,

That was how I got around the drama. Downside is that when holidays arrive, I forgot to remove the cron scheduler to kill all states. Unhappy son (and me as well at times) until I woke up.

I am relieved that the thread I started was not just me being dull or failing "to see the forest for the trees" and glad it has triggered some discussion.

@derf, I am about to upgrade from 2.0.3 to the latest and once that is complete, I will then go through your steps. I also understand phil.davis remark about the WAN element.

Nonetheless, does anyone know whether or not this part of pfSense will be (or has been) addressed? As for the latter part of that question, I will soon find out. …....upgrading in 5 minutes. Wish me luck!

Hope we all had a fab Christmas and may 2014 be superb!!!

craigjl77 · Dec 29, 2013, 4:56 AM

Good Luck OzRattler, may all your overs be wicket maidens…. ;-)

podilarius · Feb 20, 2014, 2:46 PM

I would like to see that in the base code of a rule with a schedule.
I have used this and it works great. Thanks.

Phil.Davis, this was not to block incoming, but to block outgoing once the block schedule was in place. While it is true it is not needed in normal rule sets, but any rule that has a schedule on it, needs to have the states killed once it is supposed to be blocking. Or at least an option to kill the states. I can think of a situation where the rule should not drop states. This would be in a rule sending traffic to another shaping queue. This might help make sure the correct traffic shaping is used, but would interrupt the current session, which is probably unwanted.

MindfulCoyote · Jul 3, 2014, 10:53 PM

@pere:

I tried it without that ""Allow_internet" rule and then open states remain open…. somehow.
Also I noticed that some states from floating rules remain open (sometimes) with that both allow and stop rules active.
Thinking of moving those allow-stop rules to floating or wan area to see what will happen.

Pere, did you make any headway with your workaround for the "Schedule States" bug? I thought I'd re-invented your solution, but it only worked in testing. When I dropped my rules into a live environment they are failing to remove active states. I feel that I will need to hardcode a crontab script to call pcftl.

On a side note… can anyone point me to the documentation for pfSense's version of the pfctl command?

NotAnAlias · Jan 15, 2015, 1:41 AM

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?

doktornotor · Jan 14, 2015, 10:04 AM

@NotAnAlias:

Is there a fix without using cron?

Use 2.2

https://redmine.pfsense.org/issues/3558

NotAnAlias · Jan 24, 2015, 4:03 AM

Schedules do work properly with no hassle on 2.2 release.
Thanks pfsense devs :D

dunc · Feb 13, 2015, 4:59 AM

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.

OzRattler · Mar 5, 2015, 12:38 AM

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

jdusablon · Jan 9, 2016, 6:37 AM

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.

Joelcento · Jan 31, 2016, 9:13 PM

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!