Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    2.01 using a rule on a schedule to stop Internet access (LAN to WAN)

    Scheduled Pinned Locked Moved Firewalling
    5 Posts 2 Posters 1.8k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M Offline
      mervincm
      last edited by

      My desire is to limit access from a subset of PC's to Internet for evenings and prevent multihour online sessions.  I created an alias for the subset of PC's, by IP address.  DHCP reservation and spot check on system verified I have the source IP correct.  I then created a schedule for the times that I want access to be rejected.  Lastly, I created a LAN interface Firewall-rule (right under the Anti-lockout rule)
      reject protocol:* Source:alias port:* destination:* port:* gateway:* queue:none Schedule:rejectimes
      reboot the firewall

      spot checks during the "reject time" reveal working Internet access.  Ideas?

      some possible ideas:

      When the reject rule kicks is, it is able to kill existing sessions, or just stop new ones.  I need to be able to stop existing ones.

      Is the schedule system accurate to the second?  Assuming firewall is set to correct timezone and time is set correctly, If I have set a block rule to a schedule that includes 13:00-13:59, can I expect it to block traffic right at the moment the clock hits 1:00PM, and permit traffic the moment it hits 2:00PM?

      If I modify the schedule, or the list of IPs in the alias, it seems I need to reboot to take immediate effect, is this correct?

      1 Reply Last reply Reply Quote 0
      • M Offline
        mervincm
        last edited by

        please note that I have searched and read the posts that the schedule only works on the 00, 15, 30 and 45, and that it includes the full minute after.  Thats why when I want to block only from 1:00PM to 2:00PM I specified 13:00 to 13:59.

        I have not tried changing my start time to 1 minute before I want it to kick in, maybe thats what I should have done.

        PS I have also made the schedule apply equally on all days of the week, I plan to do that fine tuning after this is working as expected!

        1 Reply Last reply Reply Quote 0
        • M Offline
          mervincm
          last edited by

          Found another post that seemed to indicate that existing sessions are NOT killed when the scheduled reject kicks in.  I am not sure if this is still in place with ver 2.01 but I am going to assume it is.

          I made a change in approach hoping to work around this.

          I modified the default allow LAN to any rule  source from * to NOT alias
          then just on top on that, I created a rule that will instead enable source:alias and a new shedule that includes the times that I want it to work.

          I should be able to test this tomorrow.

          1 Reply Last reply Reply Quote 0
          • P Offline
            phil.davis
            last edited by

            The things you describe are correct and should work. You should be able to do it either way around (the negative after hours block, or the positive in hours pass). In either case, existing sessions/states/flows are not killed. So someone doing a download, for example, will have the download keep going. But users who bounce around doing different web stuff should quickly find they lose access.

            If there are still problems tomorrow, post the aliases, schedule and rules you have.

            As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
            If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

            1 Reply Last reply Reply Quote 0
            • M Offline
              mervincm
              last edited by

              forgot to post that my change decribed above did indeed fix the issue for me.

              1 Reply Last reply Reply Quote 0
              • First post
                Last post
              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.