Timebased rules

redpanther

yoda715

Can you post a screenshot of the first schedule page, firewall_schedule.php, thanks.

redpanther

yoda715

Ok I've confirmed, its not "killing" the states properly.

k2ham

I think I'm having the same problems. I've set up the timebased rules and they are showing up as being active at the proper times when I look at the Firewall:Rules page (e.g., I've got a block rule for my wireless subnet that is showing up as being active at the proper time). However, the wireless subnet is not actually blocked at the time.

Here's what I did:

1. Prior to 7:30 am set up a timebased rule to block access to/from the wireless subnet from 7:30 am to 7:45 am. At this time (prior to 7:30 am) the wireless subnet has access (confirmed via ping to yahoo.com).
2. After 7:30 am check firewall:rules page and confirm that the timebased rule is active… it is. Attempt ping from wireless subnet to yahoo.com... still have connectivity.
3. From the firewall:rules page open up the edit page for the wireless subnet block rule having the associated 7:30 to 7:45 schedule. Don't make any changes but save and apply the rule "change". Attempt ping to yahoo.com. Now there is no longer connectivity which is the proper/desired state.
4. After 7:45 (when the timebased rule should no longer be active) I go through similar steps and see that I have the same problems in reverse. I.e., even though the firewall:rules page shows the rule as no longer active the wireless subnet connectivity is still blocked. I have to "edit" the firewall rule, save it, and apply it for the timebased rule to be truly no longer active.

I am using the pfSense-Full-And-Embedded-Update-1.2-BETA-1-TESTING-SNAPSHOT-05-14-2007 snapshot.

Thanks!

heiko

Hi,
i have duplicated your test, but for me it works as it should.

1.) Block Rule –> schedule 18:30 to 18:45 --> any to yahoo.com --> at 18:30 it blocks all to yahoo.com, no ping
2.) At 18:45 the Block Rule is outside the schedule and the ping replys!

k2ham

Nope… still not working for me. I rebooted the firewall and tried it again. At 14:45 block rule schedule started and I can still ping to yahoo.com. I have to open the block rule, save it so that the system prompts me to apply the "change", and then the rule takes affect. The schedule doesn't appear to change the change the state itself. Nothing shows up in the system log other than the "check_reload_status: reloading filter" from applying the change.

k2ham

Just tried booting from the most recent ISO using my config settings saved on a floppy rather than my hard drive installation which has been upgraded multiple times with squid, snort, etc. installed and uninstalled multiple times. Thought this might help eliminate some potential problems.

Still didn't work booting from the CD. Same behavior as before.

Strange and too bad, since this is a feature I would really like to use!

trendchiller

works here like a charm… sorry...

k2ham

Any suggestions for how I might begin tracking down where the problem might be?

Any help would be appreciated!

Thanks.

Perry

Maybe you could do the same test on lan.
http://pfsense.hotserv.dk/dd.htm

k2ham

Is it possible that my installation is not automatically reloading the rules every 15 minutes (check_reload_status?)? How could I confirm this?

Everything looks fine in the GUI as far as the block rules being enabled/disabled at the proper times per the schedule, etc… yet the scheduled rules aren't actually being enabled/disabled unless I do so manually. I've confirmed this by resetting the states and seeing that the block rules don't work automatically per the schedule (even though they are shown as enabled) but do work if I've manually reloaded the rules.

P.S. I've also gone through my config.xml file to try to find any obvious corruption. I did remove sections for packages that I had previously installed but later uninstalled but that was it. That didn't take care of my problem though.

Thanks again for any help you can provide!

k2ham

The following from the {Complete} Timebased Rules thread appears to describe what I am experiencing…

Hello,
sorry for the misunderstandings about the fw states. I have tested it with two schedules, because (scotts posting) the first schedules becomes up only after a reboot.

1.) I created two schedules
2.) I created one rule to permit icmp to WAN with one schedule (activ 12:45 to 13:00)
3.) At 12:45, sorry nothing happens, no ping replys, at 12:51 i edited and saved manually the schedule for a second time, and it rock´s , hm
4.) The same behaviour if i edited and saved the icmp rule a second time.
5.) At 13:00 nothing happens, at 13:10 i edited and saved the schedule a second time manually, the ping is killed directly

heiko

No, this problem does not exist in the recent snapshot, i think you have a problem with missing cron items…

k2ham

I think you are correct… I don't see any entries in the crontab file.

Also, the rules I'm trying to schedule are on the opt interface. In trying to research and track down where the problem might be (as a relatively newbie though not knowing much of anything!) I noticed the following from the config.inc file:

cat /etc/inc/config.inc | grep schedule
if (isset($config['interfaces']['lan']['schedulertype']))
unset($config['interfaces']['lan']['schedulertype']);
if (isset($config['interfaces']['wan']['schedulertype']))
unset($config['interfaces']['wan']['schedulertype']);
if(isset($config['interfaces']['opt' . $i]['schedulertype']))
unset($config['interfaces']['opt' . $i]['schedulertype']);
/* shaper scheduler moved */
if(isset($config['system']['schedulertype'])) {
$config['shaper']['schedulertype'] = $config['system']['schedulertype'];
unset($config['system']['schedulertype']);

Once again, as a newbie, I was wondering if the opt lines might have a problem since they were different from the wan and lan lines? I haven't tried to see if scheduling is working correctly within the wan or lan segments.

If this is way off base please excuse me!

Thanks!

k2ham

Just tried out a scheduled rule on the WAN interface. It doesn't work there for me either.

DanielSHaischt

These are the stock cron items which can be usually found in a stock config.xml:


        <cron><minute>0</minute>
                        <hour>*</hour>
                        <mday>*</mday>
                        <month>*</month>
                        <wday>*</wday>
                        <who>root</who>
                        <command></command>/usr/bin/nice -n20 newsyslog 
                <minute>1,31</minute>
                        <hour>0-5</hour>
                        <mday>*</mday>
                        <month>*</month>
                        <wday>*</wday>
                        <who>root</who>
                        <command></command>/usr/bin/nice -n20 adjkerntz -a 
                <minute>1</minute>
                        <hour>*</hour>
                        <mday>1</mday>
                        <month>*</month>
                        <wday>*</wday>
                        <who>root</who>
                        <command></command>/usr/bin/nice -n20 /etc/rc.update_bogons.sh 
                <minute>*/60</minute>
                        <hour>*</hour>
                        <mday>*</mday>
                        <month>*</month>
                        <wday>*</wday>
                        <who>root</who>
                        <command></command>/usr/bin/nice -n20 /usr/local/sbin/expiretable -v -t 3600 sshlockout 
                <minute>1</minute>
                        <hour>1</hour>
                        <mday>*</mday>
                        <month>*</month>
                        <wday>*</wday>
                        <who>root</who>
                        <command></command>/usr/bin/nice -n20 /etc/rc.dyndns.update 
                <minute>*/60</minute>
                        <hour>*</hour>
                        <mday>*</mday>
                        <month>*</month>
                        <wday>*</wday>
                        <who>root</who>
                        <command></command>/usr/bin/nice -n20 /usr/local/sbin/expiretable -v -t 3600 virusprot 
                <minute>*/60</minute>
                        <hour>*</hour>
                        <mday>*</mday>
                        <month>*</month>
                        <wday>*</wday>
                        <who>root</who>
                        <command></command>/usr/bin/nice -n20 /usr/local/sbin/expiretable -t 1800 snort2c 
                <minute>*/5</minute>
                        <hour>*</hour>
                        <mday>*</mday>
                        <month>*</month>
                        <wday>*</wday>
                        <who>root</who>
                        <command></command>/usr/local/bin/checkreload.sh 
                <minute>*/5</minute>
                        <hour>*</hour>
                        <mday>*</mday>
                        <month>*</month>
                        <wday>*</wday>
                        <who>root</who>
                        <command></command>/etc/ping_hosts.sh</cron>

If they are missing in your config.xml, you need to insert them before the closing tag.

Cheers
Daniel S. Haischt

k2ham

Thanks Daniel. I finally figured that out.

In looking through the default/stock config.xml file in the latest snapshot, I'm saw quite a few things different and missing in my config.xml file. Even though mine says version 2.9 I don't think it's made it through the upgrades properly so…

I guess I'll rebuild my pfsense box from scratch tonight with the latest snapshot and selectively restore back my configuration settings to try to get it back to where it needs to be.

Thanks again!

k2ham

The rebuild from scratch took care of the problem. Apparently the config.xml file didn't make it through the upgrades in the past successfully.

Thanks for the assistance and for the developers of this great piece of software. Keep up the good work!