UDP Traffic from NVR not blocked

jpk_pfsense

I have a camera NVR system that is connected to a wireless AP. That wireless AP then connects to "interface2" on my SG-2440 PFSense firewall.

I have no desire for this NVR system to be accessible to/from the internet, as such have put in rules to block all outbound IPv4/6 traffic (all protocols). Essentially, interface2 should not be able to send any traffic outside of it. I have set the rules to log the traffic and see consistent log entries for blocks on UDP 53/DNS. Which is to be expected.

I thought all was working well - the camera NVR "cloud" system/app is unable to connect to it (which is what I want, I wanted to break the cloud connection) and I have tested from a device connected to the wireless AP that I am unable to reach the internet. Great!

Well - Today, I noticed in the States Summary some entries from the wireless AP to internet routable hosts on UDP port 58200. So I run the packet capture on interface2 and I see constant UDP traffic to these hosts, but also from these hosts to the wireless AP (who is then passing it to the NVR system).

So I then run the packet capture on the on the WAN interface to see if traffic was actually getting to that interface and more importantly out of it and I see that it is. UDP port 58200 connections from the internet hosts to my WAN IP.

I then create two specific rules to block all to/from these IP's on the interface2. I do not see any logs of that rule hitting. I run the packet capture on both interface2 and WAN and still see the connections.

Any suggestions on what I might be doing wrong?

Given I see the IPv4* rule blocking DNS - I know that rule is hitting and logging. How is the UDP 58200 able to get outside of that interface? And how the heck did the rules I put in to block those specific internet hosts not work? :)

jpk_pfsense

Sample packet capture, I have deleted part of the IP for privacy:

Interface2
15:48:08.315829 IP 192.168.201.3.60363 > 52.x.249.90.58200: UDP, length 186
15:48:11.498084 IP 192.168.201.3.52360 > 20.x.231.108.58200: UDP, length 186
15:48:13.131891 IP 52.x.249.90.58200 > 192.168.201.3.46448: UDP, length 205

WAN:
15:49:18.356888 IP 192.168.198.17.30491 > 52.x.249.90.58200: UDP, length 186
15:49:21.536394 IP 192.168.198.17.14031 > 20.x.231.108.58200: UDP, length 186
15:49:23.168923 IP 52.x.249.90.58200 > 192.168.198.17.17565: UDP, length 205

jpk_pfsense

Apologies, firewall rules are:

johnpoz

@jpk_pfsense said in UDP Traffic from NVR not blocked:

Protocol: IPv4* | Source: Internet Host 1 | Destination: interface2 net | Port: * | Action Block (and log)
Protocol: IPv4* | Source: Internet Host 2 | Destination: Interface2 net | Port: * | Action Block (and log)

Those rules would never work - how would some internet IP be the source inbound into your lan side interface 2?

Rules are evaluated top down, first rule to trigger wins. No other rules are evaluated.

Thing with block rules - if there is an existing state, the rules are not evaluated. Since the traffic is allowed by the state before rules are evaluated again.

when you create a block rule, you need to make sure you flush any existing states that rule would block. Or wait for them to timeout on their own, etc.

jpk_pfsense

@johnpoz Thank you - I believe the issue was flushing the states. I restarted the interface and that seemed to resolved it. And good call out on the internet IP block rules - I will remove those :)

johnpoz

@jpk_pfsense would of been no reason to restart the interface.. Just look in the state table for the traffic you were going to block.. I would of just filtered on say the NVR IP, and killed all its states.

Rules with 0/0 point to for whatever reason that rule is not being triggered, a rule above it allowing or block what this rule would do, or client you believe should hit that rule isn't actually using pfsense as its gateway, or maybe its using a vpn and your not seeing traffic as you thought with the rule.

Or big one - some state exist that allows the traffic that would trigger that rule.

Glad you got it sorted.

Other possible issues, rules didn't actually reload fully.. You can reload the filters under status and watch the output looking for any errors, like table memory errors, etc.