How to Isolate IP Cameras from the Internet While Keeping NVR Access

To isolate IP cameras from the internet while preserving recording to the NVR, place the cameras in a separate VLAN or a physically separate segment, allow only the necessary communication with the NVR and local services, and block routing from the camera network to external networks. The policy must cover both IPv4 and IPv6, as well as all network interfaces on the cameras. Simply removing DNS or the gateway, or assigning a different subnet, is not sufficient.

Recommended topology

For a home or small business system, it is convenient to divide the network into at least a user segment, a camera segment, and, when stronger security is required, a separate NVR segment.

USER_NET — computers and mobile devices;
CAMERA_NET — IP cameras only;
NVR_NET — a separate recorder segment when strict isolation is required;
a router or firewall controls communication between the segments;
routing from CAMERA_NET to the internet is blocked for both IPv4 and IPv6;
only required traffic from CAMERA_NET to the NVR and selected local services is allowed;
administrative access to cameras is allowed separately.

Example IPv4 addressing:

USER_NET:    192.168.10.0/24
CAMERA_NET:  192.168.20.0/24
NVR_NET:     192.168.30.0/24
Cameras:     192.168.20.101-192.168.20.150
NVR:         192.168.30.10
Camera GW:   192.168.20.1

These addresses are for illustration only. Isolation is provided not by the IP address ranges themselves, but by correct L2/L3 segmentation and routing and filtering rules.

Step 1. Determine the NVR architecture

First, determine exactly how the cameras connect to the recorder. This affects where internet access can be reliably blocked.

NVR with built-in PoE ports

On some recorders, the PoE ports form an internal network separate from the NVR's primary LAN interface. However, having different subnets alone does not prove that the cameras are isolated from the internet.

A particular NVR may perform routing, proxying, or other forwarding between the internal PoE segment and its external interface. You therefore need to check the documentation for the specific model and verify the device's actual behavior.

After connecting a camera to a PoE port, check:

which IP address, gateway, and DNS settings the camera receives;
whether the NVR's internal PoE interface has a route to the external network;
whether the NVR can forward camera traffic through its primary interface;
whether external connections are observed from the cameras or from the NVR acting on their behalf.

Cameras connected to a regular switch

If the cameras are connected to shared Ethernet infrastructure, create a separate VLAN or use a physically separate switch. Assigning addresses from different subnets without VLANs does not provide isolation: the devices may still be in the same broadcast domain.

Step 2. Create a separate VLAN for cameras

On a managed switch, assign the cameras to a separate VLAN. A typical configuration follows this logic:

camera port — access or untagged in CAMERA_NET;
uplink to the router or L3 switch — trunk or tagged;
an NVR in a separate segment communicates with the cameras through the router or firewall;
administrative workstations receive access to CAMERA_NET only through separate rules.

The terms access, trunk, tagged, and untagged vary by vendor, so the exact port configuration should be checked against the switch documentation.

Why it is better to place the NVR outside the camera VLAN

If the NVR is in the same VLAN as the cameras, their traffic usually passes directly through the L2 switch and does not traverse the firewall. This is convenient, but it also means that a compromised camera has network reachability to the NVR within the shared segment.

For a stricter security model, place the NVR in a separate VLAN and allow only the required CAMERA_NET → NVR communication. An alternative may be possible if the switch supports suitable L2 port isolation or ACLs, but the behavior of such mechanisms depends on the hardware and must be verified separately.

Step 3. Assign predictable addresses

Static IPv4 addresses or DHCP reservations are suitable for cameras. Predictable addressing makes rule creation and troubleshooting easier.

192.168.20.101  camera-entrance
192.168.20.102  camera-yard
192.168.20.103  camera-garage
192.168.30.10   nvr

If DHCP is used, create a separate pool for CAMERA_NET. With a static configuration, the IP address, gateway, and DNS settings are configured directly on the camera and are not changed by the DHCP server as long as the device actually remains in static mode.

The risk of settings changing arises in other cases: the camera may be switched back to DHCP, reset to factory defaults, or receive a new configuration after replacement or reinitialization. Therefore, the absence of a gateway on the camera itself should not be treated as the only protection mechanism.

Step 4. Block internet access over IPv4

The main policy should be enforced on the device that routes CAMERA_NET traffic.

Abstract logic:

CAMERA_NET -> NVR_NET               ALLOW
CAMERA_NET -> required LAN services ALLOW
CAMERA_NET -> other LAN networks    DENY
CAMERA_NET -> external networks     DENY

These are not ready-to-use commands for a specific firewall. The actual implementation depends on the platform, rule order, stateful model, default policy, and how the device defines WAN.

It is especially important to check rule processing order. If a broad allow rule such as CAMERA_NET → ANY appears above the deny rule, the later DENY may never be reached. On a stateful firewall, existing connections must also be considered: after changing the policy, you may need to wait for them to expire or clear the relevant states using platform-specific tools.

A “CAMERA_NET → WAN DENY” rule is effective only when you clearly understand which interfaces and routes are considered external and have checked IPv4, IPv6, rule order, existing states, and alternative interfaces on the cameras themselves.

Step 5. Do not forget IPv6

Blocking only IPv4 does not guarantee isolation. If a camera receives a global IPv6 address and a default route, it may potentially reach external networks independently of the IPv4 policy.

For CAMERA_NET, choose one of two approaches:

completely disable IPv6, Router Advertisement, and DHCPv6 in this segment if IPv6 is not needed there;
or configure separate IPv6 firewall rules that block camera routing to external IPv6 networks and allow only the required local destinations.

Do not limit your checks to the presence of an IPv4 gateway. Make sure the camera has not received an IPv6 default route and a global address that could bypass the IPv4 policy.

Step 6. Check alternative camera interfaces

A VLAN network policy applies only to the interface that is actually connected to the controlled infrastructure. Some cameras may have additional communication paths: Wi-Fi, a second Ethernet port, a cellular modem, or another external interface.

If complete isolation is required, unnecessary interfaces must be disabled in the device settings or separately included in the controlled network policy. A camera connected by Ethernet to CAMERA_NET while simultaneously having active Wi-Fi access to another network is not isolated.

Step 7. Restrict access to the local network

Blocking internet access should not leave cameras with unrestricted access to all internal devices.

Example policy:

CAMERA_NET -> NVR_NET         ALLOW
CAMERA_NET -> USER_NET        DENY
CAMERA_NET -> SERVER_NET      DENY
CAMERA_NET -> MANAGEMENT_NET  DENY
CAMERA_NET -> external networks DENY

If a camera needs local DNS, NTP, or another service, allow only the specific destination address and required protocols. Do not open the entire CAMERA_NET to a server segment just to provide one service.

Step 8. Allow users to access the NVR

Regular client devices should preferably communicate with the NVR rather than connecting directly to every camera.

USER_NET -> NVR_NET      ALLOW
USER_NET -> CAMERA_NET   DENY

For camera configuration, you can create a separate allow rule from the management segment or from a specific administrative host. This reduces the number of devices that can directly access camera interfaces.

Step 9. Configure required local services

DNS

If the cameras do not need to resolve local names, DNS does not have to be provided. If it is required, allow access only to the local DNS server. The absence of DNS does not itself block internet access because a device can connect directly to a known IP address.

NTP

Accurate time is important for recordings and events. After internet access is blocked, external NTP will stop working. If the camera supports manually specifying a time server, use a local NTP source that is actually reachable in your infrastructure.

Cloud features

P2P access, cloud storage, vendor push notifications, and automatic update checks may depend on external services. If the cameras must be fully isolated, expect these features to stop working unless the documentation for the specific system describes a different mechanism through the NVR.

Step 10. Account for camera discovery

Automatic device discovery may use broadcast or multicast traffic, which normally does not route between VLANs without additional mechanisms.

If the NVR stops discovering cameras automatically after they are moved to a separate segment, this does not mean routing has failed. If the recorder supports it, add cameras manually by IP address. Do not enable broadcast relay, multicast relay, or similar features without understanding the specific protocol being used.

Step 11. Verify actual isolation

Testing must confirm both that video surveillance continues to work and that external connectivity is unavailable.

Make sure the NVR receives video streams from all cameras.
Verify that recording continues after the rules are applied.
Verify user access to the NVR.
Make sure regular client devices cannot access CAMERA_NET if the policy prohibits it.
Check firewall rule counters: deny rules should show actual hits when cameras attempt to reach external destinations.
Review the firewall log if the platform logs these rules.
Check the firewall connection or state table and make sure there are no allowed external connections originating from the cameras.
If the specific camera model provides network diagnostics, use them to verify that an external address is unreachable without changing the permanent configuration.
Check IPv6 separately: verify the absence of an allowed external route and external connections.
Reboot one camera and repeat the verification after it obtains its network settings.

A firewall log is useful but is not the only evidence. A camera may not attempt any external connection while you are reviewing the log, and logging may be disabled. A more reliable verification combines rule counters, the state table, device network parameters, and, where possible, an active test using the camera's own diagnostic tools.

What should not be used as the only protection mechanism

Missing default gateway

With a static configuration, a camera without a gateway will generally be unable to communicate beyond its IP subnet. However, this is a local device setting, not a centralized policy. It can change after manual reconfiguration, switching to DHCP, or a factory reset.

Removing DNS

DNS resolves names and does not prevent connections to known IP addresses.

Blocking only vendor domains

Such a list may be incomplete and may change. Blocking external routing for the entire segment is easier to control and verify.

Different IP subnets without VLANs

Different address ranges do not create proper L2 isolation. You must actually separate broadcast domains and control routing between them.

Passwords without segmentation

A password protects the camera interface from unauthorized login, but it does not restrict the camera's own network connections or reduce the network reachability of other devices.

If the NVR must have internet access

The NVR and cameras can have different policies. External routing can be completely blocked for the cameras while the NVR is allowed only the internet access required for selected functions.

CAMERA_NET -> external networks DENY
NVR_NET -> external networks    according to a separate policy

You must also consider the risk that the NVR itself may act as an intermediary between the cameras and the internet. This is especially important for models with built-in PoE ports. Check whether the recorder performs routing, NAT, proxying, or forwarding of camera cloud traffic through its external interface.

Final checklist

cameras are placed in a separate VLAN or physically separate segment;
the NVR is placed in a separate network where possible, or L2 access from cameras to it is restricted using switch features;
IPv4 access from CAMERA_NET to external networks is blocked;
IPv6 is either disabled in CAMERA_NET or protected by separate rules;
RA, DHCPv6, and the presence of an IPv6 default route have been checked;
unnecessary Wi-Fi, additional Ethernet, and other external camera interfaces are disabled or controlled;
cameras are allowed only the required access to the NVR and local services;
CAMERA_NET access to user, server, and management networks is denied by default;
firewall rule order, default policy, and stateful behavior have been checked;
rule counters, logs, and the connection table confirm that no external traffic is being allowed;
isolation remains in effect after a camera reboot;
for NVRs with built-in PoE ports, the absence of camera routing or proxying to the internet has been verified separately.

Specific commands depend on the router, firewall, switch, and NVR model, so providing them without knowing the platform would be unreliable. The verifiable principle remains the same: all camera network paths must pass through controlled infrastructure, local access must be limited to what is strictly necessary, and external routing must be explicitly blocked for both IPv4 and IPv6.