Device Management

Devices represent the end systems connected to your network — workstations, IP phones, cameras, access points, printers, and similar equipment. PrivateLAN lets you register these devices, group them, assign them to switch ports, and monitor their status and security.

Adding a device

When you add a device, you provide:

The number of devices you can add is limited by your license.

Security types

Each device is assigned a security type, which determines how it authenticates on the switch port it is connected to:

• Unsecure — no authentication required
• MAC (Sticky) — the port is locked to the device's MAC address
• MAB — MAC Authentication Bypass, the device's MAC address is used as RADIUS credentials
• PEAP — username/password authentication
• EAP-TLS — certificate-based authentication

Device groups

Device groups bundle devices that share the same VLAN and base configuration. A device group defines a deploy/security configuration template for each security type (Unsecure, MAC, MAB, PEAP, EAP-TLS), tagged per switch platform (Cisco IOS, Aruba OS, Aruba OS-CX). Individual devices can override these templates with their own custom configuration if needed.

A device group also has a port mode: Access (the default — the port carries one VLAN) or Trunk (802.1Q — for hardware devices that carry virtual devices in more than one VLAN, see Virtual devices behind one port). The mode does not change the templates by itself; it says what kind of port your templates produce, and PrivateLAN uses it to decide which VLANs a virtual device may be in.

A device group can also require a PoE class — the IEEE class its devices need in order to power up. The default is No PoE required, so no existing group starts checking anything on its own. Once a class is set, an interface can only be assigned to a device in that group when its [P0]–[P8] tag says it can supply at least that class; see Switch Management. Raising the class is refused while a device in the group already sits on a port that cannot supply it.

Like the port mode, this changes no configuration by itself: the PoE configuration a port gets still comes from the group's templates, so an explicit power inline never for a device that must not be powered stays authoritative.

With the Inspection license option, a device group also has SSL check ports: the unsecure port that must be closed and the secure port that must offer the device's certificate, checked by Inspection > SSL (see Monitoring & Reports). Leave them empty to use the defaults set on that page, or enter "none" for devices without a web interface, such as workstations. A device can override its group with its own ports on its edit page.

With the SOC license option, a device group also has an Offline alarm: No alarm, Warning or Critical. A device in the group that stops answering then raises an alarm of that severity on the SOC live view — for example Critical for cameras — while workstations that are switched off at night stay at No alarm (see SOC Live View).

Assigning a device to a switch port

A device can be connected to one or more interfaces (ports), possibly on different switches. Once assigned, PrivateLAN can push the correct VLAN and security configuration to that port automatically.

Each linked interface can also be given an optional patch point — free-text notes on where its cable is physically terminated (for example, a patch panel and port number). The patch point stays with the port even if it is later unassigned and connected to a different device.

An interface tagged [TRUNK] on the switch interfaces page cannot be assigned to a device: that tag marks an uplink to another switch, which is configured by hand and never programmed from a device template.

If the device's group requires a PoE class, ports that cannot supply it are still listed under Add interface, in red, naming what the port supplies and what the group needs. They are listed rather than hidden so that a port you can see is free on the switch interfaces page never simply goes missing here without an explanation; picking one is refused, with the same two classes in the message. If a port's tag is lowered after it was assigned, the device page says so next to that port.

Virtual devices behind one port

A hypervisor puts several machines behind one switch port: each virtual machine has its own MAC address, its own IP address and its own 802.1x identity, but they all share the physical port of the machine they run on. PrivateLAN models this with a Kind on every device:

• Hardware — a device with switch ports of its own. This is the default, and what every existing device is.
• Virtual — a device that runs on another registered device, chosen under Runs on. It has no ports of its own and uses those of that device.

A virtual device is an ordinary device in every other respect: it has its own security type, authenticates with its own credentials or certificate, is reachability-checked on its own address, can be locked, and counts as a device for your license. What it cannot do is be given a switch port — the port panel on its page lists the ports of the device it runs on instead, and that is where they are assigned and unassigned. In the device list a virtual device shows that port with a small "via" note naming the device it runs on.

When a port is programmed, it is programmed for everything on it at once: the template of the hardware device, with the MAC addresses of that device and of every virtual device running on it (#mac# lists them all, #max-mac# counts them all). Adding, changing or removing a virtual device re-programs the port, and so does any change to the hardware device. Locking either of them freezes the port for both. The configuration compliance check (Inspection > Compliance) holds the port to the same combined configuration.

Some rules follow from this:

• Only a wired hardware device can carry virtual devices, and only one level deep — a virtual device cannot itself carry others.
• A device that carries virtual devices cannot be made virtual or wireless, and cannot be deleted while they exist: delete them first, or move them to another device.
• The VLAN a virtual device may be in depends on the port mode of the device group of the device it runs on (see Device groups). In Access mode the port carries one VLAN, so the virtual device must be in the same VLAN as that device. In Trunk mode it may be in another VLAN, and #vlan-list# in the templates renders every VLAN on the port.
• On the Deployment page a hypervisor shows several MAC addresses and is not matched to a device automatically. Register the hardware device first, then add its virtual devices with their own MAC addresses.

The switch port's template must allow more than one client on the port — on Cisco IOS authentication host-mode multi-auth, on Aruba a client limit above one — or the second device is refused by the switch itself. That is a property of your template, not something PrivateLAN changes for you. To make the port an 802.1Q trunk, do not tag it [TRUNK] on the switch interfaces page — that marks an uplink between switches, which is left alone by the compliance check and never programmed. Put the device group in Trunk port mode instead, and configure the trunk in its templates using #vlan-id# for the native VLAN and #vlan-list# for the allowed VLANs. Whether 802.1x authentication is supported on a trunk port at all depends on the switch platform and software version.

Wireless devices

Not every device is plugged into a switch. A device that connects over WiFi authenticates in exactly the same way a cabled one does — with MAB, PEAP or EAP-TLS against PrivateLAN's RADIUS server, and it gets its VLAN assigned the same way — but it has no switch port of its own.

Set Connection to Wireless for such a device. PrivateLAN then stops treating the missing port as something still to be done: the port indicators are replaced by a single wireless marker, the port assignment panel is not shown, and the reports and actions that act on a port — Status, Auth Status, MAB Status, Power, MAC, LLDP, Show Run, Log, and Restart, Enable and Disable — are not offered, because there is nothing for them to act on. Everything else works unchanged: the device is reachability-checked, it authenticates, it can be given a certificate, it can be locked, and Ping and ARP are still available.

For the access point itself, register it as an ordinary wired device on the port it is plugged into, and add it as a RADIUS client on the 802.1x / RADIUS page so it can forward authentication requests to PrivateLAN.

Dynamic (DHCP) addresses

A device does not have to be given a fixed address. Set Address to Dynamic and PrivateLAN finds out the address by itself, by reading the DHCP snooping table from your switches — the record a switch keeps of which address was handed to which device, on which port and in which VLAN. Nothing is asked of the device, and nothing is asked of your DHCP server.

The address is then read-only on the device page, and shown together with when it was last confirmed. Switching a device from a static to a dynamic address clears the address it had, since it is no longer something you stand behind; the device reports that no address is known until one is observed, which takes at most one polling round.

This is also how PrivateLAN finds a wireless device's address. A wireless client's address request travels through the access point's network port, so the switch sees it and records it there — which is why a wireless device can be pinged at all, and why PrivateLAN can tell you which access point it is behind.

DHCP snooping has to be switched on on your switches for any of this to work, per VLAN, with the ports towards your DHCP server marked as trusted. The switch configuration guides describe how, per series. Where snooping is not enabled, a dynamic device simply reports that no address is known yet — which is stated as its own status and not as the device being unreachable.

There are situations it cannot cover, and in all of them the device reports that no address is known rather than reporting something wrong:

• an access point that sends its clients' traffic to a wireless controller through a tunnel, so the address request never passes a switch PrivateLAN can read;
• a device behind a switch PrivateLAN does not manage;
• a device that was given its address by hand rather than by DHCP — that one belongs on Static;
• the first minutes after a switch restart, until each lease is renewed, because the snooping table does not survive a restart unless your switch is configured to save it.

If a discovered address turns out to already belong to another registered device, PrivateLAN does not take it over. It reports the clash instead — that normally means your DHCP range overlaps addresses you handed out by hand, which is worth correcting rather than hiding.

Custom configuration

A device normally uses the configuration templates of its device group. When one device needs something different, open the Customization panel on the device page and press Customize. You get one text box per security type (Unsecure, MAC, MAB, PEAP, EAP-TLS); only the box matching the device's own security type is ever applied.

The boxes start out empty, and an empty box means "use the device group's template" — so you only fill in the security type you actually want to deviate for. The reload icon next to a box copies the device group's configuration into it as a starting point.

Inside a configuration you can use the placeholders #interface#, #hostname#, #ip#, #mac#, #max-mac#, #vlan-id# and #vlan-list#, which are filled in per port when the configuration is sent to the switch. #mac# and #max-mac# cover every device on the port, including the virtual devices running on this one; #vlan-list# is the comma-separated list of all their VLANs, which is simply #vlan-id# for a device on its own. Saving a customization immediately re-programs the ports this device is assigned to.

A configuration line containing #ip# is left out entirely when the device has no address yet — a line that needs an address cannot be sent half-filled. The configuration compliance check applies the same rule, so such a port is never reported as differing because of it.

Saving without a port reset, or without programming

Saving a device, or its customization, normally programs its ports straight away. Each port is reset and switched off, gets the full configuration, and is switched back on, so the device on it is briefly disconnected. Two key combinations on the Save button change that for one click:

The confirmation after saving, and the audit log, say which of the two was used. RADIUS is updated in both cases, because it is not part of the switch.

Both leave the port different from a normal save. Without the reset, settings from the old configuration stay on the port alongside the new ones. That is harmless when you change the VLAN, hostname or description, but after a change of security type or MAC address the new configuration may not take full effect. With DB only, the switch keeps its old configuration completely. In both cases the port shows up as drift on Inspection > Compliance, and fixing it there — or saving the device again normally — programs the port in full.

Discovery

The Discovery page lists devices that PrivateLAN has detected via LLDP but that are not yet registered. From here you can quickly create a device entry pre-filled with the discovered information.

Certificates

For devices using EAP-TLS, PrivateLAN can generate and manage a client certificate for the device, issued by PrivateLAN's own Certificate Authority (see 802.1x / RADIUS). It can be revoked when no longer needed.

A certificate does not require the device to have an IP address: where there is none, the certificate is issued against the device's hostname alone. That is what decides whether authentication succeeds in any case, so a device with a dynamic address is not held back.

The certificate holds the device's hostname and, for a static address, its IP address, so the same certificate can also secure the device's own web interface: a browser accepts it whether you open the device by address or by name. Whether a device actually uses it is checked by Inspection > SSL.

The generated files can be downloaded from the device's Certificates tab in several formats. The files that contain the device's private key — the PFX, P12, PEM and KEY files — are protected with the Client certificate password set on the RADIUS configuration page; you need that password to import or use them. The CA, CRT and CSR files contain no private key and need no password.

Cameras

A device can be marked as a camera with the Is camera checkbox. That adds a camera panel to the device page, where you record the camera's ONVIF details and watch a live, periodically refreshed image next to the device's other information. See Camera Live View for the full description.

Locking a device

A device can be locked to freeze it — useful for equipment that must not be changed by accident, such as a camera covering a critical location or a machine under a maintenance contract. Use the padlock at the top right of the device page: a closed padlock means the device is locked, an open one means it is not, and clicking it does the opposite. In the device list, a locked device shows the same closed padlock in place of its delete and restart icons.

While a device is locked, all of the following are refused, whether they are attempted from the web interface, the REST API or the assistant:

• changing any of the device's own settings, including its camera settings and its custom configuration
• deleting the device
• assigning an interface to it, or unassigning one
• generating or revoking its certificate
• restarting, enabling or disabling its switch ports
• programming its ports, including picking the device up on the Deployment page

Everything that only reads keeps working, so a locked device can still be diagnosed: the whole monitoring panel, a ping, its authentication state, and its entries in the device list and the reports.

There are three lock strengths. They block exactly the same things and differ only in who can release the lock again:

You are only offered the strengths you could also undo yourself, so you cannot lock a device beyond your own reach. A Support lock is meant for a device PrivateLAN support is working on — an administrator of your own installation cannot release it, so only use it while that is actually the case.

Locking and unlocking is recorded in the audit log, including which of the three was applied and by whom.

Monitoring and control

For each device, PrivateLAN shows live information retrieved directly from the switch:

• Status — link state, speed and duplex of the port
• Auth status — current 802.1x authentication state
• MAB status — MAC Authentication Bypass result
• Power — PoE status, power consumption and power class
• MAC — MAC address table entries learned on the port
• ARP — ARP table entries for the device's IP address
• LLDP — link layer discovery information from the connected device
• Show run — the configuration currently applied to the port
• Ping — connectivity check to the device's IP address
• Log — recent activity on the port

From the same page you can restart, enable or disable the port. These three change the port on the switch, so they are not offered while the device is locked — the read-only buttons above stay available.

Restart and Disable are also withheld on one port: the one PrivateLAN itself is plugged into. If a device is registered with the same LAN address as the appliance, shutting its port cuts the appliance off from its own network — and from the switch it would need to reach to bring the port back up. Recovering from that means a serial console or a second machine on that switch. A restart is no safer than a disable here: the session to the switch runs over that same port, so the port goes down and the command that would bring it back never arrives. Enable stays available, because it only brings a port up.

The same protection applies to the background jobs and to the API, not just to these buttons. If a batch action covers several ports and one of them is the appliance's, the other ports are still changed and the skipped one is reported with the reason. Only the LAN address configured under System > Networking counts; the WAN address is not considered.

Programming the appliance's own port

The same port needs the same protection when a device is programmed, and this is the case that catches people out. Every device profile starts by resetting the port and switching it off, and only switches it back on with its last line — on Cisco default interface followed by shutdown, on Aruba disable, on Aruba CX shutdown. That is exactly right for an ordinary port, and fatal for the one the appliance is plugged into: the connection to the switch runs over that port, so it is lost the moment the port goes down, and the rest of the profile — the line that switches the port back on included — never reaches the switch. The port is then left wiped and switched off.

PrivateLAN therefore leaves those specific lines out when it programs the port carrying its own LAN address. Everything else in the profile is applied exactly as written, on a port that stays up while it happens, and each omitted line is reported so it is clear what was and was not sent. Only lines that switch the port off or reset it are affected; no shutdown, enable and a port-security violation action such as violation shutdown are all sent normally.

Because the port is not reset first, anything configured on it beforehand stays. If that port ever does need a clean start, do it from a serial console or from another machine on the same switch — not from PrivateLAN, which sits on the other side of the port in question.

Freeing that port also no longer resets it to the default port configuration. It keeps the configuration it has, which is the configuration that works; PrivateLAN says so when it happens.

The same panel can also produce a QR Support report, which hands everything an engineer needs about this device to a colleague elsewhere through an encrypted QR code, without the appliance needing an internet connection of its own. See QR Support.

The device list also gives a quick overview of all devices at once, including port status, MAC address verification, ping health and authentication status. It lists the MAC addresses configured for each device, and the filter row above the list lets you search on them.

Clicking the port status indicator at the start of a device's row opens a panel with the PoE status, class and consumption of its port, the bandwidth utilization in both directions, and the MAC addresses actually seen on that port.