NTP Firewall Rule

[johnpoz]

@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.

[czar666]

@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.

[johnpoz]

@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.

[czar666]

@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?

[johnpoz]

@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.

[czar666]

@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.

[czar666]

@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.13

You 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.

[johnpoz]

@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

[czar666]

@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.

[NE_77]

@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		UDP

10.40.90.1 is the pfsense interface IP for that VLAN. NTP service is running.

[NE_77]

@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		UDP

10.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.

[johnpoz]

@ne_77 that rule you posted has zero evaluations see the 0/0 B. So nothing is matching that rule.