Best Practices: Networking For Verkada Devices

Simplicity and ease of use might be some of the core principles based on how we architect Verkada products, but this does not mean one should forgo best practices when it comes to designing and securing the supporting network.

By following our networking best practices, teams can take the steps to deliver a system that will remain performant, scalable and, most importantly, safe from external threats.

In this blog post, we will be focusing on how to achieve this for Verkada cameras, however, many of these same steps can also be applied to our access control and cloud-based sensor solutions.

Powering and Connecting the Devices

All Verkada cameras require a wired Ethernet connection to supply Internet connectivity and power. The latter is provided either by the upstream switch or by a power injector, supporting the 802.3af PoE standard (cameras deployed in very cold environments will need extra power in order to utilize their built-in heater, thus requiring 802.3at PoE+).

If not supplied with enough power, the cameras will not be able to operate properly (if at all), so we recommend checking the switch power budget before deploying and ordering additional PoE injectors in case of insufficient power.

If you are replacing legacy analog cameras, it might not be financially feasible to re-cable the entire building. These coaxial cables can still be used as transport by adding a converter at each end.

IP Addressing and Subnetting

Once cameras receive power, they will request an IP address via the DHCP protocol. The request will travel upstream to the switch (with the port configured as access), and from there be directed to the DHCP server. If fixed IP addresses are desired, that would be the right place to create these reservations (by matching an IP with a camera’s MAC address).

We strongly recommend carving out a separate VLAN for the Verkada cameras, and not keep them together with corporate or other guest devices. This design not only guarantees the performance of the system (VLANs break up the broadcast domain into smaller independent segments), but also adds an additional layer of security to your network. By imposing strict Access Control Lists (ACLs) between the camera and the rest of the VLANs, you can limit an attacker’s ability to discover and compromise the entire network.

By default, Verkada cameras only communicate with the Internet, so there is no need for inter-VLAN communication. The only case where it’s required is for Local Streaming when viewing footage from the same location. Local streaming saves ISP bandwidth by creating a communication link directly between the end device and camera, and it will do so using TCP 4100 (this port will need to be opened, bidirectionally, in the inter-VLAN ACL).

In order to secure the physical switch port, we recommend using 802.1x RADIUS and setting up MAC Based Authentication (MBA). This will stop perpetrators from taking out a camera cable and plugging in their own device, and thus compromise the camera VLAN.

Firewall Settings

As previously mentioned, except for Local Streaming, the Verkada cameras only communicate with specific domains on the Internet and are designed to open up outbound communication as soon as they are powered on and receive an IP address. This is one of the many security benefits of the Verkada system, as we do not require you to configure port forwarding on your firewall, which would create an opening that can be exploited by malicious actors.

The cameras only use two well-known ports to communicate, namely HTTPS (TCP port 443) and NTP (UDP port 123). As a best practice, allow only these ports and the specific URLs through your firewall. If either of the above ports or domains are blocked, the camera will not work properly, and its LED will be stuck on Orange or flashing Blue.

Certain firewalls, either on-premise or cloud-based, are able and set to inspect the encrypted communication that happens via HTTPS, by becoming a so-called ‘man-in-the-middle’ and effectively brokering the communication between source and destination. This feature, known as SSL Decrypt, will not allow the cameras to communicate with the Verkada cloud, thus must be switched off for traffic initiated from the camera VLAN. The cameras will only accept genuine Verkada certificates when initiating the encrypted management tunnel.

Bandwidth Considerations

The Verkada system is designed to demand very few resources from the underlying network and provide a good remote viewing experience. However, one must understand what upload bandwidth a camera requires while operating, especially when dealing with large deployments or sites with restricted WAN bandwidth.

Camera traffic is split between the metadata it sends to the cloud at rest (between 20-50 Kbps, going upwards to 100+ kbps for busy scenes when advanced analytics such as face search are turned on), and the actual video stream when someone is watching it or the camera backs it up into AWS (around 600 Kbps for SD, 1.5 Mbps for HD, and between 2-3 Mbps for 4K).

A few steps can be taken in order to conserve WAN bandwidth, including making sure Local Streaming works (as described above, by opening TCP 4100 between your camera and end device VLANs), scheduling Cloud Backups outside working hours, defaulting all stream viewing quality to SD, and disabling advanced analytics.

Sites might differ in the way they can reach the Internet, with Direct Internet Access (DIA), private links (such as MPLS) leading to a centralized breakout, or a mixture of the two. If using both public and private WANs at a particular location, we recommend setting up routing policies to prefer the former, and use the latter just as a backup.

Time Sync and Firmware Upgrades

Verkada uses its own servers to synchronize the time on the cameras, thus there is no need to use your own infrastructure for this. The time zone on each camera will automatically be set based on the physical address field, found in the Information tab.

Similarly, no action is required from the admin in order to keep the cameras up to date, as the upgrades are delivered over-the-air (OTA) automatically. The devices will download the firmware while operating, and reboot for a few seconds in order to apply it. Dual partition memory banks allow the camera to continue using the old firmware in case of a failure, and random variables inserted in the process will make sure the cameras at a particular location don’t reboot at the same time.

System Alerts

One of the most frustrating moments occurs when an incident happens, and the security team finds out that the camera surveying that particular location has been offline for months, without anyone realizing it. With Verkada, we are striving to avoid such situations, by easy-to-configure system alerts.

Besides camera status updates, the system also alerts when someone is trying to tamper with the camera (via the in-build accelerometer) if someone or something is moving in a particular area at a certain time, when certain persons of interest are spotted across the estate, or when a crowd of people is spotted in the frame.

Looking For a Deeper Dive?

We have built a Networking Best Practices Guide to provide you and your team with all the information needed for setting up and securing your network with Verkada physical security.