Traffic seems to be ignoring rules
-
@spgeise said in Traffic seems to be ignoring rules:
Second rule: Block cameras from accessing anything but the NVR server.
Third rule: Allow anything else out."Anything else" is nothing more than the NVR alias. Everything else gets blocked by the 2nd rule.
If I disable rule 2, the cameras will query the NTP server and update.
Are you sure, that the cameras are requesting the stated IP in the first rule?
More reliable than allowing just an IP is to redirect all NTP traffic to the desired server.
This presumes, that the NTP server is connected to a different interface or is pfSense itself, however.Here are my redirecting rules for DNS and NTP for reference:
I redirect the traffic to the LAN IP, but you can also redirect it to any other or to the localhost on pfSense. NTP is already listening on it, for DNS you would have to add localhost to the listening interfaces.
-
@viragomann said in Traffic seems to be ignoring rules:
"Anything else" is nothing more than the NVR alias. Everything else gets blocked by the 2nd rule.
Yes, but I assumed the first rule would evaluate as Pass since it's allowing anything on the interface to access the NTP IP address.
@viragomann said in Traffic seems to be ignoring rules:
Are you sure, that the cameras are requesting the stated IP in the first rule?
Yes, I confirmed.
Oddly enough, the first rule seems to be working now after I posted this question. However, I originally had it as 0.noth-america.pool.ntp.org instead of the 216.128.181.220 (Which is what that FQDN resolves to). It never worked.
Now I'm thinking maybe it's a DNS thing if it's not working using the URL? However, the cameras are using 9.9.9.9 and 4.4.4.4 for DNS so I'm still guessing.
-
@spgeise the alias resolves one IP I believe. Also they change.
;; QUESTION SECTION:
;0.north-america.pool.ntp.org. IN A;; ANSWER SECTION:
0.north-america.pool.ntp.org. 130 IN A 206.108.0.133
0.north-america.pool.ntp.org. 130 IN A 5.161.184.148
0.north-america.pool.ntp.org. 130 IN A 173.255.241.59
0.north-america.pool.ntp.org. 130 IN A 72.30.35.88 -
@spgeise First rule allows anything to access the NTP server. Best to set it as Source:VLAN subnet, for peace of mind... In the second rule, the cameras need to access PFSense as a gateway, DHCP and DNS server at least. If these cameras are also not in the same L2 but traffic passes through PfSense, you need to add two rules to allow them to talk to one another. Third rule also allows anything else IN. Also, as @SteveITS said, use the domain name of the entire pool for the cameras. Or better yet, setup PfSense NTP.
-
@NightlyShark said in Traffic seems to be ignoring rules:
Third rule also allows anything else IN
What do you mean by this? The cameras should be getting blocked by the second rule, which would leave only the NVR in the third rule being allowed out to the WAN.
-
@spgeise I mean, if you remove the second rule, don't leave that as is, because it is an all in all out rule.
-
@spgeise The second rule is a bit impractical. It says "whenever you see a non-NVR address as source AND a non-NVR address as dst, BLOCK". It can create headaches down the road.
Myself, in order to allow the cameras to reach the NVR, I would go and give each camera an alias (and configure them with static IPs) and create three rules below the NTP rule, that go like:
Source: CameraX
Destination: NVR
Proto: TCP/UDP
(Dest Port: 554?)For each camera.
Below those 3 rules, an allow NVR to internet rule (maybe some "block NVR to LAN1, LAN2..." rules)
That said, that is me.
Also. In most cases, it is not the camera that initiates the connection to the NVR. The NVR logs in to the camera via the rtsp protocol. (Port 554, TCP or UDP). You did not mention anything about the camera-NVR connection, but still, it would be bad terminology to call a device NVR if the cameras log into it. Then, it is just a NAS for the cameras to each act as their own NVR and store the video there?
Just saying.
-
@NightlyShark said in Traffic seems to be ignoring rules:
because it is an all in all out rule.
You understand rules on an interface are only evaluated as traffic enters the interface from the network its attach.. It is not an "out" rule - you can only block in the outward connection with a floating rule.
Yes the traffic allows outbound from a client on network X.. But it is an inbound rule to the pfsense interface.. Users quite often misunderstand rule directions.. Rules are in relation to pfsense point of view.. Like your inside of pfsense... In what direction is the traffic flowing - is it inbound to pfsense or outbound..
If you want to block OUTbound traffic - that can only be done in the floating tab by selecting the outbound direction. Rules placed on an interface are always in relation to inbound traffic into that interface.
edit: but I am with you on the NVR rule - negate rules or ! (bang) rules can be easy to misinterpret. If your goal is to allow the NVR to talk to the internet.. Then create a very explicit rule that allows that..
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.03 | Lab VMs 2.7.2, 24.03 -
@johnpoz What I meant is that, technically, you should not allow packets from a subnet to be able to leave using a non-subnet address (broadcasts, advertisements...) as, while a NAT does exist, it is just bad practice. Unless one uses multicasting or something. Unless I again misunderstand... Thanks anyway, man!
-
@johnpoz In any case, you just incentivized me to review all my rules again, because the part about the perspective eluded me.
-
@NightlyShark multicast or broadcast wouldn't ever be routed anyway..
If you allow say lan X to go to lan Y.. in your lan X rules, this creates a state.. The return traffic from lan Y would be allowed by the state that was created.
-
@johnpoz Just finished with the rules... The got a lot simpler... And I now understand why most of them had 0 Kb, hahaha
-
@spgeise It just hit me: if your cameras are getting their IP via DHCP, (in some models/brands) the manually set NTP could be overridden by the NTP given by DHCP (pfsense ?). I haven't observed this with hikvision, but some cheaper brands, I have seen doing all sorts of crazy stuff.
-
I just setup a NVR and some poe cameras.. I don't recall what the nvr ntp was on before I set it to mine.
But I can tell you the camera's are not reaching out to the internet via their own IP. Because they connect to the switch on the back of the NVR for poe and talking to the NVR. And this is on a different network than the network the NVR is on.. The NVR gets the ip from the network I connected it to 192.168.110.110
I created a leg into this 10.1.1 network behind the nvr, so I can get to the cameras directly - you can see from their settings they are talking to the NVR 10.1.1.1 IP for its gateway.. Which must be doing nat if the cameras are going to talk to the internet, because some 10.1.1.x address would never work via the rules on my 192.168.110 network
I just looked at the cameras directly and they don't even have ntp enabled - they must be pulling time from the NVR.. They have the correct time.. So will have to look into that a bit more..
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.03 | Lab VMs 2.7.2, 24.03 -
@johnpoz That is the setup meant here? I thought they had ONVINF cameras via WiFi or something... In my hikvision poe nvr at least, your mind doesn't even go there, because the security camera streams are from the beginning only accessible via the NVR and its app. Only the doorbells and remote-location cameras have anything to do with the internet... I suspect they got in this whole mess because of some video timestamp thing...
-
@johnpoz No, they specifically say: I have a VLAN with 3 cameras and an NVR. Must be one of those NVR that have a LAN iface only.
-
@NightlyShark yeah I have a NVR on my camera vlan ;) But the cameras are actually behind the NVR in my setup.. I am new to the whole NVR scene.. I have played with stand alone IP cameras before that you just setup on whatever network you connect them too, etc. But my take which maybe flawed and only how this company does it.. The cameras are behind the NVR.. This is an isolated L2, running its own L3 space.. And it is not bridged that is for sure - I tried to see if I could see the camera's macs from my network through the NVR.. Its not bridging the interface it has on my network to the camera network.
To get to the cameras directly I had to connect another network into the poe switch on the nvr, and then outbound nat (source) nat on pfsense so my PC could even talk to the camera's IPs.
I will play with having the camera's directly try talking to my ntp server and see what I see for source IPs, etc.. I will have to do some reading on how the cameras actually sync time - would assume off the NVR..
edit: ok yeah my system is using IPC to sync the cameras time with the nvr time.. So there is zero need for the cameras to talk to any ntp server
-
Thanks everyone for the conversation. Got some interesting takeaways. This is what ultimately got things working correctly for me:
"Cameras" alias is my 3 IP cameras on the VLAN.
"Cameras_NTP" are 0.north-america.pool.ntp.org and DNS servers 9.9.9.9,4.4.4.4
"Cam_External_Ports" are 53 (DNS) and 123 (NTP).The cameras have 0.north-america.pool.ntp.org set as their NTP server. Everything working correctly now.
-
@spgeise said in Traffic seems to be ignoring rules:
"Cameras_NTP" are 0.north-america.pool.ntp.org and DNS servers 9.9.9.9,4.4.4.4
You understand that that pool.ntp.org is going to be constantly changing right.. Why would you not just allow NTP on port 123 if you want your devices to be able to talk to NTP servers out on the internet?
Also why not just use pfsense as your ntp for any devices on your network.. Now you know all your devices are syncing to the exact same source.. And the traffic is local..
-
@johnpoz said in Traffic seems to be ignoring rules:
You understand that that pool.ntp.org is going to be constantly changing right.. Why would you not just allow NTP on port 123 if you want your devices to be able to talk to NTP servers out on the internet?
Of course I understand that. That's why quad 9s and 4s are allowed out.
@johnpoz said in Traffic seems to be ignoring rules:
Also why not just use pfsense as your ntp for any devices on your network
I still haven't been able to get that to work for some reason. Not sure if the cameras are being stupid or if the rules aren't quite right. But ntp.org is the only thing to work so far.
