How to Isolate Security Cameras on a VLAN

1. What a camera VLAN protects

Cameras are always-on embedded computers with microphones, video, network services, and long replacement cycles. A dedicated VLAN limits what a compromised or misconfigured camera can reach. It also makes the intended traffic visible: video should flow to the recorder, not wander across the primary LAN.

A VLAN creates a separate Layer 2 broadcast domain. The firewall or router creates the security boundary. Assigning a VLAN ID or a different Wi-Fi name without inter-VLAN firewall rules does not provide meaningful isolation.

2. Design the network and trust boundaries

Use distinct address space so routes and logs are easy to recognize. This example keeps cameras on VLAN 30:

Trusted LAN — VLAN 10 — 192.168.10.0/24
  admin workstation
            │ tightly scoped management access
            ▼
      stateful firewall/router ─── WireGuard ─── LightNVR
            │                           │
            │ RTSP from recorder only  │
            ▼                           │
Camera LAN — VLAN 30 — 192.168.30.0/24 ◀┘
  .21 front door   .22 driveway   .23 garage
  no primary-LAN access; no internet by default

Plan these pieces before changing a port or SSID:

• VLAN ID and subnet: for example VLAN 30 and 192.168.30.0/24
• Gateway and DHCP scope: for example 192.168.30.1 and .100–.199
• Reservations: stable addresses for every camera and the optional WireGuard gateway
• Wireless SSID: a camera-only SSID mapped to VLAN 30
• Wired ports: untagged access ports for cameras; a tagged trunk only between VLAN-aware infrastructure
• Management source: ideally one admin workstation, not the entire trusted LAN

3. Build a least-privilege firewall policy

Start from deny and add the paths you can name. In a stateful firewall, place specific allows before broad denies:

DHCP commonly uses UDP 67/68, DNS uses UDP and TCP 53, and NTP uses UDP 123. Prefer the router as the camera VLAN’s DNS and time service. If firmware updates require internet access, create a temporary, logged rule for the required destination and remove it afterward.

4. Configure the router, Wi-Fi, and switch

1. Create the camera VLAN interface and gateway address on the router.
2. Create its DHCP scope and router-local DNS/NTP allowances.
3. Create the firewall rules from the previous section, including an explicit final deny from cameras to other private networks.
4. Map a camera-only SSID to the VLAN. Enable wireless client or AP isolation if cameras do not need to communicate with one another.
5. For wired or PoE cameras, carry the VLAN over a tagged trunk from router to managed switch.
6. Configure each camera-facing switch port as an untagged access port in the camera VLAN. The camera itself normally sends ordinary untagged Ethernet.

A trunk carries multiple tagged VLANs between a router, managed switch, and VLAN-aware access point. An access port carries one untagged VLAN to an endpoint. Mixing those roles is a common reason a migrated camera disappears.

5. Asuswrt-Merlin implementation notes

Asuswrt-Merlin follows two materially different firmware families. Check your router model and firmware version before following menu names.

Merlin 3006.102 on a supported model

Merlin’s 3006 release notes identify VLAN and Guest Network Pro (also called a self-defined network or SDN) as supported 3006 features. On current ASUS interfaces:

1. Open Network or Guest Network Pro and create an IoT/custom network with its own subnet and DHCP scope.
2. Under Network → General → Access Intranet, uncheck or disable the primary network.
3. Disable internet access for the camera network if the profile exposes that control. Access Intranet off does not itself mean internet off.
4. For wired cameras, open LAN → VLAN. Assign a router port as an access port for the camera profile, or use a tagged trunk to a managed switch.
5. Add the narrow WireGuard-to-camera allowance and admin exception. Confirm they do not accidentally grant the whole camera network access to the primary LAN.

ASUS notes that a VLAN-only profile has a VLAN ID but no DHCP; creating the network through Guest Network Pro/SDN provides the routed network services most camera deployments need.

Merlin 3004.388 or models without VLAN support

An isolated ASUS guest SSID with Access Intranet: Disable is useful for wireless cameras, but it is not equivalent to the 3006 wired VLAN and SDN workflow. Custom shell scripts built around bridge names, wireless BSS names, and NVRAM variables are chipset- and model-dependent and can break after firmware changes.

If you need a durable camera VLAN across Wi-Fi and PoE ports, use a router/firewall with supported VLAN interfaces and policy rules, or move to a model in the current Asuswrt-Merlin supported-device list that runs 3006.102. Keep the old administration path working until the replacement policy is tested.

6. Preserve LightNVR and WireGuard access

VLAN isolation and VPN encryption solve different problems. The VLAN controls local reachability; WireGuard carries the permitted recorder traffic privately to LightNVR. You need both a route and a firewall allowance.

1. Configure the site WireGuard peer with the camera subnet, such as 192.168.30.0/24, on the correct side of the tunnel routing policy.
2. Allow the LightNVR tunnel address or tunnel subnet to initiate TCP connections to the reserved camera IPs on port 554.
3. Do not expose RTSP with WAN port forwarding, UPnP, or a public camera web interface.
4. If the WireGuard gateway sits inside the camera VLAN, allow that one gateway to reach its configured WireGuard endpoint and DNS/NTP. Keep the same outbound access denied for ordinary cameras.
5. Use explicit RTSP URLs in LightNVR; do not depend on cross-subnet discovery.

See Set Up WireGuard with Home Routers and LightNVR for the tunnel workflow.

7. Migrate one camera at a time

1. Export or record the existing switch, SSID, DHCP, camera, and LightNVR settings.
2. Keep your current admin device on a known-good management path. Do not reassign the port through which you are configuring the router.
3. Create all VLAN, DHCP, routing, and firewall objects before moving a camera.
4. Move one non-critical camera to the new SSID or access port.
5. Find its new reserved IP and test its Web UI and RTSP locally from the allowed admin workstation.
6. Update the RTSP URLs in LightNVR, test both streams, and verify a completed recording.
7. Restart the camera and WireGuard gateway, test again, and only then move the next camera.

Thingino users should expect the normal endpoints /ch0 and /ch1. Use the Thingino camera guide to validate them before and after migration.

8. Prove the isolation

Test every intended allow and deny. A diagram is only a claim until packet flow agrees with it.

From the allowed admin workstation

nc -vz 192.168.30.21 554
curl --connect-timeout 5 http://192.168.30.21/

From LightNVR through WireGuard

• Confirm the WireGuard peer has a recent handshake and increasing transfer counters.
• Use Test Connection on the camera’s exact RTSP URL.
• Verify live view and play a recording after its segment closes.

From a temporary test device on the camera VLAN

• Confirm DHCP, router DNS, and NTP work.
• Confirm access to primary-LAN hosts and router administration is blocked.
• Confirm ordinary internet access is blocked when that is your policy.
• Confirm another camera IP is unreachable if client isolation is enabled.

Ping alone is not a sufficient test because many firewalls treat ICMP separately. Probe the actual TCP services, inspect firewall logs, and re-run the checks after a router reboot.

Primary references

• ASUS: deny guest devices access to the internal network
• ASUS: VLAN profiles, access ports, and trunk ports
• Asuswrt-Merlin 3006 release notes
• NIST SP 1800-15: network segmentation and IoT security