NTP Firewall Rule
-
@ne_77 That will allow NTP and any other services on the interface.
This allows just NTP. I let the NVR sync, then sync all cam's to it. -
That's how I did it on my pfsense:
-
@czar666
Thinkable that the NTP server is hard-coded in the devices.
To workaround this, I redirect NTP traffic to the pfSense LAN address:
-
@ne_77 that for sure would allow for access to ntp which is only UDP 123.
You might want to restrict to just that protocol and port, but yes the cam address would be typical destination for ntp listening on that interface.
As already mentioned your devices might have a hard coded ntp server. You have 2 options here, either do a ntp redirect like you can do a dns redirect. Or what I find better is dns host override. But you would also let your clients do dns.. I have quite a few devices look for ntp via name.. I have a bunch of iot devices that look for
uk.pool.ntp.org
Don't ask me why its moronic - they are sold here in the us.. So why they would point to a uk ntp pool address is beyond me.. Stupid lazy developers too lazy to change the code they using from something else is my guess ;)
If the device has a hard coded ntp by name, like my example above - they would need dns before they could even attempt to get ntp. So you would need to allow that as well to say the cam address tcp/udp 53
I would look to see what ntp server they are looking for, and put in a host override to point that to pfsense IP. Simple logging of their dns queries in pfsense, or simple packet capture of their traffic will tell you what they are trying to look up, etc.
You would think they should just use the ntp address you can hand out in dhcp, but have found very few devices leverage this..
edit: if you really want to get fancy, once you know what fqdn they are looking for for ntp - you could like what they can do for dns queries to only that via a view in unbound.
Simpler solution is if your CAMs have a way to set which ntp server they use - that for sure would be the simpliest solution, and then just your firewall rule to cam address on port udp 123 and bobs your uncle ;)
-
-
@ne_77 dhcp has auto created rules that are hidden from the gui, when you enable dhcp server on an interface rules are auto created to make sure dhcp will work.
If you can hard code the IP of the ntp then yeah that is great and the simplest solution. The only rule you would need on the interface is the UDP port 123
If you don't want them going to the internet they shouldn't need dns, unless they need to resolve some local resource? Which I wouldn't think so for a CAM.
-
@viragomann @johnpoz Thanks, I used your advice and changed my config. If it's not correct then let me know please.
Two redirection rules. One for DNS and one for NTP traffic.
-
@czar666 thought you said you could set the IP for ntp on the cam directly.. There is no point to the redirect then.
The default is deny, so there really isn't any reason for the deny to your firewall port. Nor the last rule with deny all.
What ports are in your solaredge and update ports, the way those rules are written you could go anywhere on those ports. You might want to limit those rules to only the IP or IP ranges of the update servers - normally linux update just uses 80 and 443 - so that rule would really just allow all access to the internet on those ports unless you lock it down to only the IPs that the update servers your talking to.
-
@johnpoz whaaa, free advise! I love it. So exceptional these days...
I will try to motivate my choices. Not sure at all if these are smart choices though...@czar666 thought you said you could set the IP for ntp on the cam directly.. There is no point to the redirect then.
That was @NE_77 ;-)The default is deny, so there really isn't any reason for the deny to your firewall port. Nor the last rule with deny all.
About the firewall port: systems in that vlan don't get to see the pfsense page. If I remove the rule I thought they could see the login page. I will have to test it again, I am not 100% sure anymore.
About the deny any at the end: I just use this from time to time to be able to log my rule and see what's blocked.What ports are in your solaredge and update ports, the way those rules are written you could go anywhere on those ports.
SolarEdge: 443, 53
Updates: 53, 443, 80
I figured this out after analyzing the firewall system logs.You might want to limit those rules to only the IP or IP ranges of the update servers...
I completely agree with you and will look into it. -
@czar666 said in NTP Firewall Rule:
SolarEdge: 443, 53
Why would you need to talk on 53 to your Solaredge - that doesnt make any sense, 53 is DNS.. Why would solaredge be providing dns services?
As to why you could see the webgui of pfsense, well if you allow camserver to talk on the update ports and don't limit it to IP ranges, etc. then yeah you would be abel to talk to pfsense. On those ports.
But once you limit that allow to only the solaredge IP(s) then you wouldn't be able to talk to pfsense IP on those ports.
-
@johnpoz The reason for the dns port is because I just saw them in the logs a few weeks ago. But you are right there is no reason to. And I just added the port without questioning. I should know better so I will invest again.
Concerning webui, camserver can use update ports but my default webui port is not 443 anymore. Changed it to 8443. And does the 'dropdown' rule doesn't apply here if my port remained default 443? It's blocked on the first rule so shouldn't hit anymore on the fifth rule? Or do I see this wrong?
-
@czar666 if your gui port is 8443, and you don't allow 80.
Then there there would be no reason for the first rules because none of your other rules allow those ports and you would fall thru to the default deny.
As long as your solaredge and update ports aliases do not allow the 8443 gui port then the first rule isn't need to block access to the web gui.
There is no reason why you couldn't leave it, what is in your iot_firewall alias? If your goal is to block all access to the web gui, the better thing to use would be the built in alias "this firewall" this includes all IPs on pfsense interfaces, lan side and wan interface..
Was just pointing out not really a needed rule, the default is deny - so if you don't allow it its going to be denied anyway. The only time you really need a deny rule like that is if some other rule below would allow it - like you had in your rules.
If your rules for the solar and update where limited to the IPs of those only, and or unique ports then the first rule wouldn't be needed. But nothing wrong with be sure you don't ever allow access by accident, if your goal is blocking access to the gui.
An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 24.11 | Lab VMs 2.7.2, 24.11 -
@johnpoz I am at work (GMT+2) and on a different project. But I will take time this weekend to verify all this. I really appreciate your advice and the time you spent to help others. Thank you.
-
@johnpoz My port 80 was indeed not blocked. Changed that.
The first rule = like you said not needed because of deny all.
IOT_Firewall alias = 192.168.20.254 the ip of my firewall in that subnet.
I missed that built in alias somewhere with all firewall interfaces in it. But it's easy to add, so I did.
SolarEdge host = 192.168.20.13You asked why I added dns in my rule. It's in the log. So I presume it needs dns to go outside to some cloud service? Because of my redirect rule in NAT it asks my firewall to do the translation. Am I right?
In the meantime I have a clear view to what external destinations the SolarEdge goes so I will narrow this down.
-
@czar666 20.254 the IP of your pfsense on that network. And is what would be handed out via dhcp by default. That isn't trying to talk to your solaredge - that is just asking the dns server it was assigned by dhcp for dns..
If you want your clients to ask pfsense for dns, then allow that in their own rule. The reason your seeing that in your solaredge rule because that is the IP that was asked for dns. Your redirect rule for dns above that wouldn't show up the log for that rule, it would show up if you logged your redirect rule
-
@johnpoz I configured my dns to be forwarded to opendsn (to make use of that web content filtering feature). The NAT redirect DNS is for all devices trying to reach a dns others than opendns. I admit, last week I added a new package called pfBlockerNG. So for the moment if I go to a restricted webpage I sometime get the opendns block page and sometimes the pfBlockerNG block page. Will this create problems in fact? I don't think it should but I'd like to know your point of view.
And concerning my log => it is my SolarEdge in my network that talks dns to my firewall ip address. Because you said: "That isn't trying to talk to your solaredge". In fact the source is the SolarEdge.
-
@jarhead said in NTP Firewall Rule:
@ne_77 That will allow NTP and any other services on the interface.
This allows just NTP. I let the NVR sync, then sync all cam's to it.I know that this is an older thread, but I've noticed that the cameras are failing to sync. When I manually go into the camera console, it states "Failed to connect the test server." The FW log shows:
Checkmark Oct 23 21:41:27 CAM Allow NTP (1665518016) 10.40.90.3:46747 10.40.90.1:123 UDP10.40.90.1 is the pfsense interface IP for that VLAN. NTP service is running.
-
@ne_77 said in NTP Firewall Rule:
@jarhead said in NTP Firewall Rule:
@ne_77 That will allow NTP and any other services on the interface.
This allows just NTP. I let the NVR sync, then sync all cam's to it.I know that this is an older thread, but I've noticed that the cameras are failing to sync. When I manually go into the camera console, it states "Failed to connect the test server." The FW log shows:
Checkmark Oct 23 21:41:27 CAM Allow NTP (1665518016) 10.40.90.3:46747 10.40.90.1:123 UDP10.40.90.1 is the pfsense interface IP for that VLAN. NTP service is running.
I got it to work, I had re-created the interface and under NTP services, I did not re-select the network.
-
@ne_77 that rule you posted has zero evaluations see the 0/0 B. So nothing is matching that rule.
