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

    Can someone check the order of my LAN rules?

    Scheduled Pinned Locked Moved General pfSense Questions
    5 Posts 2 Posters 822 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
      Mothra
      last edited by

      I have a pretty simple setup and it seems to be working fine… Few alias groups, one with no WAN access (printers, switches, etc.) and then some that get no WAN access through the night.

      Main thing I keep pondering is, I'm using a rule to force all DNS to pfSense and I'm not sure if it makes sense to have those two block rules come before or after the DNS rule? Also, if there's anything glaring there that's "wrong" or "could be better", I'd love the advice!

      Dropping an image URL here cause the attachment isn't uploading with the post:

      http://imgur.com/a/UL792

      TIA
      LAN.PNG
      LAN.PNG_thumb

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

        1. DNS - I just block anything to the DNS port number and not LAN address, and put that block rule up high. So if some client messes around with their DNS settings, they just get nothing. I guess you have done some redirect thing to push all DNS to 127.0.0.1 and then are allowing it. Probably you want to block all other DNS after that, just to make sure.

        2. For scheduled rules, it is best to make them positive - allow access for times they can use the internet. Then have a block rule after that for all times. So pass "Standard Clients" for a "Daytime" schedule, then after that put a rule to block "Standard Clients" at all times.
          That way, pfSense can keep track of all the states of "Standard Clients" that are being passed. Then when the scheduled time ends, pfSense will kill those states. That ensures that the clients really stop getting access.

        BlockOtherDNS.png
        BlockOtherDNS.png_thumb

        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
          Mothra
          last edited by

          @phil.davis:

          1. DNS - I just block anything to the DNS port number and not LAN address, and put that block rule up high. So if some client messes around with their DNS settings, they just get nothing. I guess you have done some redirect thing to push all DNS to 127.0.0.1 and then are allowing it. Probably you want to block all other DNS after that, just to make sure.

          2. For scheduled rules, it is best to make them positive - allow access for times they can use the internet. Then have a block rule after that for all times. So pass "Standard Clients" for a "Daytime" schedule, then after that put a rule to block "Standard Clients" at all times.
            That way, pfSense can keep track of all the states of "Standard Clients" that are being passed. Then when the scheduled time ends, pfSense will kill those states. That ensures that the clients really stop getting access.

          Thank you for taking the time to respond to my question… for the DNS, I found two How-To's in the documentation... the first one I think is what you were describing:

          https://doc.pfsense.org/index.php/Blocking_DNS_queries_to_external_resolvers

          And the one I used was this one:

          https://doc.pfsense.org/index.php/Redirecting_all_DNS_Requests_to_pfSense

          The only reason I went with the second method is because the screenshot matched the version of pfSense I'm using so I figured it was the way to do it now? Maybe I'm wrong there… I'm just not sure which is the preferred or if I should be doing the mix of the two. I've tried putting the Google DNS servers on client machines on the network and they were still forced to use the DNS servers in pfSense even after quitting the browser and clearing the DNS cache, etc.

          As for the scheduling, what you're saying makes sense... I'll look into that, thank you.

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

            The only reason I went with the second method is because the screenshot matched the version of pfSense I'm using so I figured it was the way to do it now?

            The second method does mean that if someone tries to (or accidentally) sets their client to use some other DNS, that it will be "silently" redirected to use pfSense anyway. So I guess that is convenient for clients.

            The first method makes clients not work if they do not "obey the rules".

            I guess it depends if you are a kind-hearted soul or "the network admin from hell".

            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
              Mothra
              last edited by

              @phil.davis:

              The only reason I went with the second method is because the screenshot matched the version of pfSense I'm using so I figured it was the way to do it now?

              The second method does mean that if someone tries to (or accidentally) sets their client to use some other DNS, that it will be "silently" redirected to use pfSense anyway. So I guess that is convenient for clients.

              The first method makes clients not work if they do not "obey the rules".

              I guess it depends if you are a kind-hearted soul or "the network admin from hell".

              Hehe… yah... I get it now, I think I'll stick with the kinder option for the time being ;)

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