Can someone check the order of my LAN rules?
-
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:
TIA
-
-
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.
-
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.
-
-
-
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.
-
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.
-
-
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".
-
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 ;)