Ondersteund tot 19-09-2031

26.9.5 - 19-09-2026

Web

Added

• The device overview now shows each device's MAC addresses, and you can search on them. A new MAC address column lists the MAC addresses configured for a device, in the usual colon notation. Devices with more than three show the first three followed by a link that opens the rest. The filter row has a matching search box: you can paste a MAC address in whatever notation you have it in - with colons, with dots, with dashes, or just a fragment of one - and it will find the device it belongs to.

• Switches now keep a history of their configuration, so you can see that it changed and what changed. The appliance already reads each switch's running configuration every few minutes. It now compares that reading with the one it kept before it, and stores a new version whenever the configuration has actually changed. The last ten versions of every switch are kept.

A new Versioning page under Switches lists every switch whose configuration has been stored, with the most recently changed one at the top. Opening a switch shows its full configuration, a list of the moments it changed to pick from, and a Changes view that marks exactly which lines were added and removed compared with the version before it. The configuration can be copied to the clipboard with one button or downloaded as a text file, and a single link downloads the newest configuration of every switch at once as a ZIP archive — enough to keep an off-appliance backup of the whole site. For a stack, the page lists each unit with its role, model and serial number, since the stack shares a single configuration.

Two things it deliberately does not claim: the appliance can see *that* a configuration changed, never *who* changed it, and a reading that is obviously incomplete — a connection that dropped halfway through — is discarded rather than stored as a version.

Because a switch's configuration contains the switch's own credentials, viewing this page needs a separate permission that only an administrator can grant. Nobody has it until you give it to them. Described in the documentation in English and Dutch.

• The SBOM can now be generated and downloaded through the REST API. An integration can start a new SBOM, see when it is ready together with its version and checksum, and download it, without logging in to the web interface - for example to feed a vulnerability scanner or keep your own CRA or NIS2 records up to date automatically. The download is refused while a new SBOM is still being generated, so you never receive the previous one by mistake. The API key needs the existing permission to view the SBOM. Described in the API documentation in English and Dutch.

• Administrators can now force every other user to log out in one action. The Users page has a new Logout all users button. After confirming, every other signed-in user's "remember me" session ends immediately, so they need to sign in again the next time they visit - your own session is not affected. Only an administrator who has been given this specific permission can use it. Described in the documentation in English and Dutch.

• A new honeypot can detect devices probing your network for old, insecure services. The appliance now recognises connection attempts to a small set of legacy services, such as FTP and Telnet, that it never actually offers itself - so nothing legitimate ever has a reason to try them. Any attempt is treated as a security event: it is written to the audit log and, when syslog forwarding is enabled, sent to your own log collector in the same format as every other security event, and it can trigger its own webhook so you can, for example, alert your security team or take automatic action against the source. Described in the API documentation in English and Dutch.

Changed

• The POE and bandwidth columns have moved from the device overview into a pop-up. The overview had grown wider than most screens, so the four columns showing POE status, POE class, POE consumption and bandwidth were taking space away from information that identifies a device. Clicking the port status indicator at the start of a device's row now opens a panel with all of it: POE status, class and consumption, the receive and transmit load, the MAC addresses configured for the device, and the MAC addresses actually seen on that port - with any address that is not on the allowlist for the port marked. For a device with no switch port, such as a wireless device, the panel says so instead of showing readings that do not apply. Described in the documentation in English and Dutch.

• The dashboard's "Firmware updates" and "PrivateLAN update" tiles now show "No Connection" in gray when the appliance currently has no internet access, instead of continuing to show whatever "Up to date" or "Update available" status was last checked. Both checks depend on reaching the update server, so their last result could otherwise look current even though the appliance has since lost its connection and can no longer confirm it.

Fixed

• Applying a firmware update showed "Could not reach the server." even when the update had been applied. The update page could not read the appliance's answer, so it reported a connection error while the firmware update itself had completed, and a restart could be requested right after. The same could happen when restarting from the update page. The page now shows the real outcome.
• Files downloaded through the REST API could be damaged. A certificate or SBOM downloaded through the API arrived with one extra character at the start and missing its last character, so its checksum did not match and a certificate in binary (DER) format could not be read. Downloads through the API now arrive byte-for-byte identical to the file on the appliance.
• On the device overview, the status indicators of a port supplying PoE were slightly out of line with those of a port that is not. The indicators sat a few pixels further right, and the label inside the port status block a few pixels lower, so the columns did not read as straight.
• On the device overview, clicking outside the restart confirmation did not close it. The confirmation asking whether to restart a device could only be dismissed with its Cancel button; clicking the greyed-out area around it did nothing, while the same click did close the delete confirmation. Both now behave the same way.
• Deleting a user no longer removes their name from the audit log. Until now, the audit log looked up a user's name only when it was displayed, so once a user was deleted, every action that user had performed showed as "Unknown user" - exactly when you most want to know who did it. The audit log now records the user's name together with each action. Entries of a deleted user keep showing their name, marked (deleted), until they fall outside the retention period, and a renamed user's earlier entries keep the name they had at the time. The audit entry for deleting a user now also names the user that was deleted. Entries of users deleted before this update cannot be recovered and still show "Unknown user". Described in the documentation in English and Dutch.

Security

• Two-factor authentication secrets are now encrypted in the database. They were previously stored in a readable form; a compromise of the database alone could otherwise have exposed them. Existing accounts are automatically converted the next time they sign in or change their two-factor settings - no action is needed.

Scripts

Changed

• The generated SBOM (Software Bill of Materials) now includes far more detail about every component: its license, a cryptographic fingerprint that lets you verify it hasn't been tampered with, and a more precise identifier for cross-referencing vulnerability databases. It also now lists the PrivateLAN web application itself and the third-party libraries it bundles, not only the operating system's own software - previously those were invisible to the SBOM even though they run on your appliance. Where a detail genuinely cannot be determined, the SBOM now says so explicitly instead of just leaving it out. This brings the SBOM in line with the internationally updated 2026 minimum requirements for a Software Bill of Materials.

Fixed

• The appliance's self-healing watchdog no longer fills the audit log. Every two minutes the watchdog checks that the web interface is still answering. It did so by requesting the dashboard, which of course requires a login, so each check left an Error 401 — Unauthorized, not logged in entry in the audit log from the appliance itself: around seven hundred entries a day, hiding the ones that matter. The check now requests the login page instead, which needs no login and leaves no entry. It still detects exactly the same failures — a broken web application or a web server that has stopped — and heals them the same way.

Ansible-Update

Changed

• Updates now clean up software that is no longer needed, including old kernels. Until now, every kernel update left the previous kernel installed. Those old versions were never used again, but they stayed on the appliance and kept appearing in its software bill of materials together with their known vulnerabilities. Each update now removes them. The kernel that is currently running and the newest installed kernel are always kept, so an update that still waits for a restart is never affected.

Fixed

• Temporarily blocking SSH access no longer gets silently undone by the next update. If SSH access had been disabled and an update then changed the firewall rules, SSH could be reopened without any warning. The update process now remembers whether SSH was blocked beforehand and restores that setting immediately after the new firewall rules are applied.

• A failed update can no longer leave the appliance unreachable. The appliance checks its new web server configuration before putting it into use. If that check failed, it correctly skipped the restart it was about to do - but then restarted the web server anyway through a separate mechanism, using the very configuration it had just rejected. The web server could not start on it, so the web interface went down, and with it the progress window of the update that caused it. Because that window had only lost its connection, it kept reporting that the update was still running instead of showing that it had failed. The rejected configuration also stayed behind when the update rolled itself back, so every following nightly attempt repeated the same thing, and the appliance could only be recovered from its console.

Two things changed. The restart now performs the configuration check itself, so an invalid configuration leaves the running web server exactly as it was instead of taking it down. And the last working configuration is saved before every update and put back automatically if the new one is rejected, which is verified afterwards - so a failed update leaves a working appliance, reports the failure properly in the update window, and cannot resurface at the next restart. The same protection was added for the component that runs the web application, where an invalid configuration could make the whole web interface return an error page.

---

Ondersteund tot 06-09-2031

26.9.4 - 06-09-2026

Web

Added

• Switch ports can now say how much PoE they can deliver, and a device group can require it. Tag an interface with [P0] to [P8] on Switches > Interfaces to record the highest PoE class that port can supply, and leave the tag off when the port supplies no PoE at all. A device group has a new PoE class setting; when it is set, a port can only be assigned to a device in that group if it can supply at least that class.

Ports that cannot are still shown under Add interface on the device page, in red, saying what the port supplies and what the group needs — so a port you can see is free never simply goes missing from the list 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 already assigned, the device page says so next to that port.

Every device group starts with No PoE required, so nothing changes until you set a class. Described in the documentation in English and Dutch.

Changed

• The API Rate Limits section on the security settings page now has its own illustration instead of borrowing the one used for access restrictions.
• Input fields and dropdown lists throughout the web interface now have the same white background and rounded border as the buttons next to them. Dropdowns used to be grey and text fields were drawn in the browser's own plain style, which made a single form look like it was built from three different sets of fields. Fields you cannot edit stay grey, so they remain recognisable as read-only.
• The meaning of the [P0] tag has changed. It used to be described as "no PoE present or allowed"; it now means PoE class 0, which is a real class. A port that supplies no PoE should carry no [P] tag at all. Existing tags are left exactly as they are, so if you used [P0] to mark a port without PoE, remove that tag from those ports before giving a device group a PoE class.
• The API can read and set a device group's PoE class, read the class each switch port declares, and reports a dedicated error when a port cannot supply what the device's group requires. Described in the API documentation in English and Dutch.

---

Ondersteund tot 05-09-2031

26.9.3 - 05-09-2026

Web

Added

• The appliance can no longer disconnect itself by reconfiguring its own switch port. Every device profile starts by resetting the port and switching it off, and only switches it back on with its last line. On the port PrivateLAN itself is plugged into that is fatal: 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 arrives. The port is left wiped and off, recoverable only from a serial console or another machine on the same switch. Those specific lines are now left out when that one port is programmed. 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. Only lines that switch the port off or reset it are affected - a port-security violation action is not one of them. Because the port is not reset first, whatever was configured on it beforehand stays. Freeing that port no longer resets it to the default port configuration either. Described in the documentation in English and Dutch.
• The appliance can no longer be disconnected by disabling its own switch port. If a device is registered with the same LAN address as the appliance itself, the Restart and Disable actions on that device's port are now refused instead of being sent to the switch. Shutting that port cut the appliance off from its own network and from the switch needed to bring the port back up, so recovery meant a serial console or a second machine on that switch. A restart was no safer than a disable: the session to the switch runs over that same port, so the port went down and the command that would have brought it back never arrived. The device page no longer offers Restart and Disable for that port and explains why; Enable stays available, since it only brings a port up. The same protection applies to the background jobs and to the interface used by other systems: a batch action covering several ports still changes the others and reports the skipped one with the reason. Only the LAN address counts - the WAN address is not considered. Described in the documentation in English and Dutch.
• The WAN interface can now be given a fresh address without a reboot. When the WAN interface uses DHCP, the network settings page has a new Renew DHCP button next to Refresh. Refresh only re-reads the address the appliance already holds and never contacts the DHCP server; Renew DHCP gives that address up and asks for a new one. That is what is needed after something changes on the WAN side - a different VLAN or subnet on the uplink, for instance - because until now the appliance kept using its old, no longer valid address until the lease expired. Saving the interface again did not reliably help either: it re-applies the same settings, after which the appliance asks for the address it already had. The renew takes a few seconds, during which outbound traffic is briefly unavailable, and the new address is shown as soon as it has been received. Described in the documentation in English and Dutch.
• Several devices behind one switch port. A hypervisor puts two or more virtual machines behind one physical port, each with its own MAC address, IP address and 802.1x identity. A device can now be marked as Virtual and told which registered hardware device it runs on. It has no port of its own: it uses that device's port, and everything that reads a port for it — status, reports, port actions, the device list — reads that device's port. In every other respect it is an ordinary device, with its own security type, credentials or certificate, reachability check and lock, and it counts as a device for the license.
• When a shared port is programmed, it is programmed for everything on it at once: the hardware device's template with the MAC addresses of every device on the port. Adding, changing, removing or locking any of them keeps the port in step, and the configuration compliance report holds the port to that same combined configuration.
• A device that carries virtual devices cannot be deleted, made virtual or made wireless while they exist, so a port is never reset from under a device that still uses it.
• Device groups gained a port mode: Access or Trunk. In Access mode a virtual device must be in the same VLAN as the device it runs on, because the port carries one VLAN. In Trunk mode — an 802.1Q trunk, the usual choice for a hypervisor — virtual devices may be in other VLANs, and a new template placeholder lists every VLAN on the port so the trunk's allowed VLANs are filled in automatically. The compliance report reads VLAN lists in whichever notation the switch uses.
• The interface used by other systems reports the new device fields, lists every device on a port next to its owner, and refuses to give a virtual device a port or to delete a device that still carries virtual devices, each with its own error code.
• Documentation in English and Dutch. The device page gained a section on virtual devices and the rules that come with them — including that the port's template must allow more than one client, and the difference between a trunk port and the trunk interface tag; the switch page explains that difference too; the API reference covers the new fields, the per-port device list and the two error codes.
• The documentation covers all of this, in English and Dutch: two new sections on the device page describing wireless devices and dynamic (DHCP) addresses — including what DHCP snooping is needed for, the situations it cannot cover and what happens then — the note that a certificate no longer needs an address, and the note that a configuration line needing an address is left out when there is none. The switch configuration guides for Cisco Catalyst and Aruba CX gained a section on enabling DHCP snooping, with the two things that decide whether it works: trusting every port towards the DHCP server, and enabling it on the right VLANs. The API reference documents the two new device fields, the two new webhook events, and that error 4002 is no longer returned.
• A device's IP address can now be left to DHCP. Until now every device had to be given a fixed address by hand, and one that did not have it could not be checked, could not be pinged and could not be issued a certificate. A device can now be set to Dynamic, and the appliance finds out its address by itself.
• It does that 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 the DHCP server. This requires DHCP snooping to be switched on on the switches; where it is not, a dynamic device simply reports that no address is known yet, which is now a state of its own rather than being shown as unreachable.
• This also finds devices on WiFi. A wireless client's address request travels through the access point's network port, so the switch sees it and records it there. That gives a wireless device both an address to check and an answer to "which access point is it behind" - the first time the appliance can say anything at all about where a wireless device is.
• The device page shows where a dynamic address came from and when it was last confirmed, and the address field is read-only for such a device. Switching a device to dynamic clears its current address, since nobody stands behind it any more, until a new one is observed.
• A webhook fires when a dynamic device's address changes, so an integration that talks to devices by address can follow along instead of caching one that has quietly moved.
• A webhook also fires when a discovered address is already in use by another device. That address is never written in that case - it is reported instead. In practice it means the DHCP range overlaps addresses that were handed out by hand, which is a fault on the network worth knowing about rather than something to paper over.
• A device with no switch port assigned can now still be pinged from a switch, and can still show the ARP table for its VLAN. Both used to be unavailable, which for a wireless device meant its page had nothing left on it. The switch that saw the device's address request is used instead, which is by definition a switch inside the device's own network.
• The status information available to other systems now also reports how a device is connected, whether it is reachable, when it was last seen, and which switch and port the network last saw it on. Asking for the status of a wireless device no longer returns an error.
• A device can now be marked as connected over WiFi instead of a switch port. Equipment on an access point authenticates the same way a cabled device does and is registered in exactly the same place, but it has no port - and until now the appliance treated that as a fault, showing "No interface assigned" and offering port reports and port actions that could never work. A new Connection setting on the device page says which of the two it is.
• For a wireless device the port indicators are replaced by a single wireless marker, the Interface column says "Wireless" rather than being blank, the port assignment panel is left out, and the port reports and the Restart, Enable and Disable buttons are not offered - with a short line explaining why. Reachability, authentication, certificates, custom configuration, locking and the reports that are about the device's own address and VLAN all work exactly as before.
• The QR Support report offers the same set of reports the page does, so a wireless device produces a report about what it actually has rather than pages of blanks.
• Marking a device as wired or wireless is reported to other systems the same way every other device change is, and the setting can be read and written through the interface used by other systems.
• The documentation now covers locking a device, which was never described anywhere. It explains what a lock does and does not stop, that everything which only reads keeps working so a locked device can still be diagnosed, and the three lock strengths with who can release each one. Available in English and Dutch.
• The same documentation page gained three sections it was missing: per-device custom configuration — how the text boxes relate to the device group's templates, that an empty box means "use the group's template", and the placeholders you can use inside a configuration; marking a device as a camera; and producing a QR Support report from the device page. The last two point to the pages that already describe those features in full.
• Locking and unlocking a device is now recorded in the audit log, including who did it and which of the three lock strengths was applied, next to the existing entries for adding, changing and removing a device. A refused attempt — someone trying to unlock a device they are not allowed to release — is recorded as well.
• A limit on how many API requests a single API key may make per minute. Until now nothing stopped a correctly authorised integration from calling the API as fast as it could — a polling loop without a pause, or a retry that never gives up, could keep the appliance and the switches behind it busy indefinitely. By default a key may now make one hundred requests per minute.
• A second, much smaller limit of ten per minute applies to the handful of requests that reach out to a switch: restarting or reconfiguring a port, asking a device or a switch for its status at that moment, opening a service port, issuing or withdrawing a certificate, and starting a system update. A switch is a small device that can only hold a few sessions at once, so a hundred of those a minute would take it offline rather than merely being busy. Requests that only read information the appliance has already collected — a list of devices, the status overview for many devices at once, a switch's port list — count against the general limit only, so ordinary monitoring is unaffected.
• Both limits can be changed by an administrator under System, Security, and either can be switched off. A request that goes over a limit is refused with a clear answer that states how many seconds to wait, and every answer the API gives now reports how much of the allowance is left, so an integration can pace itself instead of finding out by being refused.
• This is separate from the existing protection against repeated failed sign-in attempts, which continues to work as before.
• The documentation now covers Remote SSH, the page that sends commands straight to one or more switches from the web interface and shows you what each switch answers. It explains how to select switches and set the waiting time, how the result is presented and copied per switch, what happens when a switch stops answering or a run reaches its limits, which permission is needed and that only an administrator can grant it, and what is recorded in the audit log — the commands sent, but deliberately not the switch output, which can contain passwords and keys. The feature itself was already available; only its description was missing. Available in English and Dutch.
• Webhooks can now be triggered by eighteen more kinds of event. Until now a webhook could react to a switch going offline or coming back, a critical audit-log entry, and the four system-level notices about pending updates and restarts. Everything else was listed but greyed out as not yet available. Almost all of it now works.
• Service ports. A webhook fires when a maintenance session is opened on a service port, and again when it closes — with the reason it closed: an engineer ending it, the session running out of time, or the port no longer being marked as a service port at all. The message states which switch and port, in which VLAN, until when, and who opened it, so an alarm system or a relay can follow a maintenance window without anyone having to remember to report it.
• Device authentication. A webhook fires when a device is accepted onto the network, and when an authentication attempt is refused. This is what makes it possible to have a device that cannot get on the network raise an alarm on your own monitoring, or have a refused attempt switch a relay, without watching a log by hand. Authentication attempts from a device that is not registered at all are reported too, when they are refused — that is the case worth knowing about.
• Because devices re-authenticate on their own far more often than anyone wants to hear about, only a change is reported: the first refusal after a run of successes, or the success after a run of refusals. A device that keeps failing does not repeat the alert every few seconds, and a device flapping between the two cannot flood a receiver either.
• Device reachability. A device answering again after having been unreachable, and a device that stops answering, each fire a webhook — exactly as switches already did, and reported the same way: once when it changes, not on every check. Worth keeping in mind for equipment that is not on all the time, since a workstation switched off overnight will report itself twice a day.
• Devices. Adding, changing and removing a device each fire a webhook, whether it was done in the web interface or through the API. A change reports which settings moved — deliberately not their values, so no password ever ends up in a delivery log. Re-saving a form without changing anything sends nothing.
• Certificates. Generating a device certificate and withdrawing one each fire a webhook. On top of that, certificates are now checked regularly and report when they approach their expiry date — at thirty, fourteen, seven and one day remaining, once each. That covers the certificate authority and the RADIUS server certificate as well as device certificates, since those two are what actually stops the network working when they lapse. The number of days can be changed.
• The two port findings from the Inspection page can now raise an alarm on their own, instead of only being visible to somebody who opens that page: a connected port that has no device assigned to it, and a port marked as an uplink, SFP or non-device port that is not connected. Both report the switch, the group, the port and its marks; the first also reports the MAC addresses seen on the port, which is usually the quickest way to work out what has been plugged in.
• Each of those two comes with its recovery. A port is reported once when it starts matching and once more when it stops, so a finding nobody has got round to fixing does not repeat itself, and every alarm you receive eventually closes again. The recovery states when the finding first appeared, so it is clear how long it stood. Findings that already existed before this update are not announced as if they were new, and a single large event — a switch rebooting, an uplink dying — is capped rather than sent port by port.
• The written API documentation now has a chapter on webhooks: which events exist, when each one fires and how often, how conditions narrow them down, what a message looks like, how it is signed, what happens when a delivery fails, and the explicit promise that no login details are ever included. Available in English and Dutch.

• The documentation now covers offline updates, for appliances that have no internet connection and therefore cannot use the built-in update mechanism. Such a system is updated by replacing its system disk with the one from a newer virtual machine image, while the disks holding your database, certificates and logs stay exactly where they are — so switches, VLANs, devices, users, certificates, settings and the licence are all preserved. The procedure is described step by step with screenshots for Microsoft Hyper-V, including how to identify the right disk, why the virtual machine itself must not be replaced, how to make a restore point before the change, why you should wait for the automatic database upgrade to finish before opening the web interface, and how to roll back and clean up afterwards. Instructions for VMware ESXi and XCP-ng will follow; the principle is the same on every platform. Available in English and Dutch.

Fixed

• A device could be assigned to an interface tagged as a trunk uplink. Programming the device then overwrote the uplink's configuration, the compliance report stayed silent about it, and unassigning the device could not restore the port. Such interfaces are no longer offered for assignment and are refused when asked for directly, and the tag explanation on the switch interfaces page now says so - including where to look instead for a device port that has to be a trunk.
• The first reachability check after this update announced every device that was up as if it had just come back. The new status column started out empty for existing devices, so the first check read every reachable one as a change from "unknown" to "online" and sent a device-online notification for each. Those devices had not come back — they were never away. The status is now filled in from the reachability that was already known, so only real changes are reported.
• A burst of notifications was sent all at once instead of one after another. Each one started its own delivery in parallel, which is enough to make a small receiver — a relay, for instance — drop connections and report failures that were not really failures. Notifications from the device and switch checks are now queued and delivered in order by a single worker. This applies to any large batch, not just the one above: a switch going down takes every device behind it with it.
• MAC addresses could briefly disappear from devices on a switch that was not even being checked. The switches are checked one after another with a short gap, so two checks overlap; the cleanup step at the end of one removed the freshly collected addresses of another that had not finished writing them yet. The result was a device showing an empty list of found MAC addresses and a red indicator, for no reason, until its own switch was next checked. Each check now only cleans up its own switch.
• Left-over MAC addresses and DHCP records of a switch that has been removed are now cleaned up. They were never reachable by the periodic cleanup and stayed behind indefinitely.
• The suggested first free IP address could be one that was already in use. On a subnet larger than a /24 the check only looked at part of the range, so an address belonging to another device could be offered. On top of that, the VLAN's gateway, its router addresses, the appliance's own addresses and the switches' own management addresses were all treated as free. All of these are now excluded, and so are addresses your DHCP server has already handed out to equipment that is not registered in PrivateLAN — read from the same switch records used to find a dynamic device's address.
• Asking to ping a device from its switch reported "no IP address" when the real problem was that the device was not connected to a port yet. The two were checked as one question, so a device with a perfectly good address but no port assignment was told its address was missing. The two are now answered separately, both in the web interface and for other systems using the interface.
• A device that was locked could still be changed through the interface used by other systems. Locking a device freezes it, and the web interface refused every change to a locked device — but the same changes made by an integration or by the assistant were carried out anyway. Hostname, address, security mode, sign-in details and group of a locked device could all be altered that way. They are now refused, with a clear explanation of why.
• The network ports of a locked device could still be restarted, switched off and switched back on. These act directly on the switch, so a device that had deliberately been frozen could still be taken off the network — from the device page, from the device overview and through the interface used by other systems. All three now refuse it. Checking a locked device is unaffected: its status, its authentication state and a ping all keep working, because a frozen device is exactly the one you want to be able to examine.
• A locked device could still be picked up on the Deployment page. The connection between the port and the device was recorded, after which the switch was never actually configured — because the same lock stopped that half of the work. The result was a device that looked connected but was not. The page now shows that the device is locked and leaves it alone.
• Removing a leftover port entry could reset that port on the switch even when a device was still assigned to it. The reset was sent before it was established that the entry could be removed at all, so in that case the port on the switch was cleared while the entry itself stayed exactly where it was. The check now comes first, and nothing is sent to the switch unless the entry really is going to be removed.
• The API reference listed no response codes at all for creating or deleting devices, VLANs, switches, groups and their links — a numbering mistake in the reference meant those entries were shown without the code they belong to. Anyone generating a client from the reference had nothing to go on for exactly those calls. All of them now state their codes correctly, including the two cases that were missing entirely: refusing to delete a locked device, and refusing to create something the licence has no room for.
• Two error codes used by the webhook endpoints were missing from the error table in the written documentation.
• Linking a camera through its own discovery failed on some cameras — Axis in particular — even though that same camera showed a picture perfectly once its details were filled in by hand. Cameras differ in how they expect the appliance to identify itself when it asks them what they can do, and the appliance only ever asked in one of the two usual ways. It now tries both, so a camera that expects the other one is recognised without anyone needing to know in advance which it is.
• That same request carries a timestamp which the camera checks against its own clock, so a camera whose clock had drifted refused every attempt with a message that looked exactly like a wrong password. The appliance now asks the camera what time it thinks it is and matches it, so a camera with a drifting clock links normally.
• When discovery does fail, the exact reason the camera gave is now shown on the page underneath the message, rather than being visible only to a developer. When it succeeds, that same line reports which of the two methods the camera accepted and how far its clock is out — a camera minutes out of step is worth correcting even while it works.
• A camera that reports an address for its own video service which the appliance cannot reach — this happens on cameras with more than one network connection — is now asked on the address that just answered, instead of the one it named.
• When a camera could only be reached over one of the two connection types, a failure was reported as the camera not being reachable, even though it had answered and refused the request for an entirely different reason. The reason the camera actually gave is now the one shown.
• The list of ports you pick from when adding a port to a device was in the wrong order. The ports were sorted as plain text, which puts port 10 before port 7 and port 1/1/12 before 1/1/8. They are now listed in the order the switch itself numbers them - 7, 8, 9, 10, 11, 12 - matching what you see on the switch's own command line, for every brand. The ports already assigned to a device are listed in that same order.

Changed

• Restarting, enabling or disabling a device that occupies several ports on the same switch is now considerably faster. The switch's configuration was saved once for every port, and on some models saving takes several seconds — so a device on four ports waited four times as long as it needed to. The switch is now saved once, after all its ports have been changed. Nothing about the result differs: the ports are configured and the configuration is stored just as permanently as before, and a device on a single port is unaffected.
• The tag explanation on the switch interfaces page shows the link aggregation tag and the three PoE tags greyed out. All four have been listed there for a long time but none of them has ever been read by anything, so the page now says so instead of suggesting settings that are not applied. The PoE configuration a port receives comes from the device group template of the device assigned to it, and the PoE information shown per port is read from the switch itself - neither is affected. The example lines no longer use a PoE tag.
• The routed interface of a VLAN on a switch now carries the VLAN's own name. The VLAN itself was already labelled with the name it has in PrivateLAN, but the routed interface belonging to it was labelled with its number only - so the same VLAN appeared properly named in one place and as a bare number in the other. It now takes the same name everywhere. On the switch acting as first or second router for that VLAN the name is prefixed with "Pri" or "Sec", so the switch configuration itself shows which switch routes what. Names are shortened to 64 characters, which is as much as some switches accept.
• A certificate can now be issued for a device that has no IP address. Previously this was refused outright, which made certificates and DHCP mutually exclusive. The certificate is issued against the device's name instead of its address - which is what actually decides whether authentication succeeds, so nothing about how it works changes. The refusal and the explanatory message it produced are gone.
• A configuration line that needs the device's IP address is left out when there is none, instead of being sent to the switch half-filled. The compliance report judges the port by exactly the same rule, so a port is never held to a line that was never sent to it.
• The ARP table on the device page now goes through the same route as every other report on that page. It used to be the one exception, with its own copy of the lookup, which is why it behaved slightly differently from the same report in a QR Support document.
• A device without an IP address is no longer shown as if it had been checked. The reachability indicator on the device list and in the printed report had only two answers: a response time, or "unable to ping". A device with no address to test fell through both and simply kept whatever colour it had last — so a device that was green when its address was removed stayed green indefinitely, and one that had never been checked at all was shown as unreachable. There is now a separate answer for it: a grey question mark meaning no address was available, so nothing was tested. "Unable to ping" from now on means only what it says.
• The device overview and the printed interface report used to carry two separate copies of that indicator, which had to be kept identical by hand. They now use one, so the screen and the report can no longer disagree about whether a device is up.
• The dashboard's device connection chart has a fourth slice, "Not checked". Devices that could not be tested were previously counted as "No ping", mixing "we could not test this" in with "it did not answer" — only one of which is an outage.
• A device now records when it was last reachable. For equipment that is not switched on around the clock, "last seen" is a more useful answer than a red or green dot, and it is what the assistant is told as well.
• The assistant is no longer told that a device is unreachable when in fact no address was available to test it with.
• On a locked device the Restart, Enable and Disable buttons are no longer offered at all, with a short note explaining why. The buttons that only read information stay exactly where they were.
• The Deployment page shows a lock symbol instead of the option to configure, for a device that is locked.
• The two device lock options have been renamed and now say plainly who can undo them. "User Level Lock" applied a lock at whatever permission level the person pressing it happened to have, which rarely meant what it sounded like: for an ordinary user it produced a lock every other user could undo — no different from a basic lock — while for PrivateLAN support staff it produced one your own administrator could not undo at all. The choice is now named after who can release it: a Basic lock anyone who can log in may undo, an Admin lock only administrators may undo, and a Support lock, offered only to PrivateLAN support staff, only PrivateLAN support may undo. You are only shown the options you could undo yourself, so nobody can freeze a device beyond their own reach by accident.
• The lock symbol, the dialogs and the audit log now name which of the three is in force, instead of showing a permission-level number. Devices locked before this change keep working exactly as they did.
• The padlock on a device's own page now shows whether the device is locked, instead of what clicking it would do. It used to show a closed padlock for a device that was not locked and an open one for a device that was — the opposite of what the same symbol means in the device overview. A closed padlock now means locked and an open one means unlocked, everywhere. Hovering over it says what clicking will do, and clicking still works exactly as before.
• Removing a leftover port entry now waits for the switch to have actually been reset before the entry disappears, instead of pausing for a fixed few seconds and hoping that was long enough. If the switch is slow, the entry is kept and can simply be removed again a moment later.
• An error that happens in the first ten minutes after the system starts is no longer reported as a fault. When the system disk is replaced, the database is brought up to date automatically during the first start-up. Opening the web interface before that has finished shows an error page, because the information the page needs does not exist yet — a few moments later it does. Until now every one of those raised a problem report. Errors are now only reported once the system has been running for ten minutes, by which time the start-up work has finished.
• Nothing is hidden by this: the error is still recorded on the system itself, and a fault that is not simply a start-up delay keeps happening on every page view, so it is reported as soon as that period has passed. Reports that are not about an unexpected error — a licence problem, a database update that genuinely failed, a security setting being changed — are still sent immediately.
• The telemetry page an administrator can open now also shows how long the system has been running and whether error reports are still being held back for that reason.

Scripts

Added

• A helper that releases the current DHCP lease on the WAN interface, requests a new one and reports the address that comes back. It refuses to act on any other interface, and on an interface that is not set to DHCP.
• A small helper that reads new entries from the appliance's own authentication log for the webhook events above. It removes the password that the authentication service records alongside a refused login attempt before handing anything on, so that password can never reach a webhook message or a stored delivery.

Ansible-Update

Added

• The appliance is granted permission to run the new DHCP renewal helper.
• Two additive database changes for the new device kind, its parent device and the device group port mode, applied automatically on update. Existing devices and groups keep behaving exactly as before.
• The reachability state of existing devices is filled in from what was already known during this update, so the first check afterwards does not report every device as having just come back.
• Storage for whether a device's address is fixed or handed out by DHCP, and for the DHCP records read from the switches, is created automatically on existing systems during this update.
• Storage for how each device is connected - by cable or over WiFi - is created automatically on existing systems during this update. Every existing device is treated as cabled, which is exactly how it behaved before.
• Storage for recording when each device was last reachable is created automatically on existing systems during this update.
• Storage for the new API request limits is created automatically on existing systems during this update.
• Storage for remembering which webhook events have already been reported, so a recurring condition is not announced over and over, is created automatically on existing systems during this update.
• The appliance is granted permission to run the new authentication-log helper.

Changed

• The web application is given read access to the system's own start-up time, which is what the ten-minute rule above is based on. Applied to existing systems during this update.

Ansible-Deploy

Added

• The same permission for the DHCP renewal helper is included for newly installed systems.
• The same two kinds of storage are included for newly installed systems.
• The same storage for how a device is connected is included for newly installed systems.
• The same storage for recording when each device was last reachable is included for newly installed systems.
• The same storage is included for newly installed systems.
• The same storage for webhook event history and the same permission for the authentication-log helper are included for newly installed systems.

Changed

• The fresh-install database schema carries the same device kind, parent and port mode fields.
• The template used to issue device certificates now takes the name-or-address choice from the appliance, so a newly installed system issues certificates the same way an updated one does.
• The same access is included for newly installed systems.

Ondersteund tot 31-08-2031

26.9.2 - 31-08-2026

Scripts

Security

• The nightly safety check that automatically closes SSH again on production systems never actually ran. Since it was introduced, it stopped immediately every night because it could not find the firewall tool in the restricted environment that scheduled tasks run in. The consequence: on a production system where SSH had been switched on temporarily and not switched off again, SSH stayed reachable until somebody closed it by hand, and no notification about an automatic closure was ever sent. Running the check manually always worked correctly, which is why the problem stayed unnoticed. From the first night after this update the check runs as intended and closes SSH again automatically.

Ansible-Update

Fixed

• Scheduled system tasks now run with the same search path the operating system uses for its own scheduled tasks, so administrative tasks can always find the tools they need. Existing systems receive this automatically with this update.

Ansible-Deploy

Fixed

• The same scheduled-task change is included for newly installed systems.

Ondersteund tot 31-08-2031

26.9.1 - 31-08-2026

Web

Added

• QR Support now also works for switches. The switch overview has a QR icon next to each switch that opens the same hand-off you already had for a device: pick what to include, and the appliance turns it into a QR code that someone on site scans with a phone, so an engineer elsewhere can read it. As before, the appliance itself never needs an internet connection.
• A switch report is put together from what the appliance has already read from that switch, so it appears immediately and — importantly — still works when the switch itself is unreachable, which is usually when you want one. It opens with what is known about the switch: name, group, address, type, model, serial number, software version and location, followed by its status, whether the appliance has a connection to it, response time, processor load, temperature, power usage, uptime and, for a stack, the number of units. The moment that information was read is stated with it, so the reader can see how recent the picture is. On top of that you can include the VLANs, a short up-or-down list of every port, and the switch's configuration.
• Passwords, community strings, keys and password hashes are removed from a switch configuration before it is encrypted and shown as a QR code. That happens on the appliance itself, so no login details leave it. The configuration option is marked as large and is switched off to begin with, because a full configuration is by far the biggest thing a report can carry.
• Generating a switch report needs its own permission, separate from the one for devices, and it also has to be included in the license — the same two conditions that already applied to device reports.
• Remote SSH — a new page under Switches for sending commands straight to a switch and reading back what it answers, without leaving the interface or opening a separate SSH client. Commands are typed one per line and are sent in the order given; what the switch replies comes back as a transcript. Nothing typed is checked or rewritten by the appliance — this is the switch's own command line, so a configuration command takes effect the moment it is sent.
• Several switches can be addressed in one run, offered by switch group in the selection list, so the same commands go to a whole group in turn: saving the configuration after a maintenance window, or asking the same question of every switch and comparing the answers side by side. Switches are chosen from a dropdown that lists them under a coloured heading per switch group, the same way ports are chosen on the device page, and each one picked is added to a list underneath that can be added to or thinned out before sending; a button adds every switch at once. A switch the appliance cannot currently reach, or cannot log in to, is greyed out with the reason beside it and cannot be added, so a run is not spent on switches that were never going to answer. Each switch gets its own session and its own transcript, a switch that fails anyway is reported in place instead of stopping the others, and a run that would take too long stops in good time and names the switches it did not get to, rather than being cut off with everything collected so far lost.
• Remote SSH has its own permission, separate from being allowed to manage switches, and one that only an administrator can grant — being able to edit a switch in the interface does not imply being able to type on it directly. Every run is recorded in the audit log per switch: who did it, which switch it was, and exactly which commands were sent. Those entries are forwarded to an external log collector along with the other security events when that is switched on. What the switch sends back is deliberately not stored: a full configuration contains passwords and keys, and the audit log is the wrong place for a second copy of them. Each switch's answer has a copy button above it, so a configuration listing can be put on the clipboard in one click instead of being selected by hand.
• How long to wait for each command can be chosen per run, for commands that produce a lot of output such as a full configuration or the address table of a busy switch. A switch that stops answering is not sent the rest of the commands — after a command that goes unanswered the state of that session is unknown, and continuing blindly is the one thing that must not happen — and the run moves on to the next switch instead.
• Configuration compliance — a new Compliance report under Reports that answers a question the appliance could not answer before: does a switch port still look the way it was programmed? For every port it puts the configuration the port *should* have next to the configuration it *actually* has, in two columns, and colours each line as correct, different, missing or unexpected. Lines are compared on what they say rather than on the order they appear in, so a switch that lists the same settings in another order is not reported as wrong, and commands that only exist to enter configuration mode are left out of the verdict instead of being reported as missing. Until now a command a switch quietly refused, or a port someone changed by hand over the console, went unnoticed: programming a port reported success as long as the switch answered at all.
• The compliance report covers every port, each measured against what its own role says it should be: a port with a device on it against that device's configuration, an unassigned port against the default configuration, and a service port against the service port configuration when a session is open, or simply against being switched off when none is. Trunk ports, uplinks and ports belonging to a locked device are listed as not checked rather than guessed at, so the report never invents an expectation it cannot justify.
• Per switch the compliance report also checks two settings that are easy to miss and awkward to discover afterwards: whether the switch sends its logging to this appliance — and whether it does so by IP address or by DNS name — and whether a time server is configured at all. A switch without a time source produces log entries whose timestamps cannot be lined up with anything else.
• The compliance report can be run for all switches, for one switch group or for a single switch, starting from an overview with a line per switch and the number of correct and deviating ports, from which you can open one switch in full. Opening the report contacts no switch: it uses the configuration already read during the regular switch check, which also means the whole estate can be reviewed at once without waiting. Each switch shows when it was last read, and a reading too old to rely on is marked as such rather than presented as current. A switch can be asked to be read again from the report itself.
• The compliance report follows the way switches actually write their configuration down, so what it reports are real differences rather than differences in wording. A port that the template switches off and back on again is judged on the state it ends up in, so the report tells you whether the port is meant to be enabled and whether it really is. A setting a switch leaves out for as long as it is on its default value — a port in the default VLAN, for example — counts as correct instead of missing. Text a switch prints back in quotes is read as the same text. And the commands that only serve to enter configuration mode are gathered into a single line at the bottom of each port, instead of being listed one by one above the differences that matter.
• A switch the appliance has never been able to read is now marked as such in the compliance report, with the same status colour used on the switch overview, instead of having every one of its ports counted as a difference. A switch that does not answer at all, or that answers but can no longer be logged into, is marked in the same way. It is now clear at a glance whether a result says something about the switch's configuration or simply about a switch the appliance never got to see.
• A port that has drifted can be put right from the compliance report itself. Every drifting port with a device on it gets a fix button that programs that device's ports again with the configuration the report says they should have, and the page comes back scrolled to the port you clicked instead of at the top of a long list. A second button does the same for every drifting device on the switch at once; those are programmed strictly one after another, never several at the same time, so a switch is never asked to hold more management sessions than it allows. Programming briefly takes a port down while its configuration is rewritten, so both buttons ask for confirmation first, and both are only shown to users who are allowed to run operational actions on devices. Nothing is programmed by the click itself — the work is queued and runs in the background, exactly as it does when a device is saved.
• The SSH port of a switch can now be set per switch. Until now every switch was contacted on the standard SSH port, so a switch whose management SSH had been moved elsewhere could not be reached at all — the setting was already there internally, but there was no way to fill it in. The field is optional and keeps using the standard port unless you change it, and it can be set over the programming interface as well.
• Service ports can now also be managed over the programming interface: list them with their current session, open one for a fixed duration in a chosen VLAN, close one early, and read or replace the configuration that gets applied — either the general one or a single port's own. The same duration and VLAN checks apply as in the web interface, so a longer session or a VLAN the interface would refuse cannot be opened this way either. Opening and closing return as soon as the session is recorded; the switch is reconfigured in the background.
• The dashboard has a Service ports open tile showing how many service ports are currently open and when the first one closes, linking straight to the Service page. An open service port is deliberate rather than a fault, so it gets its own figure instead of being counted among the inspection warnings.
• Service ports — a new Service page under Switches for giving an engineer temporary access to the network during maintenance. A port becomes a service port by tagging it [SERVICE] on the switch interfaces page; such a port is always a non-device port, so no device can ever be assigned to it. From the Service page a port is opened for a fixed session of 4, 8, 12 or 24 hours in a VLAN of your choice, and only VLANs available on that port's own switch are offered. When the session runs out the port is shut down on its own — the fixed duration is enforced, not a reminder — and it can also be closed earlier by hand. Until now a maintenance port had to be configured on the switch by hand every time, and in practice stayed open long after the work was finished.
• The configuration applied to a service port when it is activated is set once and used by every service port, written the same way as the existing default VLAN configuration. A single port can be given its own configuration when one switch needs something different. Removing the [SERVICE] tag from a port removes that configuration with it, and closes the port if a session was still open, so a port can never be left open with nothing keeping track of it.
• While a service port is open it is listed on the Inspection page with the time remaining and counted on the dashboard, so an opened port is never invisible. Opening, closing and reconfiguring a service port is recorded in the audit log, including who did it, and the Service page itself shows who opened the current session.
• Two new permissions cover the feature separately: one to view the service ports, and one to open, close and configure them — so being able to see whether a port is open does not imply being able to open one.
• Switches can now be reached with an SSH key instead of a password. Each switch has an Authentication setting choosing between the two, and for SSH key you paste the private key on the switch's page, with its passphrase if it has one. The key is checked before it is saved, so a wrong passphrase or a damaged key is reported straight away rather than only surfacing later as a switch that will not connect. Once saved, the matching public key is shown on the same page, ready to be installed on the switch itself. The private key is never shown again. This also works over the programming interface, so an estate can be moved onto keys without visiting every switch by hand.
• Tux, the AI assistant, can now actually carry out changes when an administrator sets it to Full control on the AI page. Until now that setting existed but did nothing on the standard assistant: Tux would offer to help and then find it had no way to act. It now works through exactly the same programming interface, and the same validation, permissions and licence limits, that the web interface itself uses, so nothing it does can take a shortcut past a check that would otherwise apply. Because it uses that interface rather than a fixed list of things it was taught, anything the programming interface can already do is available to it, and anything added there later becomes available without the assistant having to be taught about it separately.
• Every change Tux wants to make is now shown to you first, in the conversation, with exactly what it intends to do — and nothing happens until you press Confirm. Cancelling changes nothing. This approval step is enforced by the appliance itself, not by the assistant, so it holds even if the assistant is talked into skipping it by something it read along the way, such as a crafted device name or log line. Each carried-out change, and each cancelled one, is recorded in the audit log under the account it acted for.
• While Full control is switched on, the assistant window is unmistakably marked: the header turns red and a warning strip appears above the conversation. It is meant to be impossible to confuse an assistant that can change your system with one that can only look things up.
• Tux can now send a ping, either from the appliance itself or from the switch a device is connected to. Pinging from the switch answers whether a device responds inside its own network segment, which the appliance cannot tell you when it is not on that segment itself. Pinging changes nothing, so it also works when the assistant is set to read-only and needs no approval.
• The programming interface gained a matching ping action for a device, with the same choice of vantage point, so the same check can be scripted.
• The dashboard has a new Switch status section: how many switches do not answer at all, how many do answer but can no longer be logged into to read their data, whether switch data is still being refreshed in the background, the highest power usage against a switch's own PoE budget, and how many switches have not been placed in a switch group. A switch figure that is not OK moves up into "Action needed" at the top of the page like every other tile, so a switch that has quietly dropped off the network or a PoE budget that is nearly full is the first thing you see, instead of something you only find on the switch overview.
• The dashboard now also shows how hard the appliance itself is working: processor load, memory in use and used space on each of its disks. Every value gets its own tile with an OK, Warning or Error badge, and a tile that is no longer OK moves up into the "Action needed" group at the top of the page — so a disk slowly filling up or memory running out is visible at a glance, instead of only being noticed when something stops working. The values are read fresh each time the dashboard is opened, and are the same measurements the appliance already used for its own health reporting.
• The dashboard now also shows the traffic on the appliance's own network connections: incoming and outgoing, averaged over the last minute, with a tile per connection. A connection without a link says so instead of reporting no traffic, and a connection the appliance does not have is left out entirely. These tiles are informational and always show OK — no amount of traffic is a fault in itself — and they are measured in the background rather than while the page loads, so they cost nothing in dashboard speed.
• A Syslog flood protection tile shows whether the appliance is currently discarding log messages from a device sending them faster than it accepts. "Normal" means nothing is being discarded; a warning shows how many messages per minute are being dropped, so it is visible straight away that log messages are being lost, and roughly how badly, instead of that only surfacing later as unexplained gaps in the log. The limit applies per sending device, so one very talkative switch never pushes the rest of the equipment out of the log.
• The appliance can now send its own audit events — sign-ins, failed sign-ins, refused access, and changes to accounts and security settings — to the external log collector configured on the Syslog page. Until now only messages from your network equipment could be forwarded, so the appliance itself was the one system your central logging never saw. The events are sent, not stored a second time: they stay exactly where they already were, on the Audit log page, so nothing is duplicated and the log database does not grow because of it. A new option on the Syslog page chooses what goes out: nothing, security events only (the default), or every audit entry including each page view. It only applies when forwarding to an external collector is switched on, and the events are sent in a plain, widely understood format that common log collectors can read without extra configuration.
• Log storage now also has a maximum number of messages, alongside the existing retention in days. A retention period alone says nothing about size — a single very talkative device can produce millions of messages a day — so the message limit is what actually keeps the log database within bounds. Clean-up runs in the background in small steps, so it never slows the interface down.
• QR Support — a new button in the *Monitoring and control* panel on the device page, for handing a device report to an engineer who is nowhere near the appliance, on a network that has no internet connection at all. You tick which reports to include — running configuration, interface status, authentication and MAB status, power, MAC table, LLDP neighbours, log, a ping issued by the switch itself, and the ARP table — and the appliance collects them from every switch the device is patched into, encrypts the result, and shows it on screen as a QR code. Everything except the log and the ARP table is selected to begin with; those two are marked as large, because the ARP table covers the whole VLAN rather than just this device and can double the number of codes on its own. In practice the standard selection fits in one or two codes. Whoever is on site scans that code with a phone; the phone — not the appliance — carries the report out, so nothing needs to change about an isolated network to make this work. The report can also simply be photographed and sent on later.
• A colleague elsewhere reads the report back on the PrivateLAN website, either by scanning the code or the photograph, or by entering the eight-digit code and the sixteen-character key shown next to it on screen. A large report is split over several codes, which are scanned one after another. Reports are removed automatically after seven days — long enough that a hand-off made on a Friday can still be picked up after the weekend.
• The report is encrypted before it leaves the appliance and is only decrypted again in the browser of whoever reads it. The key travels in the scanned link and is never sent to any server, so PrivateLAN cannot read the reports passing through this feature, and neither can anyone who obtains a copy of the database behind it. Anyone holding the code, or both the number and the key, can read the report — a photograph of a QR code deserves the same care as the configuration itself.
• Whatever you select, the report opens with the device's own registration — name, device group and VLAN, IP address, security mode, the allowed MAC addresses, and for the modes that use them the authentication username and password — so the engineer reading it can judge the switch output against what the appliance believes the port should be doing. A device with generated client certificates also gets their common name, alternative names, dates and validity period. The authentication password is included on purpose, because a device that fails to authenticate is exactly when someone needs it; it stays encrypted like the rest, but anyone given the code can read it, so treat a hand-off accordingly.
• Because QR Support is the one feature that deliberately carries data off an otherwise isolated appliance, it is restricted twice: it must be included in the licence, so an organisation can rule the capability out entirely, and the user needs a permission of their own to generate a code. Every generated code is recorded in the audit log with who generated it and for which device. The key is deliberately not recorded there — a log that contained it would be enough to read the reports back.

Changed

• A QR Support report now states which installation it came from: the system name you set yourself under System settings, together with the licence identifier of the appliance. An engineer receiving a report can therefore tell whose network it describes, which previously was not possible — the report named only the appliance, and that name is the same on every installation. Both details sit inside the encrypted report and are readable only by whoever you hand the key to; nothing identifying you is sent to PrivateLAN in readable form, which remains the point of the whole feature.
• The columns of the switch overview now size themselves to their contents instead of being fixed. Long hostnames, models and locations were being wrapped in narrow columns while other columns sat half empty; the table now adapts to what is actually in it.
• Programming a device port and the new compliance report now build the intended configuration through one and the same routine. They were separate pieces of code doing the same job, which meant the report could have described a configuration different from the one actually programmed. Nothing about what gets sent to a switch changes.
• The tag field on the switch interfaces page now accepts a longer list of ports. It was limited to 100 characters, which a 48-port or stacked switch could already fill before the new service port tag was added, and exceeding it only produced a generic error.
• The assistant is now told which mode it is in, so it explains itself correctly. Previously it was always instructed that it could only read, which meant that even with Full control switched on it would tell you it was unable to make changes.
• The permissions covering what the assistant may change have been simplified. Where there were separate permissions per kind of data, there is now one permission for looking things up through the programming interface and one for making changes through it, plus a separate one for pinging. Making changes still additionally requires Full control to be switched on, and administrators are unaffected either way.
• When the assistant is connected to your own AI server instead of PrivateLAN's, the time it waits for an answer is now configurable and defaults to considerably longer than before. A model running on your own hardware can need much more time than a cloud service, particularly on the first question after it has been loaded, and the previous fixed limit could cut that off. The page now also notes that carrying out changes requires a model that supports tool calling.
• Every tile on the dashboard now shows an OK, Warning or Error badge in the same top-right corner, including the tiles that previously only used a coloured edge. With the badge always in one place the row of tiles is quicker and calmer to scan, and the status is readable without depending on colour alone.
• Actions carried out in the web interface are now recorded individually in the audit log, the same way actions carried out over the programming interface already were. Creating, changing or deleting a switch, device, VLAN or any of their groups previously left only a general "page visited" entry, which made it hard to see afterwards who changed what. Both routes now produce the same wording, so a single search finds a change regardless of how it was made.
• The maximum log retention has been reduced from one year to 90 days; the default of 28 days is unchanged. The appliance is meant for inspecting recent messages from your network equipment, not for long-term log archiving, and the longer setting suggested otherwise. Note that the new message limit may clear older messages sooner than the number of days set here on a busy network.
• Housekeeping of the audit log, the syslog messages and the webhook delivery history now runs once an hour in the background instead of on every single page load. Every page in the interface previously triggered three clean-up operations on the largest tables in the database, which slowed things down for no benefit. Pages should feel slightly quicker, particularly on appliances with a lot of stored messages.
• The Syslog page now resolves the sender in both directions. Devices that identify themselves by IP address already had their name looked up automatically; devices that report only their name now get their IP address filled in as well, when that device is known to the appliance. Searching on either the name or the IP address finds the messages in both cases.
• The main menu is now ordered the way the appliance is actually used: the overview first, then the equipment being managed, then rolling out changes, then checking and reporting on the result, and the administrative sections last. Radius sat below the system settings, out of sight and away from everything it relates to, and has moved up alongside the network sections; the user administration has moved down to sit with the other administrative items. No menu entry was added, removed or renamed, and every sub-menu moved along with the section it belongs to.
• The QR Support feature is no longer part of the publicly published source code of the web application. QR Support is a licensed option, so its implementation is now left out of the public publication in the same way as the other licensed components. This changes nothing about the feature itself on the appliance.
• Only finished releases are published to the public source repository. Internal test versions were being published there as well, which meant the public code could be ahead of what any customer actually runs; the public repository now follows the released versions only.

Fixed

• The QR Support window on the switch overview showed a large empty area above the QR code. The report was being returned complete with the surrounding page instead of on its own; only the code itself is returned now. The device version was already correct.
• The icon for the Remote SSH button on the switch overview was missing from the released files, so it showed as a broken image. The icon for the new QR Support button had the same problem. Both are now included.
• Removing a switch interface now says what actually happened. An interface that still has a device assigned to it cannot be removed, but the page reported "Database updated" anyway and left the interface where it was, giving no hint as to why; it now names the reason. The same page also stayed silent when its security token had expired — the removal simply did nothing — and now reports that too.
• The separator lines a Cisco or Aruba switch prints between the blocks of its configuration are no longer stored as if they were settings. They carry nothing, but they were kept along with the rest of the configuration read from the switch, which made every port appear to have a line on it that nobody asked for. Switch data is refreshed automatically, so this corrects itself at the next reading.
• MAC addresses are now written to a switch in the notation that switch actually uses. Aruba switches were being sent MAC addresses in Cisco's notation, which they reject, so port security on those switches was never actually given the addresses it was supposed to allow — and because a switch's reply to a refused command looks the same as a reply to an accepted one, this reported success every time. Cisco switches were always correct and are unaffected. Devices on Aruba switches that use MAC-based security should be programmed again so the correct addresses are applied; the new compliance report shows which ports are still missing them.
• Asking the assistant to do the same thing twice in one question — listing the devices, looking up two jobs, checking two webhooks — could break off the whole answer with an error instead of replying. The assistant carries out each step through the same programming interface the web interface uses, and repeating one step within a single question was not handled correctly. Repeated steps now work like any other, and the same question can be asked again as often as needed. Nothing changed about what the assistant is allowed to do, or about the approval step before it makes a change.
• A service port could not be activated until someone had opened the service port configuration page and saved it once — the configuration started out empty, and activating a port before that reported that no configuration was set. A working default for all supported switch types is now supplied with the appliance, so the feature works as soon as a port is tagged.
• Activating a service port reported success while the switch was in fact never reconfigured. The supplied configuration was missing the command that enters configuration mode, so every line was rejected by the switch — but a rejected line looks the same as an accepted one to the appliance, so the run appeared to have worked. The configuration now enters configuration mode first, and after activating a port the appliance reads the port's configuration back from the switch and shows it, so what actually landed on the port is visible rather than assumed.
• The audit log recorded only the internal number of anything that was deleted, never its name — and once the record is gone that number no longer refers to anything, so afterwards there was no way to tell what had been removed. Deletions now record what the item was as well: the name and address of a device or switch, the name of a VLAN or a group, the address a webhook pointed at. This covers deletions made in the web interface and through the programming interface alike, and the name is read before the record is removed rather than looked up afterwards, when it would be too late.
• The box asking you to approve a change identified what it was about to touch only by its internal number. Approving the removal of "device 9" tells you nothing about which device that is, so there was no way to catch it if the assistant had the wrong one — and on our own test system exactly that happened: two devices were deleted where only one should have been, and the second removal looked no different from the first. The box now names what each number refers to, looked up on the appliance itself at the moment it asks you: the device's name and address, the switch a port belongs to, the name of a VLAN. Removals are also labelled as permanent and stand out from other changes.
• Requests that needed a few lookups before the assistant could act were given up on. Something like "move this camera from port 1 to port 3 on that switch" first requires finding the switch, the device and both ports, and the assistant was only allowed a handful of steps per message — all of which went on the looking up, so it never reached the change and answered that it could not complete the lookup and you should rephrase. The question was fine; the budget was not. It has been raised substantially, the assistant is now told how to spend it (look several things up in one go, and use the quick overviews for finding names rather than fetching records one at a time), and if it does still run out it now says where it stopped and whether anything was changed, instead of asking you to rephrase.
• Long answers from the appliance could reach the assistant cut off halfway. Anything sizeable — the port list of a large switch, for instance — was trimmed to a fixed length that turned out to be far too short, and because the trim fell in the middle of the data the assistant could not read what came back and tried again, using up its steps for nothing. The limit is now four times larger.
• The assistant's own replies could be cut off mid-sentence when it had a lot to say, and its allowance of conversation and daily usage has been raised well above the old level. Carrying out changes simply uses more than answering questions did, and the previous allowances were set when the assistant could only read.
• The assistant lost track of the changes it had made. Its record of carrying out an action only existed while it was answering that one message, so from the next message onwards it had no idea it had done anything. In practice that meant it would deny having made a change it really had made, contradict its own confirmation, and — the reason this mattered most — carry the same change out a second time when asked about it, because nothing told it the first one had already happened. The appliance now keeps its own record of every change it carries out during a conversation and gives that record back to the assistant on every message, so it can say exactly what it did, and recognises a change that has already been made instead of repeating it.
• The approval you gave disappeared from the conversation. The approval box was only ever drawn on screen and was not part of the saved conversation, so it vanished as soon as you moved to another page — leaving a conversation in which the assistant appeared to have changed something with nothing showing that you had agreed to it. Answered approval boxes now stay in the conversation, marked as approved or cancelled.
• The assistant announced changes as completed before they had happened. Asking to make a change and having made it are two separate steps — your approval sits in between — but nothing told the assistant that, so it would report success, and even quote an item number, at the moment it merely requested the change. It is now instructed to say what it is about to do, and to report a change as carried out only once it has seen the result. What it said it was about to do also now appears above the approval box, instead of only the bare technical details.
• When the assistant was connected to your own AI server, information it was given to work with could arrive empty, depending on which server software you run. It would then answer as if it had looked something up and found nothing, rather than reporting a problem. Answers that depend on looking something up were affected; the assistant's general knowledge of the product was not.
• The Syslog page left the IP address blank for messages the appliance logs about itself. It now shows the appliance's own management address alongside the name. Messages from senders the appliance does not recognise still show no address, rather than being attributed to the wrong system.
• Log messages sent by the appliance had a small formatting error in their header, which could cause an external log collector to read the sender's name incorrectly. The appliance's own log database was unaffected and always showed the correct sender.
• The Syslog page showed the Audit log's retention period instead of its own for users who are not allowed to change that setting.

Security

• Database error messages are no longer shown on screen when something goes wrong. They named internal table and column names, which is of no use to you and of some use to an attacker. The details now go to the server log and the page shows a short, neutral message instead.
• A weakness in the audit log's detail view has been closed. The values sent with a request are shown there for investigation, and those values come from whoever made the request — a specially crafted entry could run code in the browser of the administrator who opened it, using that administrator's session. The detail view now treats the stored text strictly as text. The same view also had two older mistakes: it was built on a form that pointed at the device editor, and its close-on-click-outside never worked. Both fixed.
• Someone allowed to manage other users could change any account, including an administrator's, regardless of how much more that account was allowed to do. The check that is supposed to stop this only ran while the edit screen was being opened, not while the change was being saved, so sending the change directly bypassed it. In practice that meant such a user could set another person's password to one they chose and then switch that account off — administrators included. The check now runs on saving as well, against the account as it is actually stored.
• Passwords and one-time links were being written to the audit log in readable form. The log kept a copy of everything a form sent, with only a short fixed list of field names hidden — so the password typed when registering, when resetting a password, or when an administrator sets one for somebody else was stored as typed, as were the single-use links from verification emails. Anyone allowed to read the audit log, or holding a backup of it, could collect them. Any field whose name suggests a password, key, token or code is now hidden automatically, so a field added later is covered from the day it appears. The routine "page opened" entry, which is written for every single page view, no longer keeps a copy of what was sent at all; entries for actual actions still do.
• Changing a password now ends the sessions that were opened with the old one. "Stay signed in" is checked against a separate remembered value and not against the password, so someone who had gained access kept it after the password was changed — exactly the situation a password change is meant to end. This applies both to resetting your own password and to an administrator setting one.
• The part of a license that ties it to a specific machine was not actually doing so. The key protecting it was longer than the encryption could use, and the part that identified the machine fell off the end — so the resulting license was not bound to that machine at all. Licenses are now tied to the machine as intended, and are also protected against tampering rather than only being encrypted. Existing licenses keep working, and a license issued from now on is readable by appliances that have not been updated yet, so nothing needs to be reissued.
• Signing in with a user name that does not exist now takes exactly as long as signing in with a wrong password. The two answers already read the same, but the non-existent one came back noticeably faster, which was enough to work out which user names are in use.
• Deleting a user is now recorded in the audit log. The permission checks around it were already correct, but the most destructive action on the page left no trace of who did it or when.
• The forgot password form is now protected against automated guessing. A wrong captcha answer could previously be retried straight away and without limit, so the puzzle could be guessed rather than read; repeated failures from the same address are now counted and temporarily refused. The form additionally expects a sign that a person really interacted with it and that a sensible amount of time passed before sending. Someone filling the form in normally notices none of this.
• QR Support now uses its own dedicated key to prove that an uploaded report really came from an appliance, instead of borrowing the key that also protects licensing. One key doing two unrelated jobs meant that recovering it from an appliance would also have exposed the licensing side, and neither use could be given a fresh key without breaking the other. Nothing changes in how the feature is used, and the reports themselves were already encrypted with a key that never leaves the appliance and the engineer.
• Switch passwords, enable passwords and SSH keys are now stored encrypted rather than in plain text. The encryption key lives on the appliance itself and never in the database, so a copy of the database alone no longer reveals how to log in to your switches. Existing switches are converted automatically the first time they are used after the update; nothing needs to be re-entered.
• Messages the appliance writes to the log can no longer be tampered with to fake additional log entries. A specially crafted value — for example a login name containing a line break — could previously be made to appear as a separate, invented log record with a timestamp and source of the attacker's choosing. This mattered little while these messages stayed on the appliance, but they can now be forwarded to your own log collector, where a forged record could mislead an investigation. Messages are also capped at a safe length now, so an over-long entry is cut off cleanly and marked as such instead of arriving damaged.
• A failed two-step verification code is now recorded in the audit log. Previously only the sign-in attempt counter was increased and nothing appeared in the audit log, which meant repeated guessing of verification codes — by someone who already had the correct password — left no visible trace.
• The verification sum on the forgotten-password page is now drawn as a picture instead of being written into the page as text. Previously the sum was present as readable text, so an automated script could take the answer straight from the page without ever looking at the image. The sum is now also single-use: it changes after every attempt, so an answer that has been solved once can no longer be submitted over and over. It additionally uses a wider range of numbers and both addition and subtraction, and an extra invisible check was added that automated submissions give themselves away on but visitors never see or notice.
• A failed attempt on the forgotten-password page now actually costs something. Previously only a *successful* submission started the waiting period, so a wrong answer could be retried immediately and without limit — which meant the verification sum could simply be guessed over and over until one landed, without ever having to read it. Repeated failures from the same connection are now counted and temporarily refused, the sum uses a wider range of numbers so a lucky guess is far less likely, and the invisible decoy check now differs per visitor instead of always being the same one.
• The forgotten-password page now also expects some sign that a real browser drew the form and that someone actually used it before submitting. A submission sent straight at the page without ever loading it, or sent within a moment of loading it, is refused. Any kind of interaction counts — mouse, touch screen or keyboard — so this never depends on the visitor having a particular device, and the page says plainly what to do if the check gets in the way.
• No visitor address is stored for any of this: only an irreversible fingerprint of it, which is removed after a week.

Ansible-Update

Added

• The tables behind the new form protection are installed automatically during an update, so no manual step is needed.
• Storage for the new abuse limits on the forgotten-password page is created automatically during the update, so existing appliances get the protection without any manual step.
• Appliances receive the dedicated QR Support key during an update, so existing installations pick it up automatically. The key is shared with PrivateLAN's own systems, which is what lets an uploaded report be recognised as genuine; the report's contents stay unreadable to PrivateLAN either way.
• The default service port configuration is now installed with the appliance, so the feature works without having to save it by hand first.
• A background task now runs every few minutes to close service ports whose maintenance session has expired. Without it the fixed session length would be advisory only.
• Storage for the service ports feature is created automatically during the update, on both existing and newly installed appliances.
• Incoming log messages are now rate limited per sending device, both in the appliance firewall and in the logging service itself, so a single misbehaving or compromised device on the management network can no longer flood the appliance's log database. The limit is applied per device, so one noisy switch never stops the others from logging, and the logging service records a message when it starts throttling a sender. Normal volumes stay well within the limits, including a switch rebooting and reporting every port at once. Messages the appliance generates about itself are covered too. Existing appliances pick this up automatically on their next update.
• As a final safeguard, if the log database ever falls far behind under an extreme flood, routine informational messages are now discarded first so that warnings and errors still get recorded. This applies to existing appliances as well as newly installed ones.

Changed

• After an update finishes, the version number shown at the bottom of the menu is now set immediately, as part of the update itself. Previously it was only refreshed as a side effect of opening the update or changelog page, so every other page kept showing the previous version until someone happened to visit one of those two pages.
• The appliance firewall now counts the log messages it discards under the per-device rate limit, separately per protocol, so the dashboard can show whether messages are being dropped right now. Existing appliances pick this up automatically on their next update.

Security

• One of the logging service's configuration files contains a database password and was readable by any account on the appliance. It is now restricted to the system administrator account only. Existing appliances are corrected automatically on their next update.

Fixed

• Long-term protection for the log database: the counter used to number stored log messages could previously run out under sustained heavy logging, after which no further messages could be stored at all and no clean-up would repair it. The counter has been enlarged so this can no longer occur. Existing appliances are converted automatically during the update; searching the Syslog page by sender tag is faster as a result of the same change.
• The logging service no longer fills the Syslog page with harmless-but-confusing entries about itself: two internal security-framework access denials and a deprecation warning from the log daemon. None of them ever indicated a fault — logging to the database, the per-device rate limiting and forwarding to an external collector all worked correctly throughout — but they cluttered the page and were forwarded along to any external collector. One appeared whenever the logging service restarted, for example after saving the syslog forwarding settings; the other appeared continuously, because the new per-device rate limiting needs to identify the process it is limiting. Existing appliances pick this up automatically on their next update.

Scripts

Added

• The appliance can now read the traffic figures of its own network connections, and the counters of log messages its firewall has discarded. Both are what the new dashboard tiles display.

Fixed

• Forwarding set to "PrivateLAN messages only" now really does send everything the appliance reports about itself. Previously it only forwarded what the web interface logged, so virus detections, automatic self-repair actions and restarts, failed or blocked updates, and an automatically closed SSH port were all left behind — exactly the messages worth sending to a central collector. Existing appliances correct this automatically on their next update.

Ansible-Deploy

Added

• Newly installed appliances get the form protection tables as part of provisioning.
• Newly installed appliances receive the dedicated QR Support key as part of provisioning, so the feature works on a fresh installation without a manual step.
• Newly installed appliances get the same storage for the forgotten-password abuse limits from the start, so a fresh installation and an updated one behave identically.
• Newly installed appliances get the same service port clean-up task and storage as appliances receiving it through an update.
• Newly provisioned appliances get the same per-device rate limits and log-database safeguard from the start.
• Newly provisioned appliances start with the enlarged log-message counter and the same audit-event forwarding behaviour, so a fresh installation and an updated one behave identically.
• Newly installed appliances start with the same firewall counters behind the new syslog flood tile, and the same permission to read them, as appliances that receive them through an update.

Fixed

• Newly provisioned appliances get the same corrected logging configuration from the start.

Ondersteund tot 28-08-2031

26.8.22 - 28-08-2026

Web

Fixed

• Downloading a certificate or software bill of materials no longer records a spurious "page not found" event in the background. The download itself always worked correctly; only a stray internal notice was being logged each time. A download link that has expired or is no longer valid still shows a proper "not found" page.

Ondersteund tot 28-08-2031

26.8.21 - 28-08-2026

Web

Fixed

• Ports supplying power over the network cable (PoE) are now shown with the correct power indicator again on the Deployment page, the Inspection pages and in the network interface overview PDF report. Because of a capitalisation mismatch in the comparison, active PoE ports were drawn as ordinary ports on those screens. The Device page was not affected.

Ondersteund tot 26-08-2031

26.8.20 - 26-08-2026

Web

Fixed

• Generating the "Network interface overview (PDF)" report from the Reports page no longer records a spurious "page not found" event in the background. The report itself was always produced correctly; only a stray internal notice was being logged each time.

Scripts

Fixed

• When the WAN interface (Eth1) uses DHCP, outbound traffic such as updates and the assistant could be sent via the LAN interface (Eth0) instead of the WAN, leaving those internet-dependent features without connectivity. Outbound traffic now correctly prefers the WAN interface, while the LAN interface stays the fallback and all internal VLANs remain reachable via it. After updating, save the Eth0 settings once (or reboot) to apply the corrected routing.

Ondersteund tot 26-08-2031

26.8.19 - 26-08-2026

Web

Changed

• The dashboard "Syslog warnings (24h)" counter no longer includes the appliance's own internal operating-system messages, so routine background notices from the appliance itself no longer inflate the count. The tile now reflects warnings from your network equipment only.
• On the Edit VLAN screen, the "Management VLAN" explanation is now shown under its own heading for clearer layout.

Ondersteund tot 26-08-2031

26.8.18 - 26-08-2026

Web

Added

• The Edit VLAN screen now explains what the "Management VLAN" option does, shown under the routing (HSRP/VRRP) explanation at the top of the page.

Fixed

• On the Inspection page, disconnected uplink ports are now detected correctly. Previously an uplink was only listed when it had also been marked as a non-device port, so trunk ports tagged only as trunk — and disconnected SFP/fibre uplinks — could be missed.
• When creating a new device, the "Is camera" option is no longer switched on automatically; it now correctly defaults to off. Un-ticking it on an existing device is now saved properly too.

Changed

• The Inspection page now shows a single "Disconnected ports" list with a new "Type" column indicating what each port is (for example [TRUNK], [SFP] or [ND]), instead of two separate lists. Trunk uplinks are flagged to reconnect; unused non-device and SFP ports can be disabled straight from the list.
• The Network inspection page has moved under the Inspection section. Any saved bookmark to the old address should be updated.

Ondersteund tot 26-08-2031

26.8.17 - 26-08-2026

Web

Fixed

• On the deployment setup screen, the "Device group" dropdown no longer lists an empty entry reading "(VLAN / )". Device groups that are not linked to a VLAN are now left out, so only selectable, VLAN-linked device groups appear.
• The appliance can now log its own events to the built-in syslog server, so they appear in the Syslog list alongside network-device messages and can be forwarded to an external syslog server. Previously this internal logging path did not work. When "PrivateLAN messages only" forwarding is selected, exactly these appliance-generated messages are the ones forwarded.

Ondersteund tot 25-08-2031

26.8.16 - 25-08-2026

Web

Fixed

• On the "Program VLAN into switches" screen, the status messages for a VLAN that is being removed from a switch now appear together under that VLAN's own heading, instead of the "trunk ports updated" line showing up under the previous VLAN. This is a display-ordering correction only; the actual switch programming was already correct.
• Switch operations (programming VLANs or devices, refreshing switch data, and the per-interface monitoring actions) no longer fail with an "Internal server error" when a switch cannot be reached over the network. The unreachable switch is now clearly reported and skipped, and the remaining reachable switches are still processed.

Ondersteund tot 25-08-2031

26.8.15 - 25-08-2026

Web

Fixed

• Unticking "Management VLAN" when editing a VLAN now sticks. Previously the setting always turned itself back on after saving, so a VLAN could never be un-marked as the management VLAN from the web interface.

Ondersteund tot 25-08-2031

26.8.14 - 25-08-2026

Web

Fixed

• Programming a VLAN into a Cisco switch no longer fails with a "500 - Internal server error" on the final save step. On some Cisco models the save could hang and time out (most visible when programming the management VLAN); the switch driver now reliably returns to the correct command context before saving, so the operation completes normally.

Changed

• Removed a leftover "Background Worker tasks added!" status message from the VLAN programming screens.

Ondersteund tot 25-08-2031

26.8.13 - 25-08-2026

Web

Fixed

• Programming a VLAN onto a Cisco switch no longer intermittently fails with a timeout on newer, higher-end models. Some Cisco models take about a second longer to return to the command prompt after applying configuration over SSH than the models tested so far; the switch driver now waits long enough for these slower models, while remaining just as fast on the others.

Ondersteund tot 25-08-2031

26.8.12 - 25-08-2026

Web

Added

• The Syslog page now has a "Syslog forwarding" section where an administrator can forward incoming syslog messages to an external syslog server, setting the destination address, port and protocol (UDP or TCP). Forwarding all messages, or turning it off (the default), takes effect immediately when saved; forwarding of PrivateLAN's own messages only will follow in a later release. Access is controlled by a dedicated permission.

Fixed

• Editing a VLAN and toggling whether it is the management VLAN no longer produces a server error; saving VLAN changes now works correctly again.
• On a device's Certificates tab, the "Needs password" indicator now correctly shows that the PEM and KEY downloads are protected by the client certificate password (they contain the device's private key). Previously they were marked as not requiring a password.

Changed

• The RADIUS configuration page now explains that the CA and Server certificate passwords are for internal use only, and that only the Client certificate password is needed to import or use client certificates.
• On the RADIUS configuration page the certificate passwords are now hidden by default. A new show/hide button next to each password field lets you reveal it when needed.
• Added a "generate password" button to the user edit page, creating a strong random password that meets the password policy and is copied to your clipboard.
• Clarified the certificate documentation: which downloadable client files contain a private key and require the client certificate password, and that the CA and Server passwords are internal only.

Ondersteund tot 25-08-2031

26.8.11 - 25-08-2026

Added

• Administrators can now open the system telemetry page directly to see, at a glance, whether telemetry reporting is working — including whether it is enabled, whether the system is on a production release, and whether the reporting connection is configured — with a clear explanation of anything that is preventing reports from being sent. A "Send now" button lets an administrator send a report immediately for testing, instead of waiting for the next scheduled moment.

Changed

• The License page has moved under the System menu. Licensing information and the fingerprint/Request ID workflow are now reached via System → License.

Fixed

• Automatic browser icon (favicon) requests no longer generate spurious "Page not found" telemetry events. These harmless background requests were being reported as warnings; they are now ignored, reducing noise in the diagnostics feed.
• On the License page, the "Unable to create a License Request ID" message no longer always points to the hardware fingerprint scan. It now states the actual reason — most commonly that the default administrator password has not been changed yet (which is required before a Request ID can be generated).

Removed

• Removed the in-appliance License Generation page. Licenses are now issued centrally and imported on the appliance, so this internal tool is no longer part of the product.

Ondersteund tot 25-08-2031

26.8.10 - 25-08-2026

Added

• Added an automatic self-healing watchdog that continuously keeps an eye on the appliance's core services and its web interface. If a service stalls or the web interface stops responding, the system now tries to recover on its own — first by restarting the affected services, then by re-applying the current software installation, and only as a last resort by rebooting. To avoid reacting to brief hiccups (such as the short restarts that happen during a normal update), it only steps in once a problem has genuinely persisted for a few minutes, and it will never reboot while network authentication is still working for your devices. All recovery actions are recorded so they stay visible.

Changed

• Clarified the wording and icon on the "Web Interface Access Restriction" security setting, making it clearer that the restriction applies to LAN networks and that access from the internet-side (WAN) network is always blocked by default.

Fixed

• Fixed updates occasionally failing with a "no internet connection" error when the connection dropped only briefly during the update. The system now re-checks the connection a few times over about 20 seconds before giving up, so a momentary blip no longer aborts an otherwise successful update.
• Fixed the dashboard continuing to show "Update available" for up to an hour after an update had already been installed. The update status is now cleared as soon as an update finishes, so the dashboard reflects the current state immediately.
• Fixed systems being unable to resolve DNS or reach the internet when the internet-side (WAN) network uses a private IP address range (for example when the appliance sits behind another router that hands out private addresses). In that situation the firewall was mistakenly discarding the replies from the local gateway and DNS server, so the update page reported "no internet connection available" even though the connection itself was working. Replies to the appliance's own outbound traffic are now allowed correctly, while protection against spoofed traffic from the WAN is kept intact.

Ondersteund tot 24-08-2031

26.8.9 - 24-08-2026

Changed

• Improved recovery after a disk-image style update: required database changes are now applied at boot without depending on the web interface, so a system brought up on a new image self-heals even if it would otherwise have been stuck. Also removed a redundant internal check that ran every few minutes — database changes are still applied automatically during every update and at boot.

Ondersteund tot 24-08-2031

26.8.8 - 24-08-2026

Fixed

• Fixed the system sending a "migrations completed" status notification every 5 minutes even when there was nothing to do. This routine check is now silent unless a database change is actually applied.

Ondersteund tot 24-08-2031

26.8.7 - 24-08-2026

Fixed

• Fixed a case where a system that had already ended up on the "Service Temporarily Unavailable" page after a previous update could not recover by updating again — each update reported success but the page stayed down. Required database changes are now applied in a way that no longer depends on the web interface being reachable, so simply running an update now brings such a system back online on its own.

Ondersteund tot 24-08-2031

26.8.6 - 24-08-2026

Fixed

• Fixed an issue where installing an update that included a database change could leave the web interface temporarily showing "Service Temporarily Unavailable". Database changes are now applied before the new version of the software is put in place, so the update completes cleanly. If a database change cannot be applied, the update now stops safely and keeps the current working version running, instead of switching to the new version first.

Ondersteund tot 24-08-2031

26.8.5 - 24-08-2026

Web

Added

• A new REST API for managing devices, VLANs, device groups, switches, switch groups, and VLAN group assignments programmatically, secured with API keys. An API key is created from the Users page just like a regular account, is assigned roles and a license slot the same way, and can optionally be restricted to specific source IP addresses. The API can also list a switch's ports (to find one to use), assign or remove a switch port on a device, set a patch point note on it, and issue or revoke a device's certificate. Every error response uses a single, consistent numeric error code across the whole API, so integrations only need to handle each error once. Full documentation, including authentication and example requests, is available on the support website.
• The API can now also trigger operational actions on a device or switch — restarting, enabling or disabling a port, forcing a device to re-authenticate, reloading or factory-resetting a switch, or clearing its counters — and read back live status, without needing the web interface.
• The API can now report the current status of many devices at once (link state, authentication state, discovered neighbor) for dashboards and monitoring integrations, alongside a live, on-demand status check for a single device or switch.
• Long-running API actions (like certificate generation) now return a job reference that can be checked for progress, checked for its result, cancelled before it starts, or retried after it finishes.
• Device and CA certificates can now be downloaded directly through the API using the same API key used for everything else, instead of only through the web interface.
• Every resource in the API (devices, VLANs, device groups, switches, switch groups, and both VLAN group-link types) can now be partially updated — sending only the field(s) that changed, leaving everything else untouched — instead of always having to resend the entire record.
• Every list returned by the API (devices, VLANs, device groups, switches, switch groups, and both VLAN group-link types) can now optionally be paged through a limited number of results at a time, instead of always returning the full list in one response. Existing integrations that don't ask for this are unaffected and keep getting the full list exactly as before.
• Integrations can now safely retry a create-a-new-item request (or an action that queues a background job, such as certificate generation or a switch sync) after a network hiccup, without risking creating or queuing the same thing twice — by sending the same unique key with both the original and the retried request.
• The API can now report system update status (current version, whether a newer version is available, whether an update is currently running, and whether a reboot or firmware update is pending) and can trigger a system update, so this can be automated without using the web interface.
• The API now publishes a machine-readable specification (OpenAPI) at /api/openapi.json, and a browsable reference page at /api/docs — both public, no login required — so the full set of endpoints can be explored or imported into tools like Postman without reading the written documentation first.
• The System Security page now lets you restrict which networks are allowed to reach the web interface, by entering one or more allowed IP addresses or network ranges. Visitors from any other network see a clear message that access is restricted, instead of the login page. Leaving this empty (the default) allows access from any network, as before. This is controlled by a dedicated permission, so it can be granted only to specific administrators rather than everyone who can view the security page.
• You can now create webhooks: when a chosen event happens (such as a switch going offline, or a device authenticating), PrivateLAN sends an outbound HTTP request to a URL you configure. A webhook's target isn't limited to a receiving server you build yourself — the request method, authentication, and message shape can each be customized, so the same webhook can also be pointed directly at a network I/O relay module's own control endpoint (for example, to flip a relay when a switch goes down). Optional conditions (matched with AND or OR) let a webhook fire only when specific details of the event match, not just its type. Delivery attempts are retried automatically with backoff if the target doesn't respond, and a delivery log (showing the 5 most recent deliveries, kept for 28 days by default and configurable) is available per webhook. A "Trigger" button lets you send a one-off test delivery for a webhook at any time, without waiting for a real event.
• Webhooks can now also be triggered by a few new system-level events, in addition to a switch going online or offline: a critical entry appearing in the audit log, a system reboot becoming required, a firmware update becoming available, and a new PrivateLAN update becoming available. Each of these only fires once when the condition first appears, not repeatedly while it remains outstanding. A pending reboot is now detected within a minute of it becoming necessary, instead of only being noticed the next night.
• The reboot/firmware update/PrivateLAN update events above now also have a matching "resolved" event that fires once the condition clears (for example, once a pending reboot has actually happened). This makes it possible to use a webhook to switch something back off again (such as an indicator light or a relay) that an earlier webhook switched on.
• A new System > AI page lets you control the Tux AI assistant for the whole system: turn it off entirely, keep it to read-only lookups (the default), or allow it to also make changes (such as creating or editing devices and VLANs) for users who are separately given permission to do so. You can also choose to keep using PrivateLAN's own AI service, or connect your own AI server instead, with an optional extra set of instructions for it.

Changed

• Syslog and Auditlog moved into a new "Logging" menu, alongside the new Webhooks page.
• On the webhook edit page, the system-level events above are now highlighted with a light green background whenever their condition is currently true (for example, while a reboot is currently pending), making it easier to see the current system status at a glance.

Fixed

• Fixed an issue where some background jobs (including webhook deliveries) could be shown as "succeeded" in the system even when they had actually failed, because their real result wasn't being read correctly.
• Fixed an issue where the "reboot required" notice could disappear on its own after about a minute, even though a reboot was still actually needed.

Security

• A certificate download link inside the web interface was, in one internal step, read from disk through an extra system command instead of directly by the application; it has been simplified to read the file directly, removing that unnecessary step.
• Hardened webhooks so a webhook can no longer be pointed back at the appliance itself to reach internal-only functions that the person configuring the webhook would not otherwise be allowed to use. Webhooks aimed at other addresses on your network continue to work as before.
• The one-time secret shown when a webhook is created is no longer retained internally after it is displayed, so it can only ever be seen once as intended.
• Webhook delivery logs no longer record any detail about the length of a target's stored credential.

Scripts

Changed

• When an update fails, the automatic notification now also includes which step failed and why, instead of only saying that the update failed. This makes it possible to see the cause without needing to log into the system directly.

Ansible-Update

Fixed

• Fixed an issue where a configuration value needed by a newly released feature could fail to actually reach an already-running system during a regular update, even though the update itself reported success — the value would only take effect on a freshly installed system. Updates now always apply these values, closing that gap for every existing installation.
• Fixed an issue where a system that was still on an older version could get permanently stuck failing every update attempt, because an early step in the process depended on a newer part of the application that hadn't been installed yet. That early step no longer blocks the rest of the update when this happens, so the system can update normally again.

---

Ondersteund tot 20-08-2031

26.8.4 - 20-08-2026

Scripts

Fixed

• Fixed the actual cause of the time synchronization service failing to start after certain system upgrades: a technical marker this system added to its own configuration turned out to be invalid syntax for the currently installed version of that service, so it never started. The previous release's fix reduced how often this could happen but did not fully resolve it; this corrects it properly.

---

Ondersteund tot 19-08-2031

26.8.3 - 19-08-2026

Ansible-Update / Ansible-Deploy

Fixed

• Fixed the root cause of the previous release's automatic network setup fix: the system's internal name resolution was, since initial installation, mistakenly making itself always look like one of PrivateLAN's own internal development systems, which silently prevented automatic first-boot network configuration from ever running — on essentially every system, not just newly deployed ones. This is now corrected.

Removed

• Removed a leftover, unused piece of internal setup configuration that was superseded by the improved automatic network setup shipped in the previous release.

---

Ondersteund tot 19-08-2031

26.8.2 - 19-08-2026

Web

Changed

• On the system update page, the "Read disclaimer" button is now hidden as soon as an update starts, alongside the "Update now" button, so neither can be clicked again while an update is running.

Fixed

• Fixed an issue where, during automatic first-boot network setup on a newly deployed system, an unrelated failure elsewhere on the same page (such as the time server being temporarily unavailable) could silently prevent the network address settings from being applied.
• Fixed a small display glitch on the login page where a failed login sometimes showed a stray "2" in the error message.

Scripts

Fixed

• Fixed an issue where the time synchronization service could fail to start after certain system upgrades, due to a leftover incompatible setting, which also prevented the automatic network setup on affected systems from correcting the problem on its own.

Ansible-Update / Ansible-Deploy

Fixed

• The system now automatically corrects its own internal network name resolution on every update, so a manually customized entry from before a system was cloned or reinstalled can no longer cause automatic first-boot network configuration to be skipped.

---

Ondersteund tot 16-08-2031

26.8.1 - 16-08-2026

Ansible-Update / Ansible-Deploy

Added

• Production systems now automatically verify every night that remote administrative SSH access is blocked, and will re-block it automatically if it was left open. This never runs on development/test systems. A notification is sent when this automatic protection actually has to act.
• The system now checks in the background, once an hour, whether a new PrivateLAN version is available, so the dashboard can show this without needing to open the system update page.

Changed

• Improved the wording and layout of the informational page shown when a browser reaches the server without app.privatelan.nl set up in local DNS yet.

Fixed

• Fixed the default EAP-TLS port configuration template for Aruba CX switches, which used an incorrect command that could prevent 802.1x authentication from being enabled correctly.

Scripts

Changed

• Generated Software Bill of Materials (SBOM) files are now cleaner and easier to import into third-party SBOM and vulnerability-scanning tools, and no longer require manually picking a component type.

Fixed

• Fixed an issue where 802.1x (EAP-TLS) authentication using client certificates could fail with a certificate-revocation-list error, even when the certificate and revocation list were valid.

Security

• Revoking a single device's certificate now takes effect immediately instead of only being enforced after the next scheduled nightly maintenance window.

Web

Added

• The dashboard now shows an "Action needed" summary at the top, highlighting open inspection warnings and devices waiting to be deployed, so nothing gets missed without visiting each page separately.
• The dashboard's "Action needed" summary also now shows whether a reboot or a firmware update is pending, how many devices have no group assigned, recent syslog warnings, and antivirus/firewall status — each shown only to users with access to the corresponding page. The antivirus tile also shows whether the system is currently virus-free and how long ago it was last scanned. A "Recent activity" list of the latest audit log entries was also added.
• The dashboard now also shows whether a new PrivateLAN version is available, alongside the existing reboot and firmware update indicators.

Changed

• Clarified the dashboard's firmware update notice: it checks for an unrelated, separate type of update from the regular Ubuntu security updates, and normally has nothing to report on a virtual appliance.
• The dashboard now only lists items that actually need attention under "Action needed"; everything else that's already fine moved to a new "System status" section underneath, instead of being mixed together.
• The dashboard's recent activity list now only shows entries that were not successful, so it highlights problems instead of routine successful actions, and also shows the source address and page for each entry, matching the full audit log page.
• The dashboard's overview widgets are now grouped into clearly labeled sections ("Network overview" and "Devices & security") for easier scanning.
• Devices waiting for deployment and devices without a group now have their own dedicated "Device status" section on the dashboard instead of being mixed in with the general "Action needed"/"System status" tiles.
• The update button on the system update page is now hidden once an update has been started, preventing it from being clicked again while an update is already in progress.
• The device list and related overview pages now visibly highlight a switch when it cannot be reached, making it clear that the link/PoE/MAC status still shown for its connected devices is a last-known value rather than current.

Fixed

• Fixed the audit log and syslog filters silently showing all results instead of filtering when a filter value of "0" was entered (e.g. searching for the "Emergency" priority level).
• Fixed a small number of successful login/logout events being spelled inconsistently in the audit log, which could cause them to be missed by status-based filtering or search.
• In the AI assistant chat, a reference link to an external page (the live service status page) previously appeared as plain text instead of a clickable link; it now renders correctly, alongside the assistant's existing internal links.
• Fixed 802.1x authentication status not being detected on Cisco switches, so the device page never showed the authenticated/unauthenticated icon for ports on those switches even when the port was correctly authenticating.
• Fixed the same authenticated/unauthenticated icon never being shown for HP/Aruba switches, because the authentication status for those switches was never actually being saved.
• Fixed garbled characters appearing on the device authentication status page when a connected client's name contained characters the switch itself could not display properly.
• Fixed the camera live view and the AI assistant chat repeatedly writing a misleading "page not found" entry to the audit log while in use, even though both features were working correctly.

Security

• Fixed the device authentication status page incorrectly showing a device on an Aruba CX switch port as successfully authenticated when it had actually failed authentication.

---

Ondersteund tot 13-08-2031

26.8.0 - 13-08-2026

Scripts

Security

• Removed a hardcoded internal authentication token from the automatic update process; it is now retrieved securely at runtime instead of being stored in the script itself.

Changed

• The release publishing pipeline no longer publishes a small number of internal-only helper scripts that only work against PrivateLAN's own infrastructure (no customer-visible impact).

Web

Changed

• The release publishing pipeline now tags each published release to match its source version (no customer-visible impact).

---

Ondersteund tot 22-07-2031

26.7.21 - 22-07-2026

Web

Fixed

• Fixed an issue where the system's automatic network-configuration recovery at startup did not actually reapply the saved settings, even though it appeared to run correctly.

---

Ondersteund tot 22-07-2031

26.7.20 - 22-07-2026

Ansible-Update / Ansible-Deploy

Security

• The pre-login console banner no longer shows the operating system name/version or kernel version, in line with standard hardening guidance for unauthenticated banners.
• The pre-login console banner now states that use is authorized and that activity is monitored and logged, as recommended hardening guidance requires.

Ansible-Update / Ansible-Deploy

Security

• A warning banner (authorized use only, activity monitored and logged) is now shown before anyone can log in over SSH, on new and existing systems alike.

Web

Added

• Aruba CX switches now show bandwidth utilization per port on the device page, matching what was already shown for other supported switch brands.

---

Ondersteund tot 22-07-2031

26.7.19 - 22-07-2026

Web

Added

• On the RADIUS client add/edit page you can now optionally pick an existing switch from a dropdown, which automatically fills in the client name and IP address for you.

Changed

• Reduced the amount of internal technical detail that could appear in error messages shown in the browser.
• The general status indicator now shows a count of active users instead of listing who is currently active.

Fixed

• Certain accounts with view-only access to devices could delete or restart devices without holding the required edit permission.
• Certain accounts with view-only access to users could delete other user accounts without holding the required permission.

Removed

• Removed an unused internal test page that was unintentionally reachable without logging in.

Security

• Fixed an issue where a specially crafted request header could be used to gain access to internal maintenance functions that are only meant to be reachable by the system itself.
• Fixed a stored cross-site scripting issue where information reported by a network device (via LLDP) could run malicious code in an administrator's browser session when viewing that device's discovery details.
• Improved the antivirus signature update process so an uploaded file can no longer be downloaded before it has been fully verified.

Ansible-Update / Ansible-Deploy

Security

• Updated the system permissions used by the antivirus signature update process to match the hardening described above.

---

Ondersteund tot 22-07-2031

26.7.18 - 22-07-2026

Scripts

Changed

• When an automatic update is stopped by the release security check, the update page and the internal alert now state the specific reason it was stopped, instead of a generic message.

Fixed

• A brief network interruption during the nightly update window no longer stops a valid update: the security check now retries before giving up.

---

Ondersteund tot 21-07-2031

26.7.17 - 21-07-2026

Web

Changed

• The release notes shown on the update page and in the in-app changelog no longer include an internal technical marker that was never meant for customers to see.

---

Ondersteund tot 21-07-2031

26.7.16 - 21-07-2026

No functional changes in this release.

---

Ondersteund tot 21-07-2031

26.7.15 - 21-07-2026

Scripts

Fixed

• The live update log could show leftover messages from a previous, unrelated update, occasionally causing a blocked or failed update to incorrectly attempt a follow-up step meant only for a successful one. The log now always starts clean for each update attempt.
• The live update log could briefly show unrelated technical error noise unrelated to the actual update status.

---

Ondersteund tot 21-07-2031

26.7.14 - 21-07-2026

No functional changes in this release.

---

Ondersteund tot 21-07-2031

26.7.13 - 21-07-2026

Scripts / Ansible-Update / Ansible-Deploy

Fixed

• Applying an update could occasionally leave a background status process running longer than it should, or briefly show an unrelated informational message during an update. This has been cleaned up.

---

Ondersteund tot 21-07-2031

26.7.12 - 21-07-2026

Scripts

Fixed

• The previous fix for the update page hanging on "Connecting to the update service…" during a blocked or failed update did not actually work in all cases, because the status service it depends on failed to start correctly. This has been corrected.

---

Ondersteund tot 21-07-2031

26.7.11 - 21-07-2026

No functional changes in this release.

---

Ondersteund tot 21-07-2031

26.7.10 - 21-07-2026

Scripts

Fixed

• If an update could not be applied (for example because our new authenticity check blocked it, or a temporary network problem), the update page in the web interface used to keep showing "Connecting to the update service…" forever, without ever explaining what went wrong. The update page now shows the actual error message in this situation, the same way it already does for other update problems.

---

Ondersteund tot 21-07-2031

26.7.9 - 21-07-2026

No functional changes in this release.

---

Ondersteund tot 21-07-2031

26.7.8 - 21-07-2026

Web

Fixed

• Checking for available updates could occasionally time out too quickly when reaching our update server on a slower connection, showing an "unable to check for updates" message even though it would have succeeded with a little more time. The system now waits longer before giving up.

Scripts

Security

• Before applying an update, the system now verifies its authenticity against an independently published checksum. This means that even if the update source were ever compromised, it could no longer push a malicious update to your system without also compromising a second, separate system.

---

Ondersteund tot 21-07-2031

26.7.6 - 21-07-2026

Web

Changed

• When checking for updates fails, PrivateLAN Support users now see the underlying technical reason instead of just a generic "unable to check for updates" message, making it much faster to diagnose an intermittent connectivity issue to the update server.

---

Ondersteund tot 21-07-2031

26.7.5 - 21-07-2026

Web

Fixed

• The reboot confirmation could show a raw browser error message instead of the normal "rebooting" progress screen, on systems fast enough that the reboot cuts the connection before the confirmation response finishes sending — that is actually the expected outcome, not a failure.

Ansible-Update / Ansible-Deploy

Fixed

• Certain error responses from the update page's action buttons (such as applying a firmware update) could be silently replaced by a generic web server error page instead of the actual explanation, making it impossible to see what went wrong.

---

Ondersteund tot 21-07-2031

26.7.4 - 21-07-2026

Web

Fixed

• Fixed a bug that could crash the update page with an error instead of showing "unable to check for updates" when the update server was temporarily unreachable.
• Checking for updates could hang for several minutes if the update server was temporarily unreachable, which could make the entire web interface unresponsive during that time. This check now gives up after a short timeout instead of waiting indefinitely.

Ansible-Update / Ansible-Deploy

Fixed

• A system that had never successfully applied its backlog of pending database updates could fail to update at all, because two of those pending updates were being applied in the wrong order. Updates now always apply in the correct order, so this can no longer happen.

---

Ondersteund tot 21-07-2031

26.7.3 - 21-07-2026

Web

Added

• Added a generate-password button next to the RADIUS client secret field and the RADIUS certificate password fields. It fills in a strong random password and copies it to your clipboard automatically, with a small notification centered on screen confirming whether the copy succeeded — if not, the password is shown so you can copy it yourself.
• The update page now shows a banner with an "Apply firmware update" button when a device firmware update is available, similar to the existing reboot-required banner. Firmware updates are never applied without your confirmation — clicking the button reviews and applies the update directly from the page, no SSH access needed. If a reboot is needed afterwards, the familiar reboot banner appears.
• The system status panel now also shows a notice when a firmware update is available, combined into a single line with the existing reboot notice if both apply at once.

Changed

• Reorganized internal application files for maintainability. No visible behaviour change.

Fixed

• The RADIUS client secret field wasn't marked as required, even though a secret must be set when adding a new client.
• Fixed a broken "Add" link on the RADIUS clients page.
• The reboot confirmation on the update page could show a "rebooting… server is back online" animation even when the reboot was never actually triggered (for example an expired confirmation), misleading the operator into thinking it worked.
• The backup-confirmation step of the update flow used an inconsistent color (a green "Yes" for the option that continues toward the update, a red "No" for the option that just cancels), unlike every other confirmation on the page where red always leads toward the impactful action and grey always cancels.
• Clicking "Update now" could silently do nothing at all (the update page just showed "Connecting to the update service…" forever, with no update actually running) due to a file-ownership conflict between two processes writing to the same temporary log path. Systems still running an older version self-heal this automatically during their next update — no action needed.

Ansible-Update / Ansible-Deploy / Scripts

Fixed

• Database structure updates could be skipped when the system updated itself automatically overnight, which could cause errors until the update page was opened manually or the system was rebooted. Database updates are now always applied immediately as part of every update, including automatic overnight updates.
• Visiting a non-existent page now shows the application's own "page not found" message instead of a plain, unstyled web server error page.
• A routine operating system security update could, in rare cases, interrupt a system update that was already in progress partway through, requiring a second update run to finish. Updates now run independently of the web server process, so this can no longer happen.

Added

• Every update now also checks for available device firmware updates and reports them on the update page, where they can be applied with one click after confirmation. Firmware updates are deliberately never applied without that confirmation, since a failed firmware update carries more risk than a failed software update.

Changed

• Automatic overnight updates now start after a small random delay from the scheduled time, so that many systems don't all connect to the update server at the exact same moment. Manually starting an update from the update page is not affected and always starts immediately.

Ondersteund tot 19-07-2031

26.7.2 - 19-07-2026

Web

Added

• Stack members can now be given an optional Location and Rack of their own, for the uncommon case where a member of a switch stack is physically installed in a different room or rack than the rest of the stack.
• Each interface on a device's edit page can now be given an optional patch point (e.g. "Patch panel 3, port 12"), so the physical cabling location is recorded per port and stays in place even if the port is later reassigned to a different device.
• The Network interface overview PDF report now shows each port's patch point, and its header now shows your configured system name as the project name.
• The Network interface overview PDF report now shows a switch's individual stack members (model, serial, firmware, uptime) underneath the stack, the same way the switch overview page already does.

Changed

• Reduced the page margins on the Network interface overview PDF report so more ports fit on a single page.
• Moved the Network interface overview PDF report to its own location under Reports; the "Reports" page link has been updated automatically.

Removed

• Removed the manual "Group position" option when adding or editing a switch. Switches within a group are now shown in a clear, predictable order automatically.

Fixed

• The update page could show a "something went wrong" error message even though the update had actually completed successfully. Also corrected the timestamps shown in the live update log, which could appear a couple of hours off.
• The Network interface overview PDF report could show a broken icon, or no icon at all, for whether a port was actively authenticated.

Ondersteund tot 19-07-2031

26.7.1 - 19-07-2026

Web

Added

• The switch overview now shows an icon next to a switch's name when it is detected to be part of a physical switch stack (multiple switches managed as one), so it's easy to see at a glance which entries represent a stack.
• For a detected switch stack, the individual physical members are now shown as extra rows underneath the stack, each with their own model, serial number, firmware, uptime, CPU load, temperature and PoE usage where available. The stack's own summary row no longer repeats this per-unit information.

Removed

• Removed the short one-line description column from the "Available updates" table on the update page; it never reliably worked and the full release notes below already cover the same information.

Fixed

• Fixed a display issue on the device edit page where the live camera preview could overlap and hide the status panel in the page header when scrolling.
• Fixed a large blank area at the top of the update progress window on the update page.
• Corrected a typo in the example text on the switch interfaces page.
• Fixed an error that could occur during the periodic cleanup of expired login sessions.

Security

• The device lock setting now also applies to the camera settings and customization settings on a device's edit page, closing a gap where those settings could be changed while the device was supposed to be locked.
• Added missing anti-forgery protection to several forms and actions (automatic update settings, branch selection, audit log retention, SBOM generation, license management, network inspection actions, the switch interconnects diagram, and the login/logout forms) so they can no longer be triggered from another website while a user is logged in.
• The network inspection event actions (acknowledge, snooze, resume monitoring) now correctly require the same permission as the rest of that page.

Scripts

Added

• Added a small helper script that keeps pending database updates ready to be applied automatically when the system boots.

Ansible-Update / Ansible-Deploy

Added

• Database structure updates are now also applied automatically every time the system boots, in addition to the existing update process. This closes a gap where a system updated by replacing its virtual machine (while keeping its existing data) could end up running newer software against an older database structure.

Fixed

• Resolved several harmless but noisy system log messages related to the antivirus service, system logging, and platform housekeeping, so the system log view stays cleaner.

Security

• Disabled system crash dumps entirely, reducing the risk that sensitive data held in memory could ever be written to disk.

Ondersteund tot 28-06-2031

26.6.22 - 28-06-2026

Web

Added

• Added an optional live camera view for devices. When a device is flagged as a camera, you can configure its login details and view a periodically refreshed image directly from the device page, with a download button and an on-screen clock. The connection to the camera is detected automatically, so nothing needs to be changed on the camera itself. The view automatically stops when you leave the page or after a period of inactivity.
• The device "Username" and "Password" fields are now labelled "Auth. Username" and "Auth. Password" to distinguish them from the new camera login fields.

Changed

• The camera live view feature is now a licensed add-on: it, and the option to enable it on the System page, are only available when included in your license.

Security

• Camera login credentials are encrypted before being stored, using a server-specific key that is never stored in the database itself.
• The live camera view and the camera settings are only available to users who have been granted the relevant camera permissions.

Ansible-Update

Changed

• Removed leftover internal upgrade logic from an early, never-released version of the camera live view feature.

Ondersteund tot 22-06-2031

26.6.21 - 22-06-2026

Web

Fixed

• Fixed a bug that could cause the device edit page to fail to load correctly in the browser.
• Fixed a typo in the main menu's "Dashboard" link.
• Fixed VLAN, routing and trunk configuration for Aruba CX series switches, which previously used commands that do not exist on that platform.
• Hardened the default port security behavior applied to new Aruba CX series switches.
• Improved security and reliability of the switch deletion page, and corrected an issue where the "Default all ports (Lockout)" deletion option did not default any ports.

Added

• Added a new "SVI" routing mode, for switches that do not support VRRP or HSRP redundancy (such as the Aruba CX 6100).
• The "Factory reset" option when deleting a switch, and the "Reload" action on the switch list, now actually carry out the action on the switch itself, instead of only removing the switch from the system.

Changed

• Cleaned up unused legacy code in the interface-reset logic. No change in behavior for users.

Security

• Hardened the database queries used by the device, switch, deployment, certificate, VLAN, device group, switch group, RADIUS client, and AI assistant pages, reducing the risk of malicious input affecting the database.
• Hardened the commands run on the server by the device/switch ping check and the system file editor, reducing the risk of malicious input affecting the underlying operating system.
• Hardened the display of device, switch, VLAN, RADIUS client, file, and deployment information across many pages, reducing the risk that data shown in the interface could affect other users' browsers.
• Fixed the background task runner to always use the system's configured hostname instead of a value supplied by the incoming web request, preventing it from being redirected to an unintended address.
• Added per-page security tokens to a large number of administrative forms and action buttons (system, network, switch, device, VLAN, RADIUS, file editor, deployment and license pages), preventing malicious websites from tricking a logged-in administrator into unintentionally performing actions on their behalf.

Ansible-Deploy

Added

• Added support for deploying on additional virtualization platforms, including automatic detection and renaming of network interfaces during initial setup.

Security

• Improved isolation of the database management tool from the rest of the system, reducing the impact of a potential compromise.

Ondersteund tot 17-06-2031

26.6.20 - 17-06-2026

Web

Fixed

• Fixed an issue where creating a new switch would not save all its configuration details correctly.
• Fixed incorrect internal key names for the default VLAN configuration settings.

Ansible-Deploy

Added

• Added additional server deployment target configurations.

Ondersteund tot 15-06-2031

26.6.19 - 15-06-2026

Web

Added

• New AI assistant, "Tux", in the web interface for systems whose licence includes the chat option. Tux helps you find your way around PrivateLAN and points you to the right settings page, with a direct link. It clearly identifies itself as an automated assistant, only answers questions about PrivateLAN, and never discusses pricing. The assistant is available to users who have been granted the chat permission, and administrators can additionally control which categories of system information (devices, switches, VLANs) it is allowed to use when answering. Conversations are not kept beyond your current browser session.
• The AI assistant can now take a deeper look at an individual switch — its configuration, interface statistics and authentication status — to help troubleshoot more complex questions. For your security, any passwords, secrets and other credentials in that data are automatically removed before the assistant can use it, and the assistant will never reveal them.

Fixed

• Fixed the link used to display release notes on the update page.

Ansible-Update

Security

• Added an extra safeguard that explicitly disables forwarding of network traffic between the management network and the internet-facing connection, on top of the existing firewall protection. This is applied to existing systems automatically as part of the update.

Ansible-Deploy

Security

• New installations now include the same explicit safeguard disabling traffic forwarding between the management network and the internet-facing connection, plus a rate limit on incoming ping traffic on the internet-facing connection to reduce exposure to scanning.

Ondersteund tot 13-06-2031

26.6.18 - 13-06-2026

Web

Fixed

• Fixed a server error that could cause the update page to show "Could not reach migrations endpoint" after an otherwise successful update.

Scripts

Fixed

• Fixed an issue where, under certain development/testing version sequences, the automatic update check could fail to detect a newer release that was actually available.

Ansible-Update

Fixed

• Fixed an issue where some successful system updates could be incorrectly reported as failed, due to a timing issue while shutting down the live update progress log.

Ondersteund tot 13-06-2031

26.6.16 - 13-06-2026

Scripts

Changed

• When set to the stable update channel, the system now only considers official stable releases when checking for updates, and automatically switches back to the latest stable release if a pre-release version was previously installed.

Ondersteund tot 12-06-2031

26.6.15 - 12-06-2026

Web

Fixed

• Fixed an issue where the live update progress log could fail to connect and show a browser security error when the update page was accessed over a secure connection.

Ansible-Update

Security

• The live update progress log now streams over the same secure connection as the update page itself, instead of a separate connection. The web server's security policy was also tightened accordingly.

Ansible-Deploy

Security

• Applied the same update-log security hardening as Ansible-Update to newly provisioned systems, and removed a firewall rule that is no longer needed.

Ondersteund tot 12-06-2031

26.6.14 - 12-06-2026

Web

Added

• The system now periodically reports basic health information (CPU, memory, disk usage, uptime, and service status) to PrivateLAN once per hour, at a randomized time per system, in addition to existing telemetry events.

Security

• Fixed an issue where telemetry sent under the "anonymous" setting could still be linked back to your license. Anonymous telemetry now sends a one-way hash that cannot be traced back to your license, company, or user.

Scripts

Added

• Added a script that collects basic system health information (CPU, memory, disk usage, uptime, and core service status) for fleet health monitoring.

Changed

• Renamed an internal telemetry helper script (no customer-visible impact).

Ansible-Update

Added

• Added a scheduled task and the necessary permissions to support the new periodic system health reporting.

Ansible-Deploy

Added

• Added a scheduled task and the necessary permissions to support the new periodic system health reporting on newly provisioned systems.

Ondersteund tot 12-06-2031

26.6.13 - 12-06-2026

Scripts

Fixed

• Fixed an issue where the updater could fail to switch to a new version due to leftover local file changes from a previous step.

Ansible-Update

Fixed

• Fixed an issue where the update process could not read any of its stored credentials, causing the "Updating Git repositories" step to fail.

Changed

• The web server configuration step now consistently grants the configured administrator account access to the web files, removing a leftover temporary check.
• The internet connectivity check used at the start of every update now uses a PrivateLAN-managed address instead of a public DNS server.

Security

• The update process now keeps its encrypted credential store in sync automatically, so future credential updates no longer require manual server-side configuration.

Ansible-Deploy

Changed

• The internet connectivity check performed during initial server setup now uses a PrivateLAN-managed address instead of a public DNS server.

Security

• The provisioning process now keeps its encrypted credential store in sync automatically, so future credential updates no longer require manual server-side configuration.

Ondersteund tot 12-06-2031

26.6.12 - 12-06-2026

Web

Fixed

• Fixed an issue where the live update progress page could show "Forbidden" if the update page had been left open for a few minutes before starting an update.
• Fixed a warning that could appear on the update page when the running version could not be determined.

Scripts

Fixed

• Fixed an issue that prevented the system updater from detecting new available versions.
• Fixed an issue where the updater could attempt to apply older, already-installed versions instead of going straight to the latest available version.
• Fixed an issue where update scripts could lose their executable permission during an update, preventing further updates from running.
• Fixed a Git configuration issue that produced warnings during version switches.

Security

• Removed an unused, no-longer-valid access token from the update script.

Ansible-Deploy

Fixed

• Fixed a Git configuration issue that produced warnings during version switches.

Ansible-Update

Fixed

• Fixed a Git configuration issue that produced warnings during version switches.
• Fixed an issue where update scripts could lose their executable permission during an update, preventing further updates from running.

Ondersteund tot 11-06-2031

26.6.11 - 11-06-2026

Web

Added

• The database migration step that runs after an update now reports its result to PrivateLAN's monitoring service.

Scripts

Changed

• Renamed an internal helper function used for sending update notifications; no functional change.

Ansible-Deploy

Fixed

• Fixed an issue where the live update progress window on the system update page failed to load due to overly strict browser security settings.

Ansible-Update

Fixed

• Fixed an issue where the live update progress window on the system update page failed to load due to overly strict browser security settings.

---

Ondersteund tot 11-06-2031

26.6.10 - 11-06-2026

Web

Changed

• Diagnostic notifications are now only sent from production systems, not from development or test instances.
• Notification messages sent to PrivateLAN's monitoring service no longer include internal routing details.
• Diagnostic notifications for "page not found" events are now only sent when they result from a broken link, not from a mistyped web address.

Removed

• Removed an internal notification that was sent when a license expired.

Security

• Hardened the login process to further reduce the risk of session hijacking: a fresh session is now started at each step of signing in, including during two-factor authentication.
• Generic error responses are now returned for invalid internal requests, avoiding revealing internal details.

Scripts

Changed

• Update notification messages no longer include internal routing details.

Ansible-Deploy

Fixed

• Fixed an issue in the database setup script that could cause installation to fail.

Security

• Hardened the internal database administration interface: removed an unencrypted access option and an unused legacy access rule.
• Removed an obsolete, unused access rule from the main application's web server configuration.
• Hardened the PHP runtime configuration: disabled verbose error output to visitors, strengthened session cookie protections, and disabled an unused database file-import feature.
• Configured the web application's background processes to restart periodically for improved stability.

---

Ondersteund tot 11-06-2031

26.6.9 - 11-06-2026

Web

Added

• Dashboard now shows a copyright notice in the interface.

Changed

• Refactored index.php to improve code organization: navigation menu extracted into includes/nav.php for better maintainability.
• System update CSRF token generation moved from index.php to pages/system/update.php, aligned with the page-specific CSRF pattern used throughout the application.
• Unexpected page errors are now reported internally for faster diagnosis.
• Diagnostic notifications sent to the PrivateLAN team now include a timestamp.
• Telemetry and update notifications now route through PrivateLAN's central monitoring service instead of being posted directly to chat.

Removed

• Removed an unused internal file.

Fixed

• Fixed an issue where some monitoring, custom-device, and system-update pages did not always correctly hide the navigation menu and page header.
• Fixed a timing issue where a background task could be picked up and executed twice at the same time, which could result in duplicate diagnostic notifications.

Security

• Internal dashboard status and background-worker widgets are no longer accessible without authentication. Both endpoints now require a per-session AJAX token issued only to logged-in users (level ≥ 10).
• File downloads are now restricted to a fixed set of trusted server locations, closing a potential path traversal issue.
• Internal class loading has been restricted to the application's own components, reducing the attack surface for file-inclusion issues.
• Diagnostic information shown to PrivateLAN support staff after an unexpected error is now safely escaped to prevent script injection.
• Several database queries have been rewritten to use safer parameterized queries, reducing the risk of SQL injection.
• The application no longer generates a unique installation identifier until the default administrator password has been changed.

Scripts

Changed

• Update notifications now route through PrivateLAN's central monitoring service instead of being posted directly to chat.

Ansible-Deploy

Changed

• Notification configuration has been reorganized to support PrivateLAN's central monitoring service.

Ansible-Update

Changed

• Notification configuration has been reorganized to support PrivateLAN's central monitoring service.

---

Ondersteund tot 09-06-2031

26.6.8 - 09-06-2026

Ansible-Deploy

Fixed

• Server logging configuration no longer conflicts with the database driver package defaults, preventing log entries from being silently dropped on a fresh installation.

Security

• The database password used by the logging service is now managed through the secrets vault instead of being stored as plain text in the configuration template.

---

Ondersteund tot 08-06-2031

26.6.7 - 08-06-2026

Web

Added

• The forgot password page now includes a math captcha to prevent automated abuse.

Changed

• Expired verification codes and unused password reset links are now automatically removed from the database after 24 hours.

Fixed

• Two-factor authentication login no longer gets stuck on the login page after entering credentials. The pending verification state is now stored in a signed cookie in addition to the server session, ensuring the 2FA code entry step is always reachable.
• Editing a user account with no expiry date set no longer causes an error on the edit page.

---

Ondersteund tot 08-06-2031

26.6.6 - 08-06-2026

Web

Added

• The system page now has a configurable system name field. When set, this name is used as a suffix in the authenticator app label during two-factor authentication setup, making it easier to distinguish accounts when using multiple systems.

Changed

• The Rsyslog status indicator has been moved from the system page to the top of the syslog page.

Fixed

• The filter inputs on the switch overview page are now always shown inside the table, consistent with all other list pages. Previously, when no switches existed the filter inputs appeared floating above the empty table.
• The system name field now validates that only letters, numbers, hyphens, and underscores are accepted.
• Two-factor authentication backup codes are now stored securely and can no longer be read directly from the database.

Web

Added

• Administrators can now require all users to verify their email address before accessing the management portal. This setting is managed from the user configuration page.
• Users who change their email address must confirm the new address with a verification code before the change takes effect.
• The user edit page now includes an email address field.
• The password reset form now disables the submit button and shows a clear message when the server has no internet connection, consistent with the update page behaviour.

Security

• The user account integrity check now also covers the email address and email verification status, so a direct database modification to either field is detected and blocked on the next login.
• All user-related forms that were missing cross-site request forgery protection have been hardened.
• The user edit page has been updated to use parameterised queries throughout.

Ansible-Deploy

Added

• Fresh installations now include the database tables and columns required for email verification.

Ansible-Deploy

Fixed

• Fixed nginx startup failure on fresh deployments when the fallback HTTPS page certificate was missing.
• Fixed an issue where the admin user was not automatically added to the web server group during deployment.
• Fixed an issue where two-factor authentication setup would fail on fresh deployments due to a missing database configuration.

Changed

• The HTTPS configuration now uses the current nginx syntax for HTTP/2.

Ansible-Update

Fixed

• Fixed nginx startup failure during updates when the fallback HTTPS page certificate was missing.

Changed

• The HTTPS configuration now uses the current nginx syntax for HTTP/2.

---

Ondersteund tot 07-06-2031

26.6.5 - 07-06-2026

Ansible-Deploy

Changed

• Default user accounts created during deployment now include an email address.
• Email server settings can now be configured through the deployment, enabling password reset emails from the application.

Ansible-Update

Changed

• Email server settings are now included in the server configuration, enabling password reset emails from the management application.

Web

Added

• Two-factor authentication (TOTP) can now be enabled per user account. Works with any standard authenticator app, with a one-hour code window suitable for offline environments.
• A password reset flow is now available: users can request a reset link via email from the login page.
• Administrators can reset a user's two-factor authentication from the user management page.

Changed

• The user list now shows filter, sort, and pagination controls, and includes a two-factor authentication status column.
• Sort controls have been added to the device, audit log, and system log pages.
• Filter, sort, and pagination controls have been added to the switch and VLAN overview pages.
• The support team access toggle is now restricted to administrator accounts only.

---

Ansible-Deploy (prior)

Added

• The server now shows a helpful setup page when accessed directly by IP address over HTTPS, in addition to HTTP.
• Multiple alternative hostnames can now be configured for the management interface, useful for testing the application from different virtual machine hosts. These hostnames are automatically added to the server's local hostname resolution during deployment.

Ansible-Update

Added

• The server now shows a helpful setup page when accessed directly by IP address over HTTPS, in addition to HTTP.
• Multiple alternative hostnames can now be configured for the management interface, useful for testing the application from different virtual machine hosts.

---

Company Website

Added

• Added a contact page with a message form so visitors can reach out directly from the website.
• Companies can now be created and managed, grouping users under an organisation. Access to the application can be enabled or disabled at company level with an optional expiry date.
• Users can now be linked to a company by an administrator; a company representative with the appropriate role can manage company details and add users to their organisation.
• New users can register themselves directly from the website. Accounts are created in a pending state and must be activated by an administrator before access is granted.
• A password reset flow is now available: users can request a reset link by email, valid for one hour.
• Two-factor authentication (TOTP) can now be enabled per user. Works with any standard authenticator app without requiring an internet connection or third-party service.

Changed

• The user management and edit-user pages now display with consistent styling matching the rest of the website, including properly styled tables, form inputs, buttons, and confirmation modals.
• User accounts now include an email address field, used for password reset emails.
• The navigation menu now links to the correct pages for company management, two-factor authentication setup, and self-registration.

---