1

We’ve recently stumbled on the use of DHCP for automatically assigning phones to voice VLANs, and it’s been great…so I’m thinking of other devices that might have such options. Does anyone know of anything like this for security cameras? Mostly I’m asking about Avigilon but some of our sites use Axis, ACTi, or other brands, all of which probably have their own vendor-specific options and syntax…but if we could even just get Avigilon, that’d be a huge boon for us

Thanks!

Bonus: if there’s one to provide a host/server name/address to phone home to, that’d be another great one to have

4 Spice ups
2

A VLAN can be used for any device, regardless of what it is, assuming the port you plug it in to or the SSID you connect it to, is configured for it.

But are you asking about specific devices by brand being able to pick up a DHCP based on vendor?

2 Spice ups
3

@Rod-IT, the DHCP options we’ve run into with phones allow us to use DHCP to drop phones into the correct VLAN. This alleviates the need to untag a port, manually set a VLAN tag on-device, create a staging area to first get online then move to a new VLAN, set any options in the network controller, run LLDP or NAC…all of the other, more labor-intensive options we’ve used/considered in the past. Instead, the phones ask for a vendor-specific option of the DHCP server (I’ve set Polycom phones to 128, for example), and if the answer is properly formatted so they can understand it, they know to tag themselves into the right place, to then receive more DHCP info…including, sometimes, their controller address

I’m just wondering if we can do the same with security cameras, so we can avoid individually untagging those ports (or the other methods) as well

4

The Device would need to understand VLAN tagging for this. Most devices don’t. I think phones are an exception here.

4 Spice ups
5

This is what I was seeking clarification on.

There are limitations with DHCP options in this sense, and since neither camera or phones move a lot, if at all, wouldn’t static IPs make sense, especially if you have an application monitoring them all.

1 Spice up
6

@molan:

The Device would need to understand VLAN tagging for this. Most devices don’t.

The particular cameras in question do. I know not all do, which has been a source of annoyance in the past…and not all phones do either (at least, if we can trust our vendors)

@Rod-IT:

wouldn’t static IPs make sense

If we’re setting static IPs, we’d be able to put the VLAN in there (if supported), so it doesn’t really change the workflow appreciably. I’m just trying to see if there’s a way around that entirely. Avigilon in particular is cool with DHCP, and we have a particular project coming up involving cameras already using it, so I’m hoping we can smooth things out

7

All devices are ‘cool with DHCP’ it’s whether or not they are cool with DHCP with vendor options.

The only true way to know if your specific device supports this, is try it.

3 Spice ups
8

@Rod-IT

All devices are ‘cool with DHCP’

Sure, but not all devices are capable of performing their actual functions using DHCP…some need static IPs, as you’ve pointed out. I didn’t say “Avigilon cameras are capable of receiving DHCP addresses”, I said “Avigilon…” (as in the product) “…is cool with DHCP” (as in the cameras can report to the ACC even without static IPs…and I provided a citation for clarification)

The only true way to know if your specific device supports this, is try it.

I’m here to ask what to try, as brute forcing this is basically impossible. The two examples I know of this so far, both for Voice, are as follows (with VLAN 5 being the stand-in):

Yealink phones
Option: 132
Syntax: String
Value: 5

Polycom phones
Option: 128, 144, 157, or 191
Syntax: String
Value: VLAN-A=5;

Of course, those are both strings. If you want to tell UniFi devices where their controller is…
Option: 43
Syntax: Hex
Value: 8aec8024
(That resolves to an IP for a pool.ntp.org server, for this example)

So yeah…I’m here for direction, because just trying things out is not going to produce a usable result in my lifetime

9

I don’t understand why this would be desired. Do, you make every switch port a trunk port carrying all VLANs, and were manually setting the VLAN ID before, and now want to exclusively use DHCP to set the device VLAN?

This is a poor design from a security standpoint. You want to restrict a network port to only the uses that it needs to have. If it needs Phone and Computer, you set the Computer VLAN to native/untagged and tag the VOIP VLAN. VOIP phones with passthru ethernet already understand this, and will associate to the correct VLAN without any intervention. If there are only servers on that port, then only that VLAN. Only a PoE camera connected on that port - only give it that VLAN.

There are some handy DHCP options like setting TFTP servers for VOIP phones to get updates from, etc, but those are specific to that VLAN, and the DHCP scope for that VLAN should handle that.

3 Spice ups
10

@phildrew

There are some handy DHCP options like setting TFTP servers for VOIP phones to get updates from, etc, but those are specific to that VLAN, and the DHCP scope for that VLAN should handle that.

That’s after you get on the VLAN, yes, and my “Bonus” is basically what you’re talking about

This is a poor design from a security standpoint. You want to restrict a network port to only the uses that it needs to have.

In certain cases, the trade between security and usability is a worthwhile one. The risk of someone with the requisite technical expertise physically joining the network on any given trunk port, discovering the appropriate VLAN, having the necessary credentials to access the devices or their controllers, and messing with the system is great, but the likelihood is very small. On the other hand, the risk of a 3rd-party vendor/installer coming in and installing things “their way” in a problematic manner that creates other holes in the network that are much more easily exploited is both greater and more imminent. I want to not only expedite this particular project, but equip myself to be a shield against lackluster vendors in the first place by making it easier for them to comply with our security standards than to do it “the way we’ve always done it”

1 Spice up
11

Not really. Assuming you have DHCP relays on your network, the below command will return a bunch of useful information.

nmap --script broadcast-dhcp-discover

This will return all DHCP servers and their options, including VLANs and Vendor classes, giving the person running it the ability to choose their VLAN ID or Vendor class and be on that same network.

Credentials are not required here, unless you are using 802.1x but that would be another issue for some of the devices you mention.

I will concur this likely isn’t the best approach, but it’s your network, so I wish you will and will back out.

2 Spice ups
12

@Rod-IT and @phildrew, I do appreciate the prompt to consider the security implications. We’ve had those discussions, and at the moment have pinpointed that the biggest security problems with our networks have to do with 3rd-party vendors taking shortcuts for the sake of their own convenience, rather than working with us to harden their systems to keep our networks secure

To give you a sense…we have one in particular who frequently reminds me of the Kool-Aid main, wanting to smash holes into walls just so he can get his paycheck and leave. He doesn’t want to have to use a metaphorical keycard at the door like the rest of us…even if the system he’s installing is for keycards. I want to make it easier for him and others to use that keycard, so that they don’t complain or try to circumvent us

13

Well, if your intention is to fix third party security with DHCP, then more power to you.

I’ve never heard of this approach, so good luck!

1 Spice up
14

@alexwyatt , DHCP for security cameras do not work in most cases. The reason is that the NVR (network video recorder) reaches out to the cameras to pull streams from the cameras. (The cameras do not push their streams to the NVR’s). So if the camera’s IP address changes depending on the which port and VLAN it gets connected to, then the NVR won’t be able to find the camera when it’s IP address changes.

If there was a way you could assign a DNS name to the camera based on it’s MAC address that dynamically updates its DNS name with the correct IP address, then that might work because most NVR systems allow you to use a DNS address for the camera in lieu of an IP address, but you’d have to have a pretty sophisticated network system to do that.

The exception to this are proprietary cloud system cameras that have it hard coded in their firmware to reach out to a predefined cloud (fancy term for Internet) address so that if they are registered then they are associated with the correct customer account. The camera reaches out to establish and maintain the connection to the cloud service.

I’ve long been a proponent of the security industry including an option in CCTV cameras to program in an NVR address so that the camera associate itself with the correct NVR no matter if the camera’s IP address changes (similar to cloud camera brands), but no one seems interested in such an obviously beneficial feature.

15

simple answer - no.
most voip phones support custom dhcp options to configure the vlan ID (along with other ways) because phones are often required to tag the voice vlan. This is to enable the dpiggy backing of a PC off the phone - phone needs to support the pc vlan untagged and then tag voice traffic.

Security cameras have no reason to support tagged traffic as they have no real use case for multiple network interfaces.

There are alternate solutions to your requirement - which I take as automatically assigning cameras (or other equipment) to a specific vlan.
Some switches will support a simple form of OID to vlan mapping (using part of the mac address to group devices). This varies greatly between vendors and is often in SMB type devices.
The standards based approach to this is 802.1x - in this scenario the switch passes the device information to a policy server to authenticate and fetch policy settings. This can be used to match mac address to a vlan ID and the switch will then set the port to that vlan.

I have experienced environments where someone just scripted this or used ansible etc - quick poll of devices, get the mac address, update the switch port etc.

There are 2 key benefits:
1 - security - do not allow unauthorised devices onto network. In this case cameras would not be the focus, it’s unlikely they are connected at random, but rather securing desk/wall ports etc where anything can be connected.
2 - efficiency - usually applies to large network estates. automatic vlan assignment, port configuration etc is a big time saver on large networks. one config for all ports - as an example the security camera company could connect device to network - no need for network engineer etc. they just supply the mac address and it will be automated.

1 Spice up