CCTV VLAN Design: Camera, Recorder and Operator Traffic Rules

For most commercial CCTV systems, put cameras in a dedicated VLAN, allow the recorder or video management system (VMS) to reach the services it needs, and give operators access through the approved viewing platform. Block unrelated office and guest access. Where a VMS sends live video directly from cameras to clients, add a narrowly scoped exception for that documented path.

A VLAN separates a network into logical segments. It does not, by itself, decide which routed connections are permitted. The security boundary depends on correctly placed firewall rules or access control lists (ACLs), supported switch configuration and secure management.

This guide gives NZ security installers and integrators a design and commissioning framework. The traffic matrix is a starting policy, not a universal port list or a configuration to paste into an existing network. Agree the final design with the customer's IT administrator and use the documentation for the installed camera, recorder, VMS and firmware.

Start with the CCTV traffic paths

Before assigning VLAN numbers, identify who connects to whom. A recorder collecting camera streams, an operator playing back an incident and an engineer changing switch settings perform different jobs. They should not automatically receive the same network access.

Record the following for each required connection:

• Source device or approved address group.
• Destination device or service.
• Which endpoint initiates the session.
• Protocol, destination port and any negotiated media range.
• Whether the connection is permanent, scheduled or temporary.
• Business purpose, owner and commissioning test.

Session initiation matters. A recorder may initiate a stream request while most video bytes travel back from the camera. An alarm event or callback can be a separate camera-initiated session. Write rules from the actual protocol behaviour, rather than assuming that the direction of the picture identifies the connection initiator.

Choose where cameras and recorders belong

Option 1: Cameras and recorder share a CCTV VLAN

This can simplify a small installation. Recording traffic remains within the segment, while operators connect across a controlled boundary to the recorder. However, a firewall between the CCTV VLAN and the office network does not normally inspect communication between devices inside that same VLAN.

A compromised camera may therefore have local reachability to other cameras or the recorder. Where the switch supports suitable isolation or local ACLs, these can reduce that exposure. Confirm that any isolation preserves the recorder uplink and required services before enabling it.

Option 2: Cameras and recording servers use separate VLANs

Separating the camera and server networks allows an enforcement point to control their communication. It also puts recording traffic through that point. Size the route, interfaces and security processing for sustained camera traffic, operator demand and other authorised workloads.

This design is useful when the customer needs a clearer boundary around recording servers. It adds configuration and an operational dependency: failure of the routed path can interrupt recording even while cameras and servers remain powered.

Option 3: Cameras connect to a recorder's built-in PoE ports

Some recorders provide an internal camera network separate from the customer-facing LAN interface. Its addressing, camera access and forwarding behaviour depend on the exact model. Do not assume those ports provide configurable IEEE 802.1Q VLANs, or that the recorder can act as a general router.

Likewise, two network interfaces on a server do not prove isolation. Check supported interface use, routing, bridging and host firewall settings. Avoid creating an unintended path between the camera network and the business LAN. The AXIS Camera Station system hardening guide provides a manufacturer-specific reference; other platforms need their own documentation.

An example VLAN and subnet plan

The following is a hypothetical design, not a mandatory numbering scheme. Confirm that all proposed ranges are unused locally and across any connected site VPNs.

Guest and general office devices stay outside these groups. A VLAN number is an identifier, not an IP address or a security rating. Allocate addresses, masks and gateways through the customer's IP plan; document reservations or static assignments so later replacements do not introduce duplicate addresses.

For suitable infrastructure, review the managed PoE switch range. Select against the required VLAN, ACL, uplink and management features of the individual model, rather than the collection name alone.

Camera, recorder and operator traffic rules

Use default-deny between security zones, then add documented exceptions. The matrix below is a proposed policy for a conventional on-premises design. Cloud-connected systems and direct client streaming require different exceptions.

On a stateful firewall, permitted session responses are generally handled by connection tracking. Stateless ACLs may require explicit return rules. Confirm the behaviour of the actual enforcement device before translating this matrix into configuration.

Apply the policy to every active routed path, including IPv6 where enabled. A well-controlled IPv4 path does not establish that an alternative path is equally restricted. Cisco's VLAN security guidance explains the need for access restrictions when routing between VLANs.

Build a port schedule for the installed platform

There is no single CCTV port list that covers every manufacturer's recording, events, playback and remote access. Record the software version and enabled features beside the source document used to create each rule.

For illustration, the AXIS OS hardening guide identifies HTTPS management and RTSP streaming services, including TCP 443 and TCP 554 in its port guidance. Those examples do not prove that another camera uses those ports, that those services are enabled, or that allowing them is sufficient for a complete VMS installation.

Separate encrypted administration from media transport. Using HTTPS for a web page does not establish that every video connection is encrypted. Verify the negotiated stream transport and the security capabilities supported by both endpoints.

If RTSP negotiates UDP media, opening only the RTSP control connection may leave live video unavailable. Document the actual media range or a supported TCP transport choice. The AXIS Camera Station 5 manual is one example of platform-specific server and client port documentation, not a substitute for a different VMS manual.

Cloud architectures can be different again. Verkada's networking guidance describes direct local client-to-camera streaming for its platform. This illustrates why an operator-to-camera deny rule must be checked against the selected system before commissioning.

Configure access ports, trunks and management deliberately

A camera that sends untagged Ethernet traffic will normally use an access port assigned to its camera VLAN. An inter-switch link carrying multiple VLANs needs compatible tagged VLAN configuration at both ends. Document any untagged or native VLAN behaviour and allow only the VLANs that link actually needs.

Do not assume a switch's physical “VLAN” or “CCTV” mode provides configurable 802.1Q tagging. Read the manufacturer's feature description. For example, Provision-ISR's PoES-24370GCL+2SFP page lists automatic VLAN/CCTV modes; this alone is not evidence that the device implements the managed trunk and ACL design above.

Restrict switch administration to the management path. Disable unused ports where operationally appropriate, label active ports and retain a configuration backup. A spare live camera-network socket should be treated as an access point into that segment, even if it is inside a locked cabinet.

The non-PoE switch range may be relevant to server or operator connections, but each chosen switch still needs the features specified in the design.

Plan bandwidth and failure behaviour together

Illustrative calculation: 24 cameras at an assumed 6 Mb/s each produce 144 Mb/s of video payload towards recording. This is arithmetic using an assumed stream rate, not a measured installation result or a recommended uplink capacity.

Allow separately for protocol overhead, bitrate variation, additional streams, playback, exports and growth. Determine which traffic shares each link and whether routing makes the firewall a recording bottleneck. A VLAN does not reserve bandwidth; QoS does not create additional capacity.

Also consider the failure boundary. If cameras and the recorder share a local network, recording may continue during a failure elsewhere, provided their local switching and power remain available. If their traffic crosses a failed firewall, it may stop. Edge recording and later retrieval depend on supported camera storage, VMS features and configuration; do not promise automatic recovery without testing it.

Commission the restrictions as well as the pictures

Back up the existing configuration and agree a change window, rollback method and success criteria before moving a live site. For an NZ commercial customer, include the people responsible for after-hours monitoring and remote maintenance in that plan.

1. Confirm camera addressing, port VLAN membership and trunk configuration with one representative camera before migrating the fleet.
2. Add the camera by supported addressing methods. Discovery can fail across subnets even when a permitted unicast connection works. Microsoft's ONVIF camera guidance documents local-subnet discovery constraints for its Windows implementation.
3. Verify recording, live view, playback, export, PTZ, audio and events for every feature actually included in the project.
4. Test from an operator account and workstation, rather than relying only on an administrator's session.
5. From authorised test devices, confirm guest and ordinary office access is denied. Check firewall logs or rule counters as well as the user-visible result.
6. Verify that the administration path works and that an ordinary operator cannot use it to change infrastructure settings.
7. Test the agreed remote-access method from outside the site. Avoid exposing camera management directly through ad hoc public port forwarding.
8. During an approved outage test, check the specified recording behaviour, service recovery and time synchronisation. Confirm NZ local time and daylight-saving display settings alongside the underlying time source.
9. Remove temporary permissive rules, retest the same workflows and save the final configuration and results.

If a camera goes offline after migration, compare its address, mask, gateway, VLAN and required services before widening access. The IP camera offline troubleshooting guide covers the wider power, cabling and recorder checks. Keep a known-good reference so a failed test can be repeated after each change.

What to include in the handover

Provide a VLAN and subnet schedule, labelled port map, current topology, rule register, model and firmware list, configuration backup location and recorded test results. Identify who approves future exceptions and who responds when a network change interrupts recording.

Store credentials in the customer's approved secure system, rather than embedding them in the general handover document. Give temporary contractor access an owner and expiry. Recheck the traffic schedule after changing VMS software, enabling analytics or adding a cloud service, because a previously sufficient rule set may no longer match the installation.

Frequently asked questions

Does a camera VLAN stop office users accessing CCTV?

Not by itself. Access between routed VLANs must be restricted by firewall rules or ACLs. Test the policy from an ordinary office workstation and check every active network path.

Should cameras and the recorder be in separate VLANs?

Separate VLANs allow a controlled boundary between cameras and recording servers. A shared CCTV VLAN can simplify a small system, but local traffic may bypass the inter-VLAN firewall. Choose according to the security requirement, throughput and failure plan.

Why does the camera web page work but live video fails?

Management and media can use different connections. Check the VMS documentation, stream transport and negotiated media ports. Successful web access does not prove that recording or live-view traffic is permitted.

Can operators be blocked from connecting directly to cameras?

Often, but confirm the VMS architecture first. Some systems require direct client-to-camera streams. Permit only the documented sources, destinations and services needed for the installed platform.

Do cameras need internet access to record locally?

A conventional local recording design may operate without camera internet access. Cloud services, licensing, updates and remote access can have additional dependencies. Verify the installed platform and test the agreed offline behaviour before applying an internet deny rule.

Specify the network before ordering hardware

Prepare the camera count, stream assumptions, required VLAN and ACL features, uplink design, PoE loads and recording architecture before selecting switches. Discuss those requirements with Essential Security Supplies through your trade account or technical enquiry, and use the managed PoE collection to review relevant hardware specifications.