Timebased rules
-
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!
-
works here like a charm… sorry...
-
Any suggestions for how I might begin tracking down where the problem might be?
Any help would be appreciated!
Thanks.
-
Maybe you could do the same test on lan.
http://pfsense.hotserv.dk/dd.htm -
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!
-
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 -
No, this problem does not exist in the recent snapshot, i think you have a problem with missing cron items…
-
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!
-
Just tried out a scheduled rule on the WAN interface. It doesn't work there for me either.
-
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 -
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!
-
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!