New User... Did I define my rules correctly?
-
Hi All,
I have my box up and running for a few days now.
I had a look on this forum and online and have setup a rules set on my pfsense box.
Do these rules make sense and are they correctly defined? If not what would I need to change and could you also provide some explanation. That way I can learn out of my mistakes.
If I would add another interface, lets say APS (Access Points) would I need to copy all rules from the LAN to this interface? Or is there an easier way to do this?
Any help would be appreciated
...
-
Hello and welcome to pfSense,
why is there a special rule for blocking DNS? You are blocking all IPv4 Traffic with the last rule? Btw: pfSense blocks all traffic without a rule per default so this last rule is not required.
Your NTP rule is nonsense in this config. What do you want to achieve with this rule? If you need NTP on your clients, configure pfSense as a ntp server and allow LAN net to LAN address with NTP Port.
On the WAN interface its the same > The block all rule isnt required as pfsense blocks all traffic per default.
Kind regards
-
your wan net to lan net ntp rule doesn't make a lot of sense? Unless pfsense is downstream of some other network "wan net" and you want it to be able to access some ntp server on lan net, and your not doing nat?
Then again if pfsense was a downstream router than wan net should only be a transit network, and what would be needing to access ntp on the lan from your transit - other routers? Keep in mind that wan net is not the "internet" its just the network that pfsense wan net is on.. Nothing more.
As mentioned about your block rule at the end.. The only reason for such a rule would be to NOT log your blocked traffic, since you do not have it set to log and out of the box the default deny that is on every interface is set to log all blocks.
Same goes for your block rule on your wan - all that rule does is block the default deny from logging since you do not have that rule set to log. If you don't want to log would be easier to just turn off logging of the default deny.
-
I have a switch connected on the lan side that uses ntp. Without that rule the switch does not connect to the ntp server. Is there any manual on how to setup ntp server on pfsense?
The dns rule would force clients to use the dns as setup on pfsense instead of overruling the dns servers with local settings. This is described in the book Mastering Pfsense.
Thx
-
@patpop said in New User... Did I define my rules correctly?:
I have a switch connected on the lan side that uses ntp
If your switch is on your lan - it has ZERO to do with pfsense in talking to other devices on the lan, say ntp.. ZERO!!!
As to guide in setting up ntp on pfsense - you need a guide to click an enable button? To be honest it might even be enabled by default out of the box? The we gui is pretty straight forward.. Could you post up your ntp settings page. If you have some specific questions be happy to answer.. But its really no brainer stuff.. And out of the box once you enable it it would be working since it would query public pool ntp to get the time, and then serve that up to clients on the local/lan side of pfsense after the check to enable it.
If its not working after you enable - then sure we could help you figure out what is wrong. But some switch on your lan talking to ntp on your lan has nothing to do with pfsense. At most if you were using fqdn for your ntp then pfsense coudl resolve that for your clients on your lan to the ntp servers IP.. But it would have nothing to do with lan device talking to lan device..
-
The ntp on that switch (draytek) has a predefined number of ntp servers define with non-lan ip addresses. So forgive my ignorance if i thought i woud need a rule to connect with them.
-
If your switch is talking to the internet for ntp, then the rule to allow ntp would be on the LAN side, not the wan.
Rules are evaluated on the interface as traffic enters pfsense. First rule to trigger wins, no other rules are evaluated.
If you want lan device to talk to some ntp that is not on lan, then the rule would be on lan interface and the source would be lan net, not wan net.
Your lan rules do not allow for ntp, so no no device on lan would be able to talk to ntp. And that wan rule you created wouldn't allow it at all anyway. So if your thinking that allowed it - no sorry not possible.
Are you saying your switch that is on lan has a WAN NET IP address? So your running multiple layer 3 on the same layer 2?
-
No switch has static lan address.
-
well then on a rule on your lan the source needs to be lan net, or its specific IP if you want to allow it to talk to ntp. How would wan net even be seen as source inbound into "lan"?
-
Would it make sense then to have the unreachables unselectable or even remove from the drop down for source? Maybe this clear things a lot for new users like me
...
-
It might - put it in as a feature request on redmine. But I would think its going to have really really really low priority. Since I would have to assume they just share code for all the gui places that you would pick an interface, etc.
But sure you would think it possible to make it so the normally quite impossible sort of scenario's like wan network as source coming in lan are not listed. Then again you would also hope that the users of your firewall would understand basic networking ;) And how the rules on said firewall they are managing are evaluated..
The default to /32 on drop down when you add an interface IP also messes with many users because they leave it as /32 vs setting the actual mask they want to use.. So maybe that should default to I don't know /24? You know to keep the users from shooting themselves in the foot ;)
Feel free to put in a bouncy if you want for someone to modify the code for the drop downs to only list "realistic" interfaces as source vs all of them.. Or you could do yourself and submit it.. Its possible if you put it in as feature request that the developers might get to it - but I wouldn't hold my breath lets say.. Just my take..
So you have new rules you would like to discuss?
