How to Isolate IP Cameras in a VLAN While Retaining NVR Access

A reliable isolation design works as follows: place IP cameras in a separate VLAN with no access to the user network or the internet, allow the NVR to initiate connections to the cameras, and permit equipment management only from a trusted VLAN. All inter-segment traffic must pass through a router or firewall that enforces a “deny everything except explicitly allowed traffic” policy.

Prerequisites and Limitations

This solution applies when the network includes:

• a managed switch with IEEE 802.1Q VLAN support;
• a router or firewall capable of routing traffic between VLANs and filtering it with rules;
• an Ethernet-connected NVR;
• cameras with static addresses or DHCP reservations;
• a separate trusted computer or VLAN for administration.

Menu names, rule syntax, and rule-processing order depend on the equipment vendor. The instructions below therefore describe a verifiable configuration approach rather than commands for a specific model. Before applying the design, confirm support for VLANs, stateful filtering, DHCP relay, and logging in the official documentation for the switch and router being used.

Recommended VLAN Design

The addresses are examples of private IPv4 subnets only. Replace them with the addressing plan used in your network. Subnets assigned to different VLANs must not overlap.

Placing the NVR in a separate VLAN is preferable to placing it in the user network because it allows independent control over camera access to the recorder, user access to recordings, and administrator access to management interfaces.

Step 1. Document the Required Network Flows

Before changing the network, create a connection matrix. Do not allow ports merely because they are commonly used by other cameras. Check the manufacturer’s documentation and the NVR settings for each model.

You typically need to determine:

• which node initiates the video stream: the NVR, the camera, or both devices;
• whether RTSP, HTTPS, ONVIF, or a proprietary vendor protocol is used;
• whether the cameras require DNS, NTP, and DHCP;
• whether cameras send events, snapshots, or alarms to the NVR;
• whether mobile or cloud access is required;
• which addresses and ports are used for administration.

Do not open an arbitrary set of “standard ports” between VLANs. A single unnecessary permitted service can restore camera access to user devices or allow a compromised camera to attack the NVR.

Step 2. Create the VLANs and Gateways

Create a separate logical interface for each VLAN on the router or firewall. Assign each interface a gateway address from its subnet, for example:

VLAN 10, management: 192.168.10.1/24
VLAN 20, NVR:        192.168.20.1/24
VLAN 30, cameras:    192.168.30.1/24
VLAN 40, clients:    192.168.40.1/24

Configure a trunk link between the router and the managed switch with tagged VLANs 10, 20, 30, and 40. Avoid assigning the native VLAN to production devices. The exact method for configuring a native or untagged VLAN depends on the platform.

A camera port must be configured as an access port in VLAN 30. The NVR port must be an access port in VLAN 20. A regular camera should not receive a tagged trunk unless its documentation explicitly requires one.

Step 3. Assign Stable Addresses to the Cameras

DHCP reservations based on MAC addresses are convenient for cameras: addresses remain stable while the gateway, subnet mask, DNS, and NTP settings are managed centrally. Static addresses are also acceptable, but they must be documented and excluded from the dynamic DHCP pool.

Example addressing plan:

192.168.30.10  camera-entrance
192.168.30.11  camera-yard
192.168.30.12  camera-garage
192.168.20.10  nvr-main
192.168.10.20  admin-workstation

For cameras that do not need to communicate outside their subnet, the gateway can technically be omitted. However, this prevents centralized NTP, administration, and NVR access from another VLAN. A more practical approach is to configure the gateway and restrict traffic with the firewall.

Step 4. Configure the Base Firewall Policy

The rules must apply to routed traffic between VLANs. Rule order matters: narrow allow rules must appear above the general deny rule.

On a stateful firewall, return traffic for permitted connections is usually allowed through the established/related state mechanism. The name of this mechanism and the handling of UDP vary by implementation. Do not create a broad “cameras may access the NVR” rule until you have confirmed that the cameras actually initiate connections.

The logical policy can be documented as follows:

ALLOW admin-host -> nvr : management-ports
ALLOW admin-host -> cameras : documented-management-ports
ALLOW nvr -> cameras : documented-video-and-control-ports
ALLOW cameras -> internal-dns : dns
ALLOW cameras -> internal-ntp : ntp
ALLOW cameras -> dhcp-service : dhcp
ALLOW cameras -> nvr : documented-event-ports, only if required
DENY  cameras -> user-networks
DENY  cameras -> internet
DENY  inter-vlan traffic not explicitly allowed

This is a policy description, not a ready-to-use configuration for a specific vendor.

Step 5. Restrict Camera Internet Access

By default, cameras do not require unrestricted internet access to record to a local NVR. Block routing from the camera VLAN to the external network, and do not create port-forwarding rules for the cameras.

When cloud notifications or vendor services are required, first determine from the official documentation:

• whether cloud mode can be disabled;
• which domains, addresses, and ports are required;
• whether the firewall can filter domains without granting general internet access;
• whether the address list changes dynamically.

If the vendor does not publish a verifiable list of network requirements, a safe and narrowly scoped allow rule cannot be created. In that case, either keep the cloud feature disabled or explicitly accept and document the risk of broader access.

Step 6. Account for Multicast Camera Discovery

Automatic camera discovery often uses broadcast or multicast packets, which ordinary routing does not forward between VLANs. As a result, the NVR may fail to discover a camera automatically even though a direct connection to its IP address already works.

The preferred approach is to add cameras to the NVR manually by their fixed IP addresses. This preserves isolation and avoids expanding the multicast domain.

If automatic discovery is mandatory, use only a relay or reflector supported by the equipment and restrict it to the camera and NVR VLANs. Do not enable a general multicast relay between all segments without validation: it expands the device-discovery scope and makes traffic control more difficult.

Step 7. Secure the Cameras and NVR

• change default passwords and create separate accounts with minimum required privileges;
• disable UPnP, P2P, and cloud features when they are not used;
• disable Telnet, unencrypted HTTP, and other legacy services when the equipment supports a secure alternative;
• restrict administrative access to one workstation or a dedicated subnet;
• check for updates only on the manufacturer’s official website;
• do not expose the NVR web interface directly to the internet;
• use an authenticated VPN for remote viewing instead of forwarding ports to the cameras.

Support for HTTPS, service disabling, and local updates depends on the model and firmware. If the manufacturer does not document a feature, do not assume it is available merely because a similar device supports it.

Step 8. Verify the Isolation

Run verification after every change so that you can identify which rule caused a failure.

1. From the administrator workstation, open the NVR interface and the interface of each camera.
2. On the NVR, verify that it receives a stream from every camera and that events appear.
3. From a regular computer on the user network, try to open a camera address. The connection should be blocked unless an exception was created.
4. Check the counters for allow and deny rules on the firewall.
5. Temporarily enable logging for the final deny rule affecting the camera VLAN and identify which connections are being blocked.
6. Verify DNS and time synchronization if those services are permitted for the cameras.
7. Confirm that devices in the camera VLAN cannot connect to addresses in the user network.
8. Verify that no NAT or port-forwarding rules point directly to the cameras.

For network diagnostics, use packet capture on the router, switch port mirroring, or the firewall’s built-in log. The available method depends on the equipment. In the capture, identify the actual destination address, transport protocol, and port instead of opening access to an entire subnet after the first blocked packet.

Common Reasons the NVR Loses Camera Connections

The Camera Is Configured with Its Old Address

After being moved to the new VLAN, its IP address changed. Update the NVR entry or the DHCP reservation.

The Video Stream Is Allowed, but Management Is Blocked

The NVR may first contact the camera API, authenticate, or retrieve a stream profile before opening the RTSP connection. Determine the required ports from the documentation and blocked-traffic logs.

The Camera Initiates Event Delivery

The video stream works, but motion-detection events are not delivered because the rule allows only connections from the NVR to the camera. Add a narrow reverse-direction rule for the documented event port.

Automatic Discovery Does Not Cross VLANs

Add the camera manually by IP address. Do not expand the rules to full access between subnets solely to enable discovery.

The NVR Has Built-in PoE Ports

Some recorders create their own isolated subnet on built-in PoE ports. That subnet may not participate in the VLAN design of the main network. Access to such cameras depends on the architecture of the specific NVR; there is no universal configuration.

Final Checklist

• the cameras are placed in a separate VLAN and subnet;
• the NVR is isolated from user devices;
• all inter-segment connections pass through the firewall;
• the NVR connects only to camera addresses and required ports;
• the cameras do not have general access to the local network or the internet;
• DNS, NTP, and DHCP are allowed only to specific internal services;
• administration is available only from a trusted VLAN or a single workstation;
• automatic discovery is not used as a reason to open unrestricted access between VLANs;
• the rules have been verified through counters, logs, and actual stream operation;
• there are no direct port-forwarding rules from the internet to the cameras or NVR.

Sources

• IETF RFC 1918 — Address Allocation for Private Internets
• IETF RFC 2131 — Dynamic Host Configuration Protocol
• NIST SP 800-41 Rev. 1 — Guidelines on Firewalls and Firewall Policy
• OASIS — Web Services Dynamic Discovery 1.1