Cameras

Stop IP Cameras Phoning Home: VLAN + Firewall Rules

Block a budget IP camera's internet access without losing your NVR feed: camera VLAN, one-way firewall rules, and the local NTP step people forget.

Problem summary

Short answer: put the cameras on their own VLAN, allow the NVR to reach them, and deny that VLAN any route to the internet or to the rest of your LAN. That single change stops a camera talking to its vendor cloud while leaving local recording completely intact — and it works the same whether the camera is a cheap no-name unit, a Hikvision or Dahua OEM rebrand, or a well-known Western brand, because the concern is opaque cloud firmware rather than any particular country of origin. A camera VLAN is really about one-way trust: the NVR (or a trusted client) reaches the cameras, and nothing goes the other way. The traps are that internet-blocked cameras need a local NTP source or their clocks drift until ONVIF authentication breaks, that WS-Discovery multicast does not cross a VLAN boundary so cameras stop being auto-discovered, and that getting the stateful rule order wrong silently leaves the block ineffective.

Operator snapshotEvidence first

First proof

Confirm the cameras are on their own VLAN/subnet with the NVR's path defined.

Screen to open

From the NVR: ping <camera-ip>; nc -vz <camera-ip> 554; nc -vz <camera-ip> <onvif-port>

Expected signal

Cameras are isolated and the NVR's IP is explicitly allowed to the camera VLAN's RTSP/ONVIF ports.

Stop boundary

Don't expose the camera VLAN to the LAN to 'make it work' — fix the NVR allow instead.

Layer path

1A camera VLAN enforces one-way trust: the NVR (and chosen clients) can reach the cameras, but the cameras cannot reach the internet or the rest of the LAN — limiting a compromised camera's blast radius.

2Stateful firewalls track connections, so you only allow the NVR→camera direction; the return traffic is handled automatically. There is no need for a manual 'allow established/related' rule, and rule ORDER matters per platform.

3Internet-blocked cameras still need time: their clocks sync over NTP, and a drifted clock breaks ONVIF's timestamped auth and recording timestamps — so give the camera VLAN a reachable local NTP source (or allow only UDP 123 out).

4Discovery is multicast (ONVIF WS-Discovery 239.255.255.250:3702, mDNS) and stays link-local, so it won't cross the VLAN — add cameras by static IP + port rather than relying on auto-discovery.

Runbook

Step-by-step runbook

Start here. Do each check in order, compare it to the expected result, and stop when the evidence explains the failure or the safe stop point applies.

Create the camera VLAN

Check: Put cameras on a dedicated VLAN/subnet with its own DHCP scope.

Expected result: Cameras get addresses on the isolated VLAN.

If not: Reserve camera IPs so rules can target them precisely.

Allow the NVR (and only it) to the cameras

Check: Add an allow from the NVR IP to the camera VLAN's RTSP/ONVIF ports, above any block.

Expected result: The NVR reaches the cameras; nothing else on the LAN does.

If not: Mind first-match vs last-match order for your firewall platform.

Block the cameras from LAN and internet

Check: Block camera VLAN → other RFC1918 (LAN) above the allow-internet rule, then block/deny internet egress.

Expected result: Cameras can't reach the LAN or the internet.

If not: Allow only what's needed (DNS to the gateway, NTP).

Give cameras local time

Check: Point the cameras at a reachable local NTP server (router/NVR/Pi-hole) or allow UDP 123 out.

Expected result: Camera clocks stay in sync without internet.

If not: Skipping this breaks ONVIF auth and timestamps over time.

Add cameras by IP, then verify isolation

Check: Add each camera to the NVR by static IP + port (not discovery), then test that the NVR streams while the camera has no internet/LAN.

Expected result: Streaming works one-way; egress is blocked.

If not: If discovery is needed, run it from the camera VLAN — multicast won't cross.

Decision tree

If: NVR can't reach the cameras after isolating.

Then: Missing or mis-ordered NVR→camera allow rule.

Action: Add an allow from the NVR IP to the camera VLAN's RTSP/ONVIF ports, above the blocks.

If: Cameras lost time / ONVIF auth fails after blocking internet.

Then: No reachable NTP for internet-isolated cameras.

Action: Point cameras at a local NTP server, or allow UDP 123 out only.

If: NVR can't auto-discover cameras across the VLAN.

Then: Multicast discovery doesn't cross the boundary.

Action: Add cameras by static IP + port; or discover from the camera VLAN.

If: Cameras can still reach the internet/LAN.

Then: Block rules missing or below the allow-internet rule.

Action: Put block-to-RFC1918 and block-to-internet above any broad allow; verify with a test.

Safe stop: Don't expose the camera VLAN to the LAN to 'make it work' — fix the NVR allow instead.

Evidence

Evidence table

Symptom	Evidence to collect	Likely layer	Next action
NVR shows cameras offline after segmenting.	Whether an NVR→camera allow exists and its order.	Inter-VLAN allow / order	Add/raise the NVR→camera allow above the blocks.
ONVIF auth fails on isolated cameras.	Camera clock vs NVR; NTP reachability.	Time sync / NTP	Local NTP for the camera VLAN; resync clocks.
Auto-discovery finds nothing.	Whether discovery host shares the camera VLAN.	Multicast / discovery	Add by static IP+port; discover from the camera VLAN.
Camera reaches the internet when it shouldn't.	Position of block rules vs allow-internet.	Rule order / egress	Move blocks above broad allows; re-test egress.

Reference

Commands and settings paths

Test NVR → camera reachability

From the NVR: ping <camera-ip>; nc -vz <camera-ip> 554; nc -vz <camera-ip> <onvif-port>

Where: From the NVR, across the VLAN.

Expected: Ping and the RTSP/ONVIF ports answer from the NVR's vantage point.

Failure means: A blocked port means the inter-VLAN allow is missing or mis-ordered.

Safe next step: Add/raise the NVR→camera allow for those ports.

Verify the camera CANNOT reach the internet

From the camera (or its VLAN): attempt an outbound connection / DNS to a public host

Where: From a device on the camera VLAN (or the camera's own diagnostics).

Expected: Outbound internet is blocked while local NTP/DNS still works.

Failure means: If the camera reaches the internet, the egress block is missing or below an allow.

Safe next step: Tighten egress: allow only NTP/DNS as needed, block the rest.

Confirm time sync

Camera web UI > date/time (NTP status); compare to the NVR clock

Where: On the camera and NVR.

Expected: Both clocks match within a few seconds via the local NTP server.

Failure means: A drifting camera clock breaks ONVIF auth and timestamps.

Safe next step: Set the local NTP server on the camera and resync.

Hardware boundary

Hardware and platform boundary

Change only when

Segment cameras onto their own VLAN as soon as you have more than a couple — cameras are a common intrusion vector and isolation limits the blast radius.

Evidence that matters

A router/firewall with stateful inter-VLAN rules, a managed switch for the VLAN, a local NTP source, and the ability to add cameras by static IP.

Evidence that does not matter

A second mDNS reflector everywhere — only reflect where a client genuinely needs discovery; cameras can be added by IP.

Avoid

Adding a manual 'allow established' rule (unnecessary on a stateful firewall) or opening the camera VLAN to the whole LAN to 'make it work'.

Related tool/calculator

Use the linked calculator or tool to turn this runbook into numbers for your exact setup.

Device setup troubleshooter

Last reviewed

2026-06-03 · Reviewed by HomeTechOps. Built from June-2026 research verified against ONVIF (WS-Discovery multicast, Profile T) and the stateful inter-VLAN firewall model (UniFi ZBF / OPNsense / pfSense); centers the one-way NVR→camera trust, the local-NTP requirement for internet-blocked cameras, and the rule-order traps, cross-linking the inter-VLAN firewall and ONVIF pages. Stateful firewalls need no manual allow-established rule — stated explicitly.

Sources/assumptions

Assumes a router/firewall and switch that support VLANs and stateful inter-VLAN rules (UniFi, OPNsense/pfSense, etc.).
Stateful firewalls track return traffic, so you allow the NVR→camera direction and return packets are handled automatically — no manual 'allow established' rule.
WS-Discovery multicast (239.255.255.250:3702) is link-local and does not route across VLANs.

Source-backed checks

HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.

Frigate docs: Recommended hardwareUsed for detector inference times, the cameras ≈ (1000 ÷ inference_ms) ÷ detect_fps capacity model, and the current 'Coral no longer recommended for new installs' guidance.Frigate docs: Camera setup (detect vs record streams)Used for the detect-on-substream / record-on-main pattern that drives bandwidth and detector load.FS.com: Understanding PoE standards and wattageUsed for the 802.3af/at/bt source-vs-delivered power figures and the switch total-PoE-budget constraint.ONVIF: Profile TUsed for the Profile T feature set and the 2025 end-of-support for Profile S (Profile T is the recommended replacement).Ubiquiti Help: Zone-Based Firewalls in UniFiUsed for UniFi Zone-Based Firewall zones/policies, the Zone Matrix, and the 'Auto Allow Return Traffic' stateful behavior.OPNsense docs: FirewallUsed for OPNsense stateful per-interface rule evaluation (inbound direction, automatic return traffic, and the quick vs non-quick last-match nuance).Frigate documentationUsed as the first-party reference for Frigate camera setup, detectors, recording, and configuration.

Diagnostic rule

1. Check the simplest signal first.
2. Change one thing at a time.
3. Prove the stream/reachability before deep config.
4. Stop when the evidence says the risk moved.

FAQ

How do I let the NVR see cameras but block the cameras from the internet?

Put the cameras on their own VLAN, then write the rules in order: allow the camera VLAN to reach gateway DNS/DHCP (and your local NTP); allow the NVR (by IP) to reach the camera VLAN's RTSP/ONVIF ports; block the camera VLAN to all other RFC1918 (LAN) above the allow-internet rule; then block (or simply don't allow) the camera VLAN to the internet. A stateful firewall handles the NVR's return traffic automatically — see inter-VLAN firewall rules for the per-platform rule-order model.

My cameras lost time/ONVIF auth after I blocked their internet — why?

Cameras sync their clock over NTP, usually to an internet server. Block their internet and the clock drifts, which breaks ONVIF's timestamped authentication and can mangle recording timestamps. Give the camera VLAN a reachable local NTP server (your router/NVR/Pi-hole box often serves NTP) and point the cameras at it, or allow only NTP (UDP 123) out. See ONVIF camera won't connect.

My NVR can't discover cameras on the camera VLAN — is that the firewall?

Usually it's discovery, not the firewall. ONVIF WS-Discovery and mDNS are multicast that stays link-local and won't cross the VLAN, so an NVR on a different VLAN won't auto-find cameras. Add cameras by static IP + ONVIF/RTSP port instead of relying on discovery, or run discovery from a host on the camera VLAN. Streaming still works because you give the NVR a routable IP directly.

Planning a purchase?

We keep a source-backed, price-free comparison so you can buy once and right. No star ratings, every spec cited.

Local Cameras: ONVIF vs UniFi vs Cloud →