4. Timebased rules

Timebased rules

  • R

    I made a schedule for my kids to be blocked from internet. The 1st one is to block from 22:30 - 23:59 the 2nd one is from 00:00 - 06:00. It shut of the access as scheduled but did not re-enable access on schedule. I disabled the 2nd rule and access came back. The pc in question was off when the block should have ended. So the question is does the pc have to be on for the rules to work properly?

    0
  • H

    Please make sure you run the very latest snapshot. There have been some snapshots in between where things have not been working properly. Clients don't have to be up for scheduled rules to work/get reloaded.

    0
  • R

    I was using the snapshot 3-27-2007 modified on 4-6-07. Downloading new one now.

    0
  • H

    Please test it, it should work!

    0
  • R

    I don't know what is happening. I set a rule to block access to LAN from my laptop 19:45 - 20:0 It did not block or unblock access. I can open the schedule like I am going to modify the times and just tell it to save then it takes effect. It will not block or unblock automatically.

    PS… you will lock yourself out of the firewall as long as the block rule is active. You can't even access pfsense to administer while active so don't test this on your admin pc. ;)

    0
  • C

    @redpanther:

    PS… you will lock yourself out of the firewall as long as the block rule is active. You can't even access pfsense to administer while active so don't test this on your admin pc. ;)

    Do you have the "Disable webGUI anti-lockout rule" box checked on the Advanced page? If not, this is a bug in the time based rules that needs to be fixed. You should never be able to lock yourself out of the webGUI unless this box is checked.

    0
  • R

    @cmb:

    Do you have the "Disable webGUI anti-lockout rule" box checked on the Advanced page? If not, this is a bug in the time based rules that needs to be fixed. You should never be able to lock yourself out of the webGUI unless this box is checked.

    I think not a bug, you can't access pfsense at all from the blocked pc while rule is active. I only meant not to block your pc you use to admin.

    0
  • J

    normal there is a speciale rule that makes it that that can never happen
    if it is and you did not disable the rule
    then its a big bug

    0
  • H

    To be able to shutdown already established connections we had to set ipfw on top of pf. My bet is we don't install the antilogout rule for ipfw as we only parse the visible rules in the webgui. So if you block to any port 80 destination and your webgui runs on port 80 you will log yourself out. Create a rule on top of this block to any port 80 rule that still allows access to the gui as destination IP. I guess then it will work. If that's the case we just need to make ipfw aware of the webgui antilogout rule.

    0
  • H

    Hmmh, Tonight, i will duplicate this test, too, and post the outcomes…

    0
  • R

    I did a format, downloaded the official iso, downloaded the newest snapshot and re-installed tonight. Still can't get the schedules to block - unblock internet access. :'( Any ideas?

    0
  • Y

    Works for me. Take some screenshots of your rules and schedule, then post them here.

    0
  • R

    0
  • Y

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

    0
  • R

    0
  • Y

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

    0
  • K

    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!

    0
  • H

    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!

    0
  • K

    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.

    0
  • K

    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!

    0
  • T

    works here like a charm… sorry...

    0
  • K

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

    Any help would be appreciated!

    Thanks.

    0
  • P

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

    0
  • K

    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!

    0
  • K

    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

    0
  • H

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

    0
  • K

    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!

    0
  • K

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

    0
  • D

    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

    0
  • K

    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!

    0
  • K

    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!

    0
Log in to reply
 

Products

Services

Support

News

Resources

Company

Our Mission

We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

Subscribe to our Newsletter

Product information, software announcements, and special offers. See our newsletter archive for past announcements.

© Copyright 2019 Rubicon Communications, LLC | Privacy Policy