How to Configure NVR Access to IP Cameras Across VLANs

Working Setup: NVR in One VLAN, Cameras in Other VLANs

For an NVR to receive video from IP cameras located in different VLANs, routing must work between the networks, and the firewall must allow only the connections actually required for video surveillance. There is no need to combine the VLANs into a single broadcast network.

A practical setup looks like this: cameras are placed in separate VLANs, the NVR is in a server or dedicated VLAN, and routing and filtering are handled by a router or an L3 switch with a firewall. The NVR connects to the cameras by their IP addresses.

The addresses above are examples only. Substitute the existing VLANs, subnets, and gateways used in your network. Do not configure overlapping subnets on different router interfaces.

1. Verify the Camera and NVR Addressing

For each camera, you should know at least its IP address, subnet mask, and default gateway. The camera gateway must point to the L3 interface of its own VLAN. The same requirements apply to the NVR.

For example, if a camera has the address 192.168.20.15/24, its gateway must be within the 192.168.20.0/24 network. When the NVR is located in 192.168.40.0/24, the camera's return traffic to it passes through that gateway.

A missing or incorrect gateway on the camera is a common cause of connectivity problems. The device may still open normally from a computer in the same VLAN while failing to respond to an NVR in another subnet.

Do not start by allowing all protocols between VLANs. First establish normal IP routing, then allow connections from the specific NVR address to the specific camera addresses and only for the required services.

2. Make Sure the Router Knows Both Networks

The router or L3 switch must have an L3 interface for each participating VLAN or a route through another router. What matters is not simply whether the VLAN exists, but whether there is a route from the NVR network to the camera network and a valid return path.

For a camera in 192.168.20.0/24 and an NVR in 192.168.40.0/24, both of the following conditions must be met:

• the NVR VLAN has a route to 192.168.20.0/24;
• the camera's response to the NVR address returns through the correct gateway and does not leave through another route.

If multiple routers, VPNs, or redundant gateways are used, verify the return route separately. Asymmetric routing can interfere with a stateful firewall.

3. Test L3 Connectivity Before Configuring the NVR

It is usually easier to perform diagnostics from a device in the NVR VLAN or by using the router's own diagnostic tools. If the NVR provides built-in diagnostics, they can also be used, but availability depends on the manufacturer.

Check the following in order:

1. whether the camera VLAN gateway is reachable;
2. whether there is a route to the camera's IP address;
3. whether traffic passes through the required firewall rule;
4. whether the specific camera service required by the NVR is reachable.

A missing ICMP reply does not by itself prove that IP connectivity is unavailable: the camera or firewall may block ICMP. The final test should therefore use the TCP or UDP service that the NVR actually relies on.

4. Create Minimal Inter-VLAN Rules

For most rules, the correct direction is from the NVR to the cameras. The NVR usually initiates the connection to the camera to receive a stream or manage the device. If the firewall tracks connection state, return traffic for an allowed connection is handled according to its stateful filtering model.

Do not mechanically copy port numbers from third-party instructions. Ports used for the web interface, media stream, proprietary protocol, and discovery services depend on the camera, NVR, and their configuration.

If the NVR has multiple network interfaces, verify which IP address it actually uses to initiate the connection. A rule allowing one NVR address will not work if the request leaves through another interface.

5. Identify the Camera Services Actually in Use

The required protocols should be taken from the documentation for the specific camera and NVR. In practice, different systems may use direct media-stream connections, ONVIF, or a proprietary vendor protocol. Even when the same standard is supported, the exact device-addition procedure may differ.

If the NVR documentation specifies an IP-based connection with separate fields for the port, protocol, username, and password, use those exact values. Do not open the entire TCP/UDP range simply because the required ports are not yet known.

If reliable documentation is unavailable, a safe way to determine the required permissions is to temporarily enable firewall logging for blocked traffic from the NVR address to one specific test camera. After attempting the connection, review which connections are being blocked. This makes it possible to inspect actual traffic without guessing port numbers.

6. Account for Camera Discovery Across VLANs

Automatic device discovery and a normal connection to a camera at a known IP address are different tasks. Some discovery mechanisms use broadcast or multicast traffic, which a router does not necessarily forward between VLANs like ordinary unicast traffic.

Therefore, if the NVR does not display a camera in automatic discovery but can successfully connect to it by IP address, this does not by itself indicate a routing problem.

First try adding the camera manually by IP. If automatic discovery across VLANs is a strict requirement, check how the mechanism works in the documentation for the devices being used. Do not enable multicast relay, broadcast relay, or similar features without understanding the specific protocol, because doing so expands the scope of service traffic propagation.

7. Add the Camera to the NVR by IP Address

After verifying routing and firewall rules, manually add one test camera. Enter its actual IP address, a connection method supported by the NVR, and an account with the required permissions.

Verify the result layer by layer:

1. the NVR establishes a connection to the camera address;
2. the camera authenticates successfully;
3. the NVR receives the video stream;
4. the stream remains stable for several minutes;
5. then add the remaining cameras in the same VLAN;
6. after that, test the next VLAN in the same way.

This sequence helps distinguish a network problem from incorrect credentials, an incompatible protocol, or incorrect stream parameters.

8. If the Camera Is Reachable from the NVR VLAN but the NVR Cannot Connect to It

In this case, do not immediately change the VLAN configuration. Check the firewall log and the NVR log. If the connection from the NVR reaches the camera and replies return successfully, the next likely causes are connection parameters.

• Incorrect camera username or password.
• An NVR connection protocol not supported by the camera is selected.
• An incorrect service port is configured.
• The NVR is trying to connect to the camera's old IP address.
• The camera limits the number of simultaneous connections.
• The firewall rule allows the management interface but blocks a separate media-stream connection.

The last case is especially important: successfully opening the camera's web interface does not prove that the NVR can receive video.

9. If Connectivity Works Only After Allowing All Traffic

Such a temporary rule should be used only as a diagnostic test in a controlled network. If video appears after all traffic is allowed between the NVR IP and one camera, routing is probably working, while the permanent rule is missing one or more required connections.

Restore the restrictive rules and inspect the blocked-traffic log during another connection attempt. Add only confirmed services. Do not leave a permanent rule such as “NVR VLAN → camera VLAN: any protocol, any port” unless there is a justified requirement for it.

10. Restrict Access from the Cameras Themselves

Segmentation is useful only when restrictions exist between segments. Cameras generally do not need unrestricted access to user computers, file servers, or other internal VLANs. Permissions should be based on the architecture actually in use.

Also determine whether the cameras need DNS, NTP, and access to external vendor services. These requirements depend on the model and enabled features. If cloud functionality is not used, verify the need for Internet access against the device documentation and your security policy rather than assuming it is required.

It is safer to administer cameras from a dedicated administrative segment instead of exposing their management interfaces to all workstations in the organization.

Verify the Result

The configuration can be considered complete when the NVR continues to receive video reliably after both the camera and recorder are rebooted, without requiring a broad allow rule between VLANs. Also verify that a user device in a segment that is not permitted to access the cameras cannot connect to their services.

If the system works only until a reboot, check whether camera addressing is persistent: use the permanent addressing mechanism supported by your network and make sure the NVR always connects to the current IP address.

Final Checklist

• Each camera has the correct IP address, subnet mask, and gateway for its VLAN.
• The NVR has the correct IP address, subnet mask, and gateway.
• Routing exists between the NVR subnet and the camera subnets.
• The return route from the cameras to the NVR has been verified.
• The firewall allows connections from the NVR IP to the camera IPs only for the required services.
• Port numbers are taken from the documentation for the specific equipment or confirmed through traffic logs.
• One camera has first been tested manually by IP address.
• Failed automatic discovery is not used as the only test of network reachability.
• Authentication and video-stream delivery have been tested separately.
• The cameras do not have unnecessary access to user or server VLANs.
• After the equipment is rebooted, the NVR reconnects to the cameras.
• Temporary diagnostic rules with broad permissions have been removed.

Sources

This guide does not use version-dependent commands or vendor-specific parameters. Web search and current vendor documentation are not available in the current environment, so unverified links to ONVIF, NVR vendors, camera vendors, or networking equipment manufacturers are intentionally omitted. Exact service ports, cross-VLAN discovery behavior, and firewall rule syntax should be verified against the official documentation for the specific models and current software versions in use.