Changelog

Ondersteund tot 05-11-2031

26.11.1 - 05-11-2026

Application

Added

• DrayTek VigorSwitch switches can now be managed by the appliance: the P, G, Q and PQ series with firmware 2.x. Choose DrayTek-VigorSwitch as the type in Switches > Add. The appliance reads ports, VLANs, connected devices, PoE, temperature and 802.1X state, and, when DHCP snooping is switched on, the address of devices that get one automatically. It programs ports and VLANs as on the other switch types. A device with the MAC address profile is let onto its port by its own MAC address only, a setting these switches keep across a restart. EAP-TLS and PEAP work; MAC authentication (MAB) does not on the tested firmware, because the switch leaves out a security check that the appliance requires on every authentication request. A DrayTek switch can be the gateway of a VLAN as its only router; the protocols for a shared, redundant gateway do not exist on these switches. For the models DrayTek publishes it for, the appliance shows the total PoE budget. Device groups, the default VLAN configuration and the service port configuration get a DrayTek section, which you can edit like the others. A configuration guide for preparing the switch is on the website. Described in the documentation in English and Dutch.
• The configuration compliance report now also checks per switch whether it uses this appliance as its RADIUS server, the server that decides who may use a port, next to the existing checks for the logging host and the time server. Works for every switch type. For all three checks, a switch that names the appliance by one of the DNS names the networking page asks for now counts as correct, not only by its main name. Described in the documentation in English and Dutch.
• Deleting a switch in the web interface now offers to remove it from PrivateLAN only, without contacting the switch: for a switch that is broken, returned or already reset. It is preselected when the switch is not up. Described in the documentation in English and Dutch.
• The network interface overview in Reports now shows a drawing of the front panel of every switch. Each port is in its place with its number, in the colours of the interface overview: green when connected, with a yellow edge for PoE, a red rim without a link, grey when disabled, and blue for a service port. The first page of the report explains these colours. Until now only three models had a picture, and that picture did not show which ports were in use. A stack gets one panel per unit, in the order in which the units are cabled. For a model whose port layout has not been checked yet, the report says so under the drawing. Described in the documentation in English and Dutch.
• System > Update now shows when the appliance last asked for updates and in how many minutes it will ask again. Until now the page could show a result of up to ten minutes old without saying so. The page also no longer says that an update is ready when there is none.

Changed

• The documentation the Tux assistant reads on the appliance now also describes the screenshots that were added to the online documentation, so its answers can point to them.
• In the device list, a device connected to several switch ports now shows a connected port first. Until now the first row of such a device, the one with its name, could show a port without a link while the working port was on the row below it.
• Service ports are now shown in blue instead of orange, on Switch interfaces, in the countdown on Inspection > Ports and in the interface report. Orange is used everywhere else in the appliance for a warning, and a service port is not one.
• The Reports menu now also lists the network interface overview and the SSL inspection report, in the same order as on the Reports page. Both open in a new tab, as they do from that page.

Ondersteund tot 31-10-2031

26.10.6 - 31-10-2026

Application

Added

• The third-party notices that come with the appliance now contain a written offer for the source code of the open-source software in the appliance image, such as the operating system and the authentication server, valid for at least three years per release. The list of components and their licences per release is in the software bill of materials on the download page.
• TP-Link Omada switches can now be managed by the appliance: the Omada smart and managed switch series and the JetStream switches that share their command line, as long as the switch is managed on its own and not by an Omada controller. Choose TP-Link-Omada as the type in Switches > Add. The appliance reads ports, VLANs, connected devices, PoE and 802.1X state, and programs ports, VLANs and VLAN interfaces as on the other switch types. When a port is given a new VLAN, the appliance also takes it out of every VLAN it was in before, because these switches keep a port in its old VLANs otherwise. Device groups, the default VLAN configuration and the service port configuration get a TP-Link section, which you can edit like the others. A configuration guide for preparing the switch is on the website. Described in the documentation in English and Dutch.
• On Inspection > Ports, a port under Unexpected port usage whose device is not known yet can now be turned into a device straight away, as on the Deployment page: the Add this device button opens the new device form with the MAC addresses found on the port filled in, and the port is assigned to the device when it is saved. Until now you had to add the device by hand and then assign the port to it. Described in the documentation in English and Dutch.
• The Add and Program dialogs on the Deployment page and on Inspection > Ports now name the port and say what will happen: whether anything changes yet, and that the port is programmed with the VLAN and configuration of the device group. As with Save on a device, hold Ctrl when you click Program or Add to program the port without resetting or switching it off, or Ctrl+Shift to only save the assignment and leave the switch as it is. The new device form shows the port the device will get and the choice you made. Program now also confirms what it did, and no longer programs a port that was taken in the meantime. Described in the documentation in English and Dutch.
• Inspection > Ports now shows the VLAN each port under Unexpected port usage was in at the last poll of the switch. When you add a device from there, the new device form selects the device group and VLAN that VLAN belongs to, when it belongs to exactly one device group. You can still change the selection. When the VLAN belongs to several device groups, the form names them. Described in the documentation in English and Dutch.
• The Auth. Password of a device now has a button to show or hide the password, as on the RADIUS configuration page.
• Each result under Monitoring and control on a device now has a copy icon that puts the switch output on the clipboard, ready to paste into a ticket or a message. Described in the documentation in English and Dutch.
• Under Devices > Device group, each group now has a Copy button. It opens a new device group filled in with the settings and configuration of that group, so you only choose a name and change what differs.
• A new device group now starts from the PrivateLAN configuration templates, filled in only for the switch types used on your appliance. You can tick other switch types and fill the templates in again before saving. When you edit a device group, the page recommends the switch types to configure, based on the switches on your appliance. When a type is missing, a button adds the PrivateLAN configuration for it, and the page shows which sections no switch uses. Described in the documentation in English and Dutch.
• Users can now leave short notes for each other under a new bell in the header, for example that a switch has been removed for maintenance and will be back next week. Every user with the new notifications role sees all notes, and a number on the bell shows how many notes from others are new. A note always has an end date, ninety days ahead unless you choose another, after which it disappears by itself. Placing a note needs the notifications-add role; you can always remove your own notes, and removing someone else's needs notifications-remove-others. Administrators have all three; other users are given them under Users. The SOC button in the header now has its own symbol, so it is not confused with the bell. Described in the documentation in English and Dutch.
• Users can now be allowed to view switches and VLANs without being allowed to change them. Until now the Switches and VLAN pages, and the switch status on the dashboard, were only open to users who could also edit them. Two new permissions, Can view switches and their status on the dashboard and Can view VLANs, show the lists without the buttons to add, edit, remove, program or reload. Users who may edit switches or VLANs keep seeing them without the new permission.

- Described in the documentation in English and Dutch.

Security

• A login attempt with a wrong password no longer gives access to the page it was sent from. Until now the appliance skipped its permission check for any request that carried the login form, so an attempt from the login prompt of a protected page showed that page even when the login failed.
• Enabling, disabling and restarting a device's switch port now only works from the device page itself. A link opened elsewhere can no longer change a port.
• The appliance's background tasks can no longer be started from the browser, not even by an administrator. The telemetry diagnostics moved to their own page under System, with a button that sends the health report now.
• Updating the database from the update page now stops when any part of a database change fails. Until now a change whose first step succeeded was recorded as done even when a later step failed.
• A user can no longer delete their own account under Users. Until now an administrator could remove their own account and lock themselves out of the appliance. The remove icon is no longer shown next to your own account, and the appliance refuses such a request.
• The appliance's background tasks, such as reading the switches, programming ports, making certificates and sending webhooks, now run in a separate service on the appliance, outside the web interface. Until now the appliance started each task by opening a page of its own web interface, and anything that came from the appliance itself was trusted to start such a task. Those pages can no longer be opened through the web interface, also not by an administrator. A task also no longer stops after ten minutes, or fails after one minute without output: each task now gets up to thirty minutes.
• After a failed login, the login page no longer puts the typed password back into the form. Until now it was sent back in the page itself.
• Every appliance now has a certificate of its own for the web interface, made on the appliance itself, also without an internet connection. Until now every appliance used the same certificate, and its key came with every appliance and update. The new certificate is issued by a CA that belongs to that one appliance: download the CA under System > Security and install it as a trusted root certificate on your computers, and browsers open the web interface without a warning. The certificate is renewed automatically before it ends. Instead, you can also upload a certificate from your own CA for app.privatelan.nl there. After this update your browser shows a certificate warning until you trust the appliance's CA or upload your own certificate, and API clients that check certificates need the CA as well. The web interface always stays reachable, also with an expired or untrusted certificate, so a new certificate can always be made. Described in the documentation in English and Dutch.
• Every appliance now also gets its own CA for 802.1x. The CA that came with the installation image is replaced automatically when the default administrator password is changed, at the same moment as the web interface certificate, with new random passwords for the CA and server keys. Until now every appliance installed from the same image kept the same CA until an administrator regenerated it. If device certificates were already issued by then, the appliance leaves the CA alone and you regenerate it yourself on the RADIUS configuration page. Described in the documentation in English and Dutch.
• The passwords of devices that sign in with PEAP or MAB and the shared secrets of RADIUS clients are now stored encrypted, with a key that this appliance makes for itself. They are only decrypted to write the configuration of the authentication server. Existing values are encrypted during the update.
• The API no longer returns a device's password when it reports a device, as the API reference already described. A password can still be set and changed through the API.
• An address restriction on an API key or on the web interface could let every address through when one of its ranges had a malformed size after the slash, for example a typing error. The screens that save these settings already refused such a range, so this needed a value written some other way; such a range now never matches.
• Support reports and the assistant Tux now also hide the passwords of SNMPv3 users and the pre-shared keys of IKEv2 VPN connections in a switch's configuration.
• The protection that keeps the appliance from switching off or resetting the switch port it is connected to itself now also recognises the abbreviated Cisco commands a device profile may contain. Until now only the commands written out in full were held back, so an edited profile could still cut the appliance off from the switch.
• Telemetry now masks your data before a report leaves the appliance. An error report still names the file and line where the error occurred, but IP, MAC and e-mail addresses, database account names, entered values and passwords in it are masked, and the referring page is sent without your appliance's name or address and without the values in the address bar. Until now an error message could contain such details unchanged. Telemetry stays on Anonymous by default and can be switched off on the System page. Described in the documentation in English and Dutch.
• Hardened the assistant Tux: a link in an answer can no longer point to another website, and a locally hosted AI server can no longer redirect the appliance's request, with its access key, to a different address.
• Fixed a flaw where a switch that reports a hostname containing HTML or script could run that script in an administrator's browser, on the pages where a switch is picked from a list. The hostname is now cleaned when it is stored and shown as plain text.
• Fixed a flaw in the sign-in page that could let someone sign in as another user without that user's password or second factor. It was possible for any account that had signed in on the appliance during the previous day. Until now, a sign-in attempt that also carried an unknown "remember me" cookie could be accepted on the strength of the other account's own sign-in session. A sign-in through the form now always requires the password, and the account lockout and the second factor apply as usual. A "remember me" cookie is only accepted for the account it was issued to. We recommend installing this update promptly.
• Two-factor authentication now uses the standard 30-second codes that every authenticator app expects. Until now a code was valid for an hour, so a code could be used for longer than necessary, and after signing out you could not sign in again with a new code until the next full hour. The appliance accepts codes up to five minutes either side of its own clock, so an appliance without internet access keeps working. Existing two-factor set-ups must be set up again once after this update: sign in with one of your backup codes, or ask an administrator to reset two-factor authentication for your account, and then set it up again.
• Fixed a flaw in the camera live view that could let a user with permission to edit camera settings, or a manipulated camera on the network, make the appliance send requests to itself and start actions such as restarting a switch. The address of a camera image is now always checked, so it can only ever point at the camera's own IP address, and only images are shown in the live view. A camera image address that is not a plain path is refused when the camera settings are saved.
• A webhook's header name may now only contain the characters an HTTP header name allows, and a webhook's sign-in name no colon or control character. Until now a header name could carry a line break and so add headers of its own to the request.
• Hardened how the web interface shows text: every page now converts special characters at the moment it shows a value, including values your switches report, instead of relying on how the text was stored.
• The web interface now only runs scripts and styles that it delivered itself for that page. Until now the browser also allowed scripts and styles written directly into a page, so injected code had more room to run. Nothing changes in how the pages look or work.
• A user with the general system permission could change the network settings of the appliance by opening System > Networking directly, although changing them is meant for administrators only. The page now requires its own permission, Can edit network settings, the one the menu already checked.
• Uploading virus definitions by hand on System > Security now requires the Can update permission; being allowed to view the security page is no longer enough.

Changed

• The library that draws the switch diagram on Interconnects is updated to its current version. Nothing changes in how the diagram looks or works.
• The documentation of the assistant Tux now states more precisely what leaves the appliance: Tux looks up network data inside your appliance, and only your question and the data needed to answer it are sent to the chat service, or to your own AI server if you have set one up. Described in the documentation in English and Dutch.
• Hardened how the appliance stores the status it reads from your switches: the data is now passed to the database in a way that cannot be mistaken for a command. Nothing changes in how the pages look or work.
• The web interface now stores what you type exactly as you typed it, and only converts special characters where it shows them on a page. Until now text was stored in the form a web page uses, so an & was stored as &. Existing text is converted once during the update. Backslashes are now kept as well; until now they were removed without notice. Your password keeps working: the first time you sign in after the update, the appliance stores it in the new form. Described in the documentation in English and Dutch.
• On VLAN > Assign devices and VLAN > Assign switches, adding now takes several VLANs at once: choose the group, tick every VLAN it should get and save once. Until now each VLAN had to be added separately. VLANs the chosen group already has are greyed out. If one of the selected VLANs cannot be added, none of them is added and the page says which VLAN is the problem. Editing an existing assignment still changes one VLAN.
• The Customization section of a device now stays collapsed and shows, next to the Customize button, a label for each custom configuration that is filled in, so you can see at a glance which ones differ from the device group. The configuration fields now use the full width of the section.
• A device group no longer needs a configuration section for every supported switch type. It only needs the switch types its devices are connected to: at least one, the same in every template of the group. A port on a switch whose type the group has no section for is not programmed for devices in that group. A section name with a typing error, a section listed twice or a section without commands is now refused when you save. The same applies to device groups created or changed through the API, and to a device's own custom configuration. Described in the documentation in English and Dutch.
• The System menu now opens for every user who may use one of its pages. Until now it required the permission Can control system, so a user who was allowed to view the security page, the SBOM or the changelog could not reach them from the menu, and got Unauthorized when opening the security page or the SBOM directly. System > Security and System > SBOM now check their own permissions. Can control system is renamed to Can view system health on the dashboard (firewall, virus scanner, CPU, memory, disk and network), which is what it already did; users who held it keep it.
• The default role presets SOC, Junior Engineer and Senior Engineer now include viewing permissions. A user set up with one of them saw little of the dashboard and the System menu. SOC and Junior Engineer can now also view switches, VLANs, RADIUS, the system health on the dashboard, the system details in the header, the notifications and the contact page; SOC can also view the security page. Senior Engineer gains the notifications, including placing them, and the contact page. A preset you renamed or changed is left as it is. Users keep their current permissions; apply the preset again on the user's page to give them the new ones.

- Described in the documentation in English and Dutch.

Fixed

• An API request to a path that is not an API endpoint now gets the API's usual JSON error, code 3014 (ENDPOINT_NOT_FOUND), instead of an HTML page. Described in the documentation in English and Dutch.
• On Aruba CX switches, VLAN programming now also removes a VLAN that is no longer assigned to the switch. Until now the appliance could not read the VLAN list of these switches, so it added every VLAN again and never removed one. Check the VLANs assigned to your CX switch groups before you next program VLANs: a VLAN on the switch that is not assigned to it will be removed. The default VLAN 1 is never removed, on any switch brand.
• On Aruba CX switches the port overview now shows dropped traffic, CRC errors and collisions, and the name and description of an LLDP neighbor. Until now these were always empty, and for a Cisco neighbor its port and management address were missing as well.
• On Aruba CX switches the uptime now counts whole weeks: a switch that had been running for 10 weeks and 3 days showed 3 days. VLANs that were created together without a name, and ranges in the VLANs allowed on a trunk, are now all listed; the native VLAN of a trunk is shown as untagged only; and a port without a description no longer takes the next line of the switch output as its description.
• On ArubaOS switches (ProCurve, 2530 and similar) paging is now really switched off when the appliance connects. Until now it stayed on, and the rest of the paging prompt could end up in what the appliance read, which lost the configuration of a port, the name of a VLAN or the address of an LLDP neighbor.
• On ArubaOS switches a port without 802.1X no longer shows an unauthenticated status, the uplinks included: only ports with 802.1X configured show one. Counters of 1,000 and higher were read as their first digits (1,352 became 1); an administratively disabled port now shows as disabled; a port without link no longer shows a speed; and an LLDP neighbor that sends no name no longer shows "Not set".
• On Cisco 2960-X switches and stacks, PoE usage now shows what the PoE ports draw, per stack member, instead of the power use of the whole switch.
• On Cisco Catalyst switches with IOS-XE (such as the 9200), the MAB status of a port is now read from its authentication session. Until now it showed "No attempts made", because these switches do not have the command the appliance used.
• A device with a static address can no longer be given the network or broadcast address of its subnet, on the device pages and in the API. Until now only an address outside the subnet was refused, while the suggested free address already skipped those two.
• The SSL check no longer counts a certificate for all names under a domain as valid for a device name that starts with a dot.
• A list request in the API now refuses a page size that is not a whole number, as the API reference already describes. Until now a value such as 1.5 was read as 1.
• The certificate details on Radius Configuration and on a device's Certificates tab now show an IP address in the certificate without the "IP Address:" text in front of it, and a certificate without validity dates no longer stops the page from loading.
• The port indicator on the Deployment, Network inspection, Port inspection and Service pages could show the speed of the port in the row above it when a port reported no speed of its own. All port lists and the PDF report now draw the indicator the same way: a port without a reported speed shows A, and a port the switch shut down itself after a fault is shown in red everywhere. Until now that state appeared gray on the Service page and as a question mark in the PDF report.
• The Deployment and Port inspection pages now suggest "Probably a workstation or server" for a port with one device on a fast link without PoE. Until now that suggestion never appeared.
• Radius Configuration now shows an error when one of the certificate actions cannot be started. Until now the page showed nothing and kept the "Working" indicator on screen.
• A VLAN can now only be given a number from 1 to 4094, on every page and in the API. Until now some pages and the API also accepted 4095 and 4096. Switches reserve those numbers and refuse them, so such a VLAN could be saved but then failed when it was programmed onto a Cisco Catalyst switch. Described in the documentation in English and Dutch.
• The certificate downloads on a device's Certificates tab are now sent with the correct file type. Until now most of them carried a malformed type, so a browser or operating system could fail to recognise a certificate or key file and offer to open it with the wrong program.
• On Cisco switches, every port showed the load, error and collision counters of the first interface on the switch instead of its own. Network inspection could therefore report high load or collisions on the wrong ports. Each port now shows its own values. The appliance also reads the PoE status of a Cisco switch once per check instead of once for every port, which makes the check quicker.
• The checks for dropped traffic and CRC errors never reported anything, on every switch brand, because those counters were not stored. They are stored now, so Network inspection can report ports with dropped traffic or CRC errors. The switch counts these errors from its last counter reset, so after this update a port may be reported for errors that occurred earlier. The check for dropped incoming traffic also looked at outgoing traffic; it now checks incoming traffic.
• Text with special characters such as &, <, > or quotes now reaches switches, the authentication server, the API, webhooks, the support QR reports and the assistant Tux exactly as it was typed. Until now these characters were passed on in the form a web page uses, for example & instead of &. A switch password, a PEAP device password, a RADIUS client secret or a device profile that contained one therefore did not work, Compliance reported such a profile as different from the switch, and the API returned descriptions, locations and profiles in that form. Described in the documentation in English and Dutch.
• A PEAP device password and a RADIUS client secret now refuse the characters the authentication server cannot store (" ' # { } \), with a message. Until now these were removed without notice, so the device or switch could not sign in.
• A RADIUS client now needs a valid netmask (0 to 32). Until now any value was accepted.
• After a password reset you can sign in with a new password that contains &, <, > or quotes. Until now such a password was refused at the next sign-in.
• Saving a form again no longer changes a value with a quote or & in it: the location and rack of a stack member, the interface list on Switch interfaces, the sign-in name and header name of a webhook, the RADIUS client secret and the settings of your own AI server. Until now such a value grew longer with every save.
• A service port configuration set through the API is now stored the same way as one set on the Service page. Until now it could show differently on that page and change when it was saved there.
• The device list no longer marks a device's own MAC addresses as unknown after programming its port failed. Until now a failed connection to the switch cleared the record of which MAC addresses were allowed on the port, so the MAC indicator turned orange until the device was programmed successfully again. Programming the device once more repairs a port that still shows this.
• A device's MAC address list is now stored without stray line-break characters. Until now every address but the last could carry one, which also showed up in the API.
• When a switch does not accept a connection, the appliance now waits five seconds and tries once more before it reports that it could not connect. A switch that is briefly busy, for instance because it allows only a few management sessions at a time, no longer makes programming a port or reading the switch fail.
• On Deployment > Setup a port that is selected now shows its tick again. Until now clicking a port did select it, but no tick appeared, so it looked as if the ports could not be selected.
• On Devices, the reachability indicator of a device that gets its address from DHCP no longer shows a white question mark with "No IP address to ping" while the address is already filled in next to it. Until the next check pings the address, the indicator is now orange with "Not pinged yet". The PDF interface report shows the same indicator and explains it in its legend.
• A device with only a custom Secure MAB configuration did not show that it had one: the Customization section stayed closed without any hint.
• Opening a VLAN assignment under VLAN > Assign devices or VLAN > Assign switches that no longer exists showed an empty page. It now says that the assignment cannot be found.
• Opening a device, switch, VLAN or RADIUS client that no longer exists could show a form with empty fields. The page now opens with its normal default values.
• On Inspection > Network, the message that only muted events were found could appear while other events were shown. It now appears only when every event is muted.
• On System > AI and in the device settings under System, a save that was refused could show the form with empty fields. It now shows the stored settings again.
• On Cisco IOS switches with a long list of VLANs allowed on a trunk, the VLANs that the switch prints on a second line were not read. All of them are now included.
• An API request with a MAC address list that contains something other than text, or a webhook credential that is not text, got a server error. It now gets the usual validation error that names the field.
• In the lists of devices, switches, users, VLANs and RADIUS clients, a filter of 0 showed every row. It now shows only the rows that contain 0, as the audit log already did.
• On the page for editing a device group, the name of each configuration field is shown again next to the top of its text field instead of at the bottom.
• The login page no longer asks the appliance for the status bar every minute. Before anyone has logged in that request is always refused, so it only filled the browser console with errors.

Removed

• The system-backup role has been removed. It gave access to nothing, because the appliance has no backup function; make a backup or snapshot of the virtual machine instead. Users and role presets that held it keep all their other roles.

Ansible-Update

Security

• The RADIUS server no longer writes the password of a rejected sign-in attempt to its log, which Radius Configuration shows. Until now a mistyped or wrong device password was kept there in readable form. An update applies this to existing appliances, and log files older than 90 days are now removed automatically, so passwords logged before this update disappear within that period.

---

Ondersteund tot 22-10-2031

26.10.5 - 22-10-2026

Scripts

Security

• The web application can no longer change its own program files. Until now the web application could modify the program code it runs, so someone who had taken it over could change that code or add a file that stayed in place after every update. The program files are now read-only for the web application. An update makes this change before it installs anything, and lists in its log any file it finds among the program files that is not part of the installed version.

Ondersteund tot 22-10-2031

26.10.4 - 22-10-2026

Web

Security

• A switch can no longer be registered with a loopback address, such as 127.0.0.1, as its management IP. Entering one would have let the appliance's own switch features — including Remote SSH — connect back to the appliance itself instead of to a real switch. Found during our own review; there is no sign of misuse and no customer action is needed.
• The connections the appliance makes to PrivateLAN by itself — for the Tux assistant, for the mail with a password reset code, and to read the update information — now require an encrypted connection whose certificate really belongs to PrivateLAN, and they no longer follow a redirect to somewhere else. If either check fails, the appliance does not send the request at all rather than sending it to an unverified destination. This protects the key with which the appliance proves its identity to those services. Found during our own review; there is no sign of misuse and no customer action is needed.

Added

• New documentation page Outbound Connections: every connection the appliance makes by itself to PrivateLAN and to other systems outside your network, when it happens, what is sent and how you control it. It also lists the servers the database updates come from, for networks that only allow listed destinations. The Telemetry setting controls only telemetry; the update check, updates, password reset mail and the Tux assistant are separate. The system settings documentation now links to it. Described in the documentation in English and Dutch.

Changed

• The quick start documentation now explains that the keys an appliance makes for itself at the first password change are kept on its data disk, and that the data disk therefore belongs in your backups: without these keys, the stored credentials and user accounts in a database backup cannot be read back. It also no longer says that an appliance shares no key at all with other appliances. Described in the documentation in English and Dutch.

Fixed

• When starting an update after the update page had been open for more than five minutes, the update window showed only a bare "Forbidden". It now shows a clear message in the style of the web interface, with a button to reload the page and start the update again.
• On the update page, the release notes of the available updates are now exactly as wide as the update panel below them.
• On the device page the panels were shown one below the other instead of in two columns, a side effect of the new look of the web interface. Settings, Interfaces and Certificates sit beside Camera, LLDP Discovery, Monitoring and control and Customization again. The panels in a column now share one width, and a report requested under Monitoring and control no longer changes that width. On a screen too narrow for two columns the panels are still shown one below the other.

Scripts

Security

• The PDF reports now accept only the image type the reports actually use. The reports only ever contain the logo and switch pictures that come with the appliance, so nothing changes in what you see, but the PDF engine can no longer be made to process other image types, a common source of security problems in such software. Found during our own review; there is no sign of misuse and no customer action is needed.

Fixed

• Switching the update branch no longer gets stuck when the other branch has no newer version, for example switching back to Production while the appliance already runs the latest production release. Until now the update page kept showing "Disconnected, retrying" without end, and kept offering the switch because it was never recorded. The switch now takes effect at once and the page says there is no update to install.
• Setting Telemetry to *Disabled* now also stops the status reports the appliance sends on its own, outside the web interface: the progress and outcome of an update, automatic repair of failed services and the automatic blocking of remote login. Until now these were still sent with telemetry disabled. If the appliance cannot read the setting, for example during a database outage, it sends nothing.
• On an appliance that runs without an internet connection, the check that reports whether an update is available could stop working permanently once the appliance's own web certificate had expired — while the log claimed the web interface was unreachable, which it was not. That check no longer depends on that certificate: it talks to the appliance itself, where there is nothing to verify. Appliances with an internet connection were not affected, because they keep receiving a renewed certificate.

Ansible-Update

Security

• The database now gets its security updates directly from the database software's own maker instead of through Ubuntu, which was slower to pass security fixes on. This also updates the database on appliances that already run the earlier source, the next time an update is installed. Database updates keep arriving automatically every night, like the security updates of the operating system, and always stay within the same database version. No action is needed and no data or configuration is affected.
• An unused upload-tracking feature in the appliance's web runtime is now switched off. The web interface never used it, but while it was enabled every file upload was handled by extra code the appliance does not need. Turning it off reduces the attack surface of the web interface. Uploads keep working exactly as before and no action is needed.
• Parts of the web runtime the appliance never uses — three optional components and a second, unused way of running the web interface — are now removed, on new appliances and on existing ones. Less code loaded means less that can be attacked. The web interface does not use any of it, so nothing changes in how the appliance works.

Ondersteund tot 20-10-2031

26.10.3 - 20-10-2026

Scripts

Security

• Strengthened the appliance's internal privilege boundary. A few maintenance actions that run with administrator rights could, through crafted input, be pushed to do more than intended by someone who already had limited access to the system. These actions now accept only strictly checked input, and the component that sends status information to PrivateLAN no longer takes any settings from the web interface. Found during our own review; there is no sign of misuse, and no customer action is needed.

Changed

• The appliance now proves its identity to PrivateLAN's online services — the Tux assistant, status reports and QR Support — with its own key instead of a credential that every appliance shared. These services therefore need a licence that is linked to the appliance's update key; an appliance without one no longer uses them. Status reports set to Anonymously are sent with the key too, so that only real PrivateLAN appliances can send them. PrivateLAN does not link them to the licence; the privacy statement explains what that means. Described in the documentation in English and Dutch.
• QR Support reports are now signed by the appliance with that same key, so PrivateLAN only accepts reports that really come from a PrivateLAN appliance. The first QR code therefore carries a short identifier of the appliance's key, which lets PrivateLAN see which appliance a report came from while the report is kept. The contents remain encrypted, and PrivateLAN still cannot read them. Signing works without an internet connection. Described in the documentation in English and Dutch.
• Updates are now installed only through PrivateLAN's signed release channel. The older update method, which fetched the software straight from PrivateLAN's code repository, has been removed; every appliance on this version already updates through the channel. An appliance that does not know which version it runs now refuses an update with a clear message, instead of installing the newest version without the usual checks.

Web

Changed

• Password reset and email verification messages are now sent through PrivateLAN's online service, so the appliance no longer holds mail account details of its own. A password reset now works with a code instead of a link: the email contains a 6-character code, which you enter on the Reset Password page together with your new password. The code is valid for 15 minutes and can be tried five times. Sending these messages needs an internet connection and a licence linked to the appliance's update key; without them, an administrator can set a new password under Users. Described in the documentation in English and Dutch.
• On the Development branch, the update page now asks for a new version once a minute instead of once every ten minutes, so a new pre-release shows up sooner. The Production branch is unchanged. Described in the documentation in English and Dutch.

Removed

• The device data returned by the API no longer contains an undocumented status colour field. It was not kept up to date; use the device status instead.
• A mail component that the appliance no longer used has been removed.

Fixed

• Status reports sent with telemetry set to Anonymously could in principle be traced back to the licence by PrivateLAN, because the identifier they carried could be recalculated from the licence. The identifier is now calculated with a random key that stays on the appliance, so anonymous reports really are anonymous. Reports from the same appliance still belong together; after this update they appear under a new identifier once.
• Verifying your email address, and confirming a changed email address, could fail with an error instead of sending the verification code.

Security

• Each appliance now has its own keys for the credentials it stores: switch login details and SSH keys, two-factor authentication seeds, camera and webhook credentials, and the key for an on-premises AI service. Until now these were encrypted with keys that were the same on every appliance, so someone with a copy of one appliance could have read the stored credentials of another. An appliance creates its own keys when it is taken into use, at the first change of the default administrator password. Stored credentials are also protected against tampering now: a value copied to another place no longer decrypts. An appliance on version 26.10.2 or earlier cannot be updated to this version, online or offline: install a new VM image instead. An appliance on this version cannot be taken back to an earlier one, because earlier versions cannot read its credentials. Described in the documentation in English and Dutch.
• A webhook whose stored credential cannot be decrypted is no longer called with an empty credential or an unexpected signature. The delivery fails and is retried, and the reason shows in the delivery log. Described in the documentation in English and Dutch.
• Licences are now signed by PrivateLAN and checked by the appliance itself, so nobody else can make or change a licence. A licence is tied to the appliance's update key, which is kept on the data disk: replacing the virtual machine or its OS disk keeps the licence, so the VM replacement procedure on the licence page is gone. Licences issued before this version are no longer accepted; request a new one with the License Request ID on the licence page. An appliance without a valid licence keeps working on the default limits and keeps receiving updates. Described in the documentation in English and Dutch.

Ansible-Update

Security

• Appliances no longer carry the encrypted settings file that was the same on every appliance, nor the password that opened it. The keys that protect stored credentials and user accounts, and the appliance's identity towards PrivateLAN, are now made by each appliance itself.
• The database administration tool that was installed on every appliance has been removed. It could be reached from the management network, and its administrator login used a password that was the same on every appliance. The database now has no passwords at all. PrivateLAN support maintains it only over SSH, while SSH access is enabled on the appliance. Nothing changes in daily use; the update removes the tool by itself.
• The appliance's database no longer uses passwords for the web interface, the log collection and the maintenance tasks. The database now recognises each of them by the system account it runs under, and nothing else can log in that way. Until now these passwords were the same on every appliance. Nothing changes in use; the update makes the switch by itself.

Fixed

• Version 26.10.2 was meant to limit the database to connections from the appliance itself, but on installations that already existed the update could not apply this. It showed a warning and kept the previous setting, so the firewall was still the only thing keeping the database unreachable from the network. The change now takes effect. The database restarts briefly once, during the first update that includes this fix.
• The update page could lose the log of an update while it was running, because the update removed its own log file partway through. The log now stays in place.

Ondersteund tot 18-10-2031

26.10.2 - 18-10-2026

Web

Added

• The order of the alarms on the SOC live view can now be chosen. Until now critical alarms always came first, so a warning that nobody had acknowledged yet could end up below critical alarms that were already being handled. The new default, Needs attention first, puts every alarm that has not been acknowledged on top, then sorts by severity and then by the newest. System > SOC > History and display also offers Severity first (the previous order), Newest first, Oldest first and Latest activity first. Muted alarms keep their own section below, in the same order. Described in the documentation in English and Dutch.
• Inspection > SSL now shows the oldest TLS version each device accepts. Projects often require at least TLS 1.2 with TLS 1.0 blocked, but until now the check only saw the newest version a device offered. The new Minimum TLS column shows for example 1.2+ (TLS 1.2 and newer) or 1.2 (only TLS 1.2); hover over it to see every version that is accepted or refused. You can filter the overview on it, for example on every device below TLS 1.2, and sort on it, and the PDF report includes it. One older version is tested per check, so the picture is complete within fifteen minutes; Check this device now tests all versions at once. Described in the documentation in English and Dutch.
• A Minimum TLS version setting (TLS 1.2 or TLS 1.3) in the SSL check settings decides which versions are still allowed.
• System > License now shows whether this appliance can receive online updates. From this version on, online updates are only delivered to an appliance whose licence is linked to its own update key. The appliance creates that key when the default admin password is changed, and the licence request on this page then includes it. PrivateLAN makes the link when it issues the licence, so requesting and importing a licence still needs no internet connection on the appliance. The new Updates block shows the key and whether it is linked; right after an import it says the link is being checked. If it is not linked, send the licence request to PrivateLAN and import the licence you receive. An appliance without internet access does not need the link: it is updated with an offline update, and its licence works without a connection. Described in the documentation in English and Dutch.
• The update status in the API now also reports the newest available version, whether an intermediate version has to be installed first, whether the licence of the appliance allows it to receive updates, and when the appliance last checked for updates. Described in the documentation in English and Dutch.

Changed

• Inspection > SSL: a device that still accepts a TLS version below the minimum is now shown as an SSL problem, even when it prefers a newer version. Until now such a device could show as secured. After this update, devices that still accept TLS 1.0 or 1.1 turn orange within fifteen minutes and send one alert each, by syslog and webhook if you use those.
• System > AI now says so when Chat (AI) is not included in your license. Tux is then only available to PrivateLAN Support, and you can still switch it off there for every user. The AI backend settings are only shown when the option is licensed.
• System > Update now tells you when a newer version can only be installed through an intermediate version. The update then installs the intermediate version first, and a following update brings you to the newest one. The release notes now cover every version the update contains.
• The copyright and license notices included with the software now match the PrivateLAN license terms published on privatelan.nl.
• The number of VLANs, users and RADIUS clients is no longer limited by your license. Dividing your network into VLANs is the basis of a secure network, so you can now create as many as you need, and give everyone who manages the network their own account. Your license still determines the number of switches and devices. Creating a VLAN through the API can no longer fail on a license limit. Described in the documentation in English and Dutch.

Fixed

• After a restart the appliance no longer looks up a few PrivateLAN-internal server names that do not exist on your network. Until now your DNS server could log these failed lookups after every restart. The lookups stop once the default admin password has been changed.
• The top bar of the SOC live view and history page now has the same height, logo and clock as the rest of the appliance. The clock still shows seconds, but the hours and minutes no longer shift slightly as the seconds change. In the top bar of every page the time now lines up with the date below it.
• When your license does not include Syslog or Auditlog, these menu entries are now shown with a lock, like Inspection, Reports and SOC already were. Until now administrators saw them as available and got a bare error message when opening them; the page now explains that the option is not in your license.
• A locked menu entry for an option that is not in your license now says Not licensed when you click it, instead of telling you that you have no authorization. Described in the documentation in English and Dutch.
• Saving a device no longer clears its camera setting when your license does not, or no longer, include Camera Live View. Until now the camera view of that device was gone after renewing the license, until the setting was switched on again.

Security

• Stronger protection of the second login step. Wrong verification codes are now also counted per account, not only per network address, so guessing codes from many addresses no longer works. After ten wrong codes the account refuses codes for fifteen minutes. After five wrong codes the login attempt itself is cancelled and the password has to be entered again.
• A verification code can only be used once. A code that was seen by someone else can no longer be reused within its validity period.
• The temporary login state between the password and the verification code no longer contains any account information and can be revoked by the appliance.

Scripts

Changed

• Updates now come from PrivateLAN's signed release service. Before anything is installed, the appliance checks PrivateLAN's signature on the release and that every downloaded file is exactly what was signed. An update that fails this check is not installed. An appliance switches over automatically with an update once it can use the release service: when its licence is linked to its update key (see System > License). Until then it keeps updating the way it did before. What the appliance sends to PrivateLAN when it checks for updates, and how long PrivateLAN keeps it, is described in the documentation in English and Dutch and in the privacy statement on privatelan.nl.

Fixed

• When an update through the release service fails, the appliance now returns all of its software to the previous version. Until now only part of it was restored, so a failed update could leave a mix of the old and the new version.

Security

• Once an appliance has switched over to the release service, it no longer keeps a copy of PrivateLAN's software repositories or their history on disk: it only holds the files of the version it runs, and of the previous one for a rollback.
• A downloaded update is inspected without administrator rights until it has been verified, so a tampered download cannot use a flaw in that inspection to take over the appliance.
• Fixed a weakness through which someone who had already taken over the web application could gain full control of the appliance during the next update. Updates no longer act on links the web application places among its own files.

Ansible-Update

Changed

• The appliance's web certificate has been renewed and is now valid until 3 May 2027. The previous certificate expires on 17 November 2026. An appliance that has not installed this update by then shows a certificate warning in the browser, and integrations that check the certificate refuse to connect.

Security

• The database now only accepts connections from the appliance itself, so it no longer depends on the firewall alone to stay unreachable from the network. The database restarts briefly once, during the first update that includes this change.
• Remote access over SSH is now closed again at the end of every update, instead of during the nightly check. Until now SSH that had been opened under System > Security and not closed again stayed reachable after an update until the next night. Sessions that are already open stay connected. If you opened SSH yourself for maintenance, open it again under System > Security after a manual update.
• Closed SSH access now stays closed after a restart of the appliance. Until now every restart opened SSH again until the nightly check closed it. The appliance now remembers the last setting from System > Security: if you opened SSH yourself, it also stays open after a restart, until the nightly check or the next update closes it. A restart therefore no longer opens SSH; use System > Security for that. Described in the documentation in English and Dutch.

Ondersteund tot 17-10-2031

26.10.1 - 17-10-2026

Web

Added

• Role presets and a clearer overview of user permissions.

- Before: the permissions on a user's page ran down one long, narrow column that grew with every new function, and giving a new colleague the right set meant ticking dozens of boxes from memory.

- The permissions are now grouped side by side, in up to four columns. All and None tick or clear a whole group, and each group shows how many of its permissions are ticked.

- The new page Users > Roles holds role presets: named sets of permissions. SOC, Junior Engineer and Senior Engineer come with the appliance and can be changed or deleted. On a user's page, choose a preset and press Apply; nothing changes until the user is saved. The page also shows which preset a user's permissions match.

- A preset is a template, so changing it does not change anyone's access by itself. When you change a preset, you can choose to also update the users who hold exactly its permissions.

- New functions still give nobody below administrator level access until it is granted. Users > Roles now lists the permissions added by an update since they were last reviewed, so they can be added to the right presets.

- The user list has a new Roles column showing which preset each user matches.

- A new user permission, Can manage role presets and review roles added by an update, decides who may manage presets.

- Described in the documentation in English and Dutch.

• The Tux assistant can now read the SOC alarms. Ask it which alarms are open, whether anything is critical or how long an alarm has been standing, and it answers from the same list as the SOC live view. It only does so for users who have been given the new data permission May share SOC alarms with the assistant, and only when the SOC license option is present.
• The documentation now also covers the light and dark appearance, reseller branding and the new status bar at the top of every page, including the permission that decides who sees the processor load, background tasks and active users. In English and Dutch.
• A device can now be saved without its switch port going down, or without programming the switch at all.

- Before: every save of a device, or of its customization, reset the port and switched it off before reconfiguring it. Even changing a description briefly disconnected the device, and a change could not be prepared now and applied later.

- Ctrl (Cmd on a Mac): hold it and the Save button turns orange and reads Save (no shutdown). The switch is then programmed without resetting or switching off the port, so the device stays connected.

- Ctrl+Shift: the button turns green and reads Save (DB only). Only the change is saved and the switch is left as it is.

- RADIUS is updated in both cases.

- The confirmation and the audit log say which mode was used.

- Side effect: settings from the old configuration can remain on the port. A port saved either way shows up as differing in Inspection > Compliance, where it can be programmed in full, as can a normal save.

- Described in the documentation in English and Dutch.

• Dark mode. The web interface now has a light and a dark appearance. By default it follows the setting of your operating system; the Light, Dark and Auto buttons at the bottom of the menu override that for the browser you are using. The Tux assistant follows the same choice.
• Reseller branding. An appliance supplied through a reseller can now show that reseller's logo and colours. The appearance is part of the license, so nothing has to be configured on the appliance; a license without a reseller brand keeps the PrivateLAN appearance, also after the license expires.

• New user permission: "Can view system details in the header". It shows the background tasks, processor load and number of active users in the new status bar at the top of every page. Administrators have it automatically. Other users no longer see this information until it is granted to them in their user settings; they keep seeing the clock, the software version and the license, reboot and update notices.
• New: Inspection > SSL shows for every device whether its web interface is properly secured with the certificate PrivateLAN issued it.

- Why: most devices have a web interface or another management page, and the certificate a device gets for network authentication can secure that page as well. Until now there was no way to see whether devices actually use it, or still offer their login page without encryption.

- Every five minutes the appliance checks that each device keeps its unsecure port closed and offers its own certificate on its secure port, with the right address and hostname in it. Only devices that answered the last ping are checked.

- Each port is shown as a coloured label: green when it is in order, orange when encryption works but something is not right (another certificate, the wrong name or address, an expired certificate, outdated encryption, or an unsecure port that only redirects to the secure one), red when the device is not secured, grey when it has not been checked. Hover over a label for the reason.

- The overview has the same navigation, filters and sorting as the device list, and can show the errors first. It shows until when each device's certificate is valid; that date can be searched and sorted on, and hovering over it shows when the certificate was issued.

- Devices that still present their factory certificate with an unlimited end date, as many cameras do, are checked and shown like any other device.

- Which ports are checked is set once for everything, can differ per device group — or be switched off, for example for workstations — and per device.

- Devices can be checked by IP address (the default) or by DNS name. DNS checks can only be chosen when a DNS server is set for the LAN interface and answers; the page says so when it does not. The current settings are shown in one line at the top of the page and changed in a dialog, so they do not take up space on the page. A new user permission controls who may change them.

- A device can be muted: it is hidden from the overview and sends no alerts, but is still checked.

- Findings are logged to syslog once instead of every five minutes, and repeated once each morning at 09:00 while they are still there, so there are no repeated alerts at night. New webhook events report an unsecure port that is open, a certificate problem and a device that has recovered.

- A PDF report of the findings can be made from the page, with the current filters and sort order, or from the Reports page, with a choice of sort order.

- Part of the Reports & Inspection license option.

- Described in the documentation in English and Dutch.

• The Tux assistant now knows what the Inspection pages show. Until now it could explain Inspection > SSL but not read its results, and of the inspection findings it only saw the events of Inspection > Network. It can now tell which devices fail the SSL inspection and why, which device certificates have expired or end within thirty days, which switch ports are in use without an assigned device and which uplink or other marked ports are not connected. It uses the existing data permission for inspection, so no permissions need to be changed. Described in the documentation in English and Dutch.
• Trend lines on the dashboard. Until now the CPU, memory, LAN and WAN tiles only showed the value of this moment, so a peak during the night or a slow increase over several days went unnoticed. These tiles now show a small line in the background with how the value developed.

- A switch at the top of the dashboard chooses the period: the last 3 hours, 24 hours or 7 days. The choice is remembered per browser.

- Short peaks stay visible, also over 7 days. A period in which the appliance was switched off shows as a gap in the line.

- Hovering over a tile shows the highest value in the chosen period.

- The appliance keeps these measurements for seven days.

- Described in the documentation in English and Dutch.

• New Disk I/O tile on the dashboard. The disk tiles show how full each disk is; this tile shows how busy the disks are: how much is read and written per second, how long a disk operation takes, and a trend line.

- The tile shows a warning when processes had to wait for the disks during more than a quarter of the last minute, and an error above half of it.

- Described in the documentation in English and Dutch.

• Firewall figures on the dashboard, for the LAN and the WAN side. A new tile per network interface shows how many new connections the firewall accepted in the last minute and how much traffic it blocked, with a trend line like the other tiles.

- Blocked traffic includes connection attempts to the honeypot ports on the LAN and traffic on the WAN pretending to come from a local address.

- The firewall never answers blocked traffic, it drops it silently, so there is no separate figure for rejected connections. A device usually retries a blocked connection a few times, so one attempt can count more than once.

- The firewall rules themselves are unchanged; only counting was added.

- Described in the documentation in English and Dutch.

• A clean start when you take the appliance into use. When the default administrator password is changed, the appliance clears the audit log, the syslog and the dashboard trend lines. Until now these still held everything recorded while the appliance was being prepared and tested before delivery. The audit log then opens with a single Logs cleared entry, so an empty history is explained. Appliances already in use are not affected. Described in the documentation in English and Dutch.
• New: SOC live view, a screen for the control room that stays open all day. It shows every active alarm with how long it has been standing - a camera that went offline, an uplink without a link, a device refused by 802.1x - together with a live feed of what happens on the network, and sounds when a new alarm comes in. Available with the new SOC license option.

- Alarms: switch offline, switch login failing, uplink down, port shut down by the switch, device offline, access rejected, honeypot triggered, login blocked and IP address conflict. Each alarm says where the problem is: switch and port, location, patch point, device group.

- Device offline per device group: a device group now has an Offline alarm setting (No alarm, Warning or Critical), so cameras can raise a critical alarm while workstations that are switched off at night raise none.

- One cause, one alarm: while a switch is down, the ports and devices behind it do not raise alarms of their own.

- Login blocked: an address that is refused after too many failed login attempts - on the login page, at the two-factor code or with an API key - raises an alarm that names the address and the accounts the attempts were against. It stays until an operator closes it, since a block running out says nothing about whether the guessing stopped.

- Acknowledge, mute, comment and close work as in Zabbix: acknowledging says someone is on it and stops the sound, but the alarm stays until its cause is gone and then resolves by itself. Every action is kept with who did it, when and the comment, and is also in the audit log.

- Opening it: a SOC button at the top of every page, next to the clock. History, at the top of the live view, lists all alarms with filters; System > SOC sets the severity per alarm type, the sounds, how long resolved alarms stay visible and how long history is kept (30 days by default, open alarms are always kept). A short beep each time the sound is switched on confirms that it works.

- Fast port alarms: a switch that sends its log to the appliance is read again as soon as it reports something about a port, so an uplink or port alarm appears within about two minutes. The log line alone never raises an alarm; the fresh reading of the switch decides.

- New permissions "SOC view", "SOC acknowledge" and "SOC settings". A user with only the SOC view lands on it straight after logging in, without the menu - the account for a control-room screen.

- Lights, sirens and relays: webhooks can follow the live view. A stack light, siren or relay in the control room switches on when a new critical alarm or warning comes in, and off again as soon as every alarm has been acknowledged, muted or resolved - or a siren simply sounds once for every new alarm. Alarms that come in together send one message, and a late retry never switches a light back on that has already gone off.

- Described in the documentation in English and Dutch.

Changed

• The PDF reports now carry the appliance's own brand. The Network interface overview and SSL inspection reports always showed the PrivateLAN logo and colours, also on an appliance supplied under another brand. They now show the logo and colours of the brand the appliance runs under, the same as the web interface.

- A new layout for both reports: the logo at the top of every page, the report name, project and page number ("Page 3 of 12") at the bottom, and column headings repeated when a table continues on the next page. Status colours match the web interface.

- The network interface overview names the switch at the top of every page it covers, and starts with the switch name and its location.

- A downloaded report is now named after the report and the date, instead of "document.pdf".

- The reports are made by a different open-source PDF engine, WeasyPrint, which this update installs. It replaces the previous engine, dompdf, which is removed.

- Described in the documentation in English and Dutch.

• A refreshed, calmer look for the whole web interface. Nothing has moved: every page, menu item and button is where it was.

- The menu now highlights the page you are on.

- Tables are more compact, and in forms each label lines up with its field.

- Colour is reserved for status, so warnings and errors stand out. Log entries are marked with a soft tint instead of a full colour bar.

- Dialogs have a fixed, readable width with their buttons side by side, instead of stretching across the whole screen.

- The dashboard charts show the total in the middle.

- All tiles on the dashboard now have the same size and line up in columns from section to section, whatever text they show. Until now a tile with a longer text was slightly wider or taller than the tiles next to it. The charts line up with the tiles as well.

- Messages after you save something or perform an action appear in a clear box with an icon and a coloured edge, instead of a large picture with coloured text. When there are several errors, they are listed one below the other. The messages follow the light and dark appearance, and a screen reader announces an error straight away.

- In the device list, the authentication shield matches the colours of the status indicators next to it and shows a check or a cross, so the two states can be told apart without relying on colour.

- The certificate list of a device shows the same kind of check and cross for Key included and Needs password; a "no" is now grey instead of red, since it is not an error. The green add buttons on the list pages follow the same style.

- In the switch list, the Remote SSH and QR Support icons take the colour of the text, so they stay visible in dark mode, where they used to disappear. The action icons now fit on one line. The download and copy icons under Switches > Versioning do the same, and the Copy to clipboard button keeps its icon after copying.

- Inspection > Network now uses the same words as Inspection > SSL: hiding an event is called Mute instead of Snooze, and showing it again is Unmute instead of Monitor. On both pages these buttons are now simple round icons in the same style as the add buttons, so they are easy to recognise at their small size.

- All other icons now follow the same style as well: edit, delete, reload, lock and the other actions in the lists, the icons next to password fields, and the pictures in the update and confirmation dialogs. They take the colour of the text or of the brand, stay visible in dark mode and are sharp on high-resolution screens. Icons that act as a button, such as generating a password or loading the default configuration, can now also be reached with the keyboard. The Activate and Disable icons of service ports are now a play and a stop symbol.

- System > Update and System > Security use the same icons for their status lines instead of emoji: the automatic update status, the firewall status and the antivirus status show a check, a warning triangle or a cross in the status colour. The reboot and firmware notices on System > Update appear in the same box as other messages, and the waiting animation in dialogs now follows the brand colour and dark mode. In the user list, the 2FA column shows the same check and cross as the certificate list.

- System > Update shows each available update in the same layout as System > Changelog: newest first, with its release date and end of support. Bold text and code in the release notes are now formatted, where they used to show their markup characters. The live log during an update uses the same dark terminal style as the Remote SSH output.

- The PDF interface report is unchanged.

• PrivateLAN now states its manufacturer's registered name and Chamber of Commerce number. The company behind the product has not changed and nothing about your installation changes: the same person still owns, develops and supports the product. What changes is that the copyright notices in the appliance software and on the website now name the registered business (KMT Techniek, trading as PrivateLAN) together with its Chamber of Commerce number. Your licence, your support period and the published end-of-support date of every release are unaffected.

• The status information at the top of every page is now a compact status bar, and the header takes up less space.

- Before: two blocks of text listed the latest background tasks and the system status on every page, including the license dates, even when nothing needed attention.

- The clock and the date are always visible and show the appliance's own time.

- Everything else is a small icon: background tasks, processor load (one bar per processor core), the number of active users, the software version and the license. Click an icon for the details.

- The software version has moved from the bottom of the menu to the status bar. Click it for What's new, the list of changes per release.

- What needs your attention stays in words: Reboot required and Update available take you straight to System > Update, and the license icon shows how many days are left once fewer than thirty remain.

- Routine tasks the appliance runs on its own schedule only appear when they fail.

- After ten minutes without activity the status stops refreshing. It now resumes as soon as you move the mouse or press a key; until now the page had to be reloaded.

• The changelog page now shows only the releases of the series you are running, and is easier to read. Until now it listed every release of the year. On version 26.9.5, for example, it now lists every 26.9 release and nothing older; the release notes of older series remain available on the PrivateLAN website.

- Each release has its own panel with its release date and end-of-support date, and the installed release is marked Installed.

- Changes are grouped by type, each with its own colour next to its name, and lists and emphasis are shown as formatted text instead of raw markup.

- The page follows the light and dark appearance.

- Described in the documentation in English and Dutch.

• Device certificates now contain the device's hostname as well as its IP address, so a browser accepts the certificate when you open the device's web interface by name. Until now a certificate for a device with an IP address only worked when the device was opened by its address. Network authentication is not affected. Certificates issued before this release keep working as they did; issue them again to include the hostname. Described in the documentation in English and Dutch.
• Inspection and Reports are now a license option. All Inspection pages, the inspection tile on the dashboard, the inspection alerts and all reports need the Reports & Inspection option. A Full license includes it. If your license does not include it yet, contact PrivateLAN support for an updated license before installing this release, or these pages will show a license restriction instead of their content. Described in the documentation in English and Dutch.
• With Full control switched on, the Tux assistant is marked by a red ring around its picture instead of a red window header. The red header took over the whole window; the header now keeps the normal colour, and the red ring on the button and in the window, together with the warning strip above the conversation, still makes it unmistakable that this assistant can change your system. Tux also greets you as "your AI assistant" and the message field reads "Ask me something...", so an appliance supplied through a reseller no longer shows the PrivateLAN name there. Described in the documentation in English and Dutch.
• A clearer layout for the Inspection and Reports menus. Inspection now holds the checks that look for problems; Reports holds the overviews you view, print or download.

- Inspection opens an overview showing how many findings each check has right now, with a link to each one: Ports, Network, SSL and Compliance. Until now it opened the port checks directly, so the other checks looked like part of them. The dashboard's inspection tile opens this overview.

- The port checks (unexpected port usage, disconnected ports and open service ports) have their own page, Inspection > Ports.

- The configuration compliance check moved from Reports to Inspection > Compliance, because it looks for differences and lets you fix them. It now needs permission to use the inspection pages. Asking a switch to be read again there now needs permission to make changes on the inspection pages. Old links and bookmarks to the compliance page still work.

- Reports now holds Switch interconnects and the PDF reports. Each one has its own description on the Reports page; the description of the network interface overview used to be shown under Switch interconnects.

- Described in the documentation in English and Dutch.

• The user edit page has a Save button above the permissions as well as below them, so you no longer have to scroll past the full list of permissions to save a change.

Security

• Every change to a user's level or permissions is now recorded in the audit log: who made it, which permissions were added or removed, and which preset the result matches. Until now it could not be traced afterwards who had given a user a permission.
• The login page no longer shows which software version the appliance runs, and no longer shows the system status after you log out. Anyone who could open the login page could read the version number, which tells an attacker which known vulnerabilities to try. After logging in, the version is in the status bar at the top of the page.
• Enabling two-factor authentication now fails safely, with a clear error message, if the server's encryption configuration is missing, instead of silently continuing with weaker protection. This closes an edge case in the two-factor authentication encryption added in the previous release; it has not been observed on a running system.
• Disabling a switch port from Inspection > Ports now requires permission to make changes on the inspection pages. Until now, a user who was only allowed to view the inspection pages could also shut down a switch port from there. Users who may only view the page no longer see the button.
• The two-factor code step now also respects the temporary block after too many failed login attempts. Until now, someone who already knew a password could go on trying codes from an address that was blocked, for as long as the code page stayed valid.
• Logged-in sessions are checked in a way that can no longer be used to slow the appliance down. Until now, checking a login cookie took more work the more users were logged in, and anyone able to reach the web interface could send a fake cookie to make the appliance do that work. You stay logged in through the update.
• A failed login with an unknown user name no longer records what was typed as the user name in the audit log. That field often holds a password typed into the wrong box. Failed logins on existing accounts are still recorded with the account name, as before.
• Webhook deliveries can no longer be steered to the appliance itself, and a webhook address must now start with http:// or https://. The check that refuses the appliance's own address could be bypassed with a specially prepared host name, which a user allowed to manage webhooks could use to reach internal functions. A delivery now always goes to the address that was checked, and an address pointing at the appliance itself (such as 127.0.0.1 or localhost) is now refused as soon as you save the webhook, instead of only failing at delivery. A delivery to such an address is no longer retried.
• The audit log no longer stores the hidden security codes that every form sends along. They were only usable together with the session they belonged to, but have no place in a log.

Fixed

• Radius > Configuration was shown as not permitted for users who do have the permission to change the RADIUS configuration. Administrators were not affected. The menu item now opens the page.
• Saving a user could remove permissions without notice. When a user who is not an administrator edited another user, every permission they could not grant themselves was taken away from that user on saving, even when only the name was changed. Those permissions are now kept.
• Tux no longer guesses which switch or device you mean when you give a number. "Switch 5" was read as the fifth item in a list instead of the switch with ID 5, so the answer could be about the wrong switch. Tux now sees the ID of every switch and device and treats a number as that ID.
• Every webhook is now signed with its own secret. The secret shown once when a webhook is created could not be used to check the signature of its calls, because they were signed with a single key for the whole appliance. They are now signed with the webhook's own secret. Webhooks that already exist keep their old signature until you generate a new secret for them, which can be done on the webhook's edit page or through the API; the new secret is shown once and the old one stops working at once. Described in the documentation in English and Dutch.
• The VLAN column of the network interface overview report shows the VLAN of every connected device. It was empty for almost every device, and only showed the VLAN number and name now and then.
• Two-factor authentication can now actually be set up by any user, not just administrators. A configuration error meant a regular user could not reach their own two-factor authentication setup page. This also meant the "Force 2FA for all users" option locked an affected user out of the entire system instead of guiding them to set it up; that option should not be enabled until this fix is applied.
• A user granted the "logout all users" permission introduced in the previous release can now actually use it without also needing full administrator rights. The permission previously had no effect unless the user was already a full administrator, so assigning it on its own did nothing.
• API keys now keep working when "Force 2FA for all users" is enabled. Every API request was being redirected to the two-factor-authentication setup page instead of receiving its normal response, because that setting did not distinguish between a person logging in and an API key authenticating on its own. API keys never go through two-factor authentication, so they are no longer affected by this setting.
• When editing a device, switching its address to "Static" now lets you type the IP address straight away, instead of requiring you to save the page first before the field became editable.
• The countdown shown while the appliance restarts now better matches how long a restart actually takes, so it no longer sits at zero for a while before the appliance is confirmed back online.
• The labels on the compliance page all have the same height and fit on one line. The legend also has more space between its labels.
• The spacing between sections is now the same on every page. The Switch Configuration, Syslog, Radius, Security, License, Switch interfaces and Deployment pages had extra blank space between sections, and Switch Configuration also between the page buttons, the sort options and the filter.
• Users who are not administrators can open Inspection > Network from the menu again, instead of getting an "Unauthorized" message although they had permission to use the inspection pages.
• The Cancel button in the high ping time dialog on Inspection > Network now closes the dialog. Clicking outside the Acknowledge, Mute and Unmute dialogs on that page now closes them too, as it already did for the high ping time dialog.
• Clicking outside a confirmation dialog now closes it on every page. On pages with more than one dialog, only the last one closed this way, for example on the switch, VLAN, device, certificate and deployment pages. The "Please wait" screen shown during an upload on System > Security no longer disappears when you click beside it.
• The time printed on the network interface overview report is correct again. It showed the month where the minutes belong.
• The online / offline status of devices is up to date again on larger installations. The appliance checked devices one at a time and waited up to two seconds for every device that did not answer. With a few hundred devices, many of them switched off, a round took longer than the appliance allows and was cut short: the devices at the end of the list kept an outdated status, their online and offline webhook notifications were not sent, and the background task was reported as failed. Inspection > SSL, which skips devices that are offline, relied on the same outdated status. Devices are now checked in parallel, and a round of five hundred devices finishes in well under a minute.
• Inspection now reports a disconnected uplink, SFP or non-device port. Because of an error in how the port status was compared, these ports were never listed under Disconnected ports, never counted on the dashboard and never sent their webhook. A port the switch has shut down itself after a fault or security violation now also counts as disconnected. After the update, ports that are already down appear straight away; the first check sends a limited number of webhooks for them and summarises the rest.
• The port status bars on Inspection, Deployment and the device page show disconnected ports in red again, instead of a question mark.
• A single lost ping no longer marks a device or switch as offline. A device or switch that was reachable is now pinged a second time before it is reported offline, so one dropped packet no longer causes an offline message followed by an online message five minutes later. Described in the documentation in English and Dutch.
• An IP address conflict is reported once instead of every few minutes. As long as a conflict lasted, the webhook was sent again after every switch check. It is now sent when the conflict is found, and again only if it comes back after having been resolved. Described in the documentation in English and Dutch.
• An offline switch no longer shows up as failed background tasks. The appliance waited a full minute for an unreachable switch before it gave up on reading its status. That was exactly as long as a background task may run, so every five minutes the task was reported as failed, which looked like a fault in the appliance. The appliance now gives up after ten seconds and the task finishes normally. Whether a switch is offline is still shown on the dashboard, the switch page and the SOC. Actions on an unreachable switch, such as configuring a port, also report the problem after ten seconds instead of a minute.
• Changing the automatic update setting on System > Update now confirms the change, or says why it failed. Until now the page showed nothing after Apply, so the only way to tell was to look at the status line.
• Corrections in the built-in documentation: menu paths that changed with the new Inspection menu, which permission is needed for the SSL inspection settings, that a disabled (err-disabled) port counts as disconnected, how to replace a webhook secret from the web interface, and that certificates for devices with a dynamic address carry no IP address.

Ansible-Update

Security

• A configuration gap meant a small number of internal, non-customer-facing files could be downloaded from the appliance over the local network, instead of being kept private. This was found and fixed during routine internal security testing, before any customer installation existed; no customer system was ever affected. The appliance's own certificate revocation list and public API documentation remain available as intended — those are meant to be reachable.
• Only the appliance itself can now raise a honeypot alert. Until now, a single forged log message sent from any device on the local network could raise a honeypot alert naming any address, including its webhook and, in this release, a critical SOC alarm. Where that webhook was used to block the source automatically, a forged message could have blocked a legitimate device.
• Two web server protections from an earlier release are back on updated appliances. The database administration tool is again reachable over an encrypted connection only, and the web server log no longer records the parameters of a requested address, such as the code in a password-reset link. Until now, every update put the older settings back on existing installations. Log lines written before this update are removed by the normal log rotation.
• The appliance's web interface now holds only the administrator rights it actually uses. Several broad rights it never needed have been removed, so a weakness in the web interface can no longer be turned into full control of the system through them. Nothing you use changes.

Fixed

• Device status is now checked at an even five-minute interval. In parts of the hour the interval was three or seven minutes instead.
• The database now recovers automatically when it cannot start because a temporary folder it needs was removed by the system's routine cleanup. On an affected appliance the web interface could stay unavailable until the database was restarted by hand.
• When a change to the RADIUS clients is rejected by the configuration check, the previous configuration is now really restored. The backup it was supposed to restore from was never made, so the rejected configuration stayed in place and RADIUS authentication failed at the next restart.
• The appliance now sends its complete certificate chain. Tools that check certificates strictly, such as curl, Python and most API integrations, could not verify the appliance's certificate and refused the connection, while browsers worked. This also made the hourly check for new updates fail.

Scripts

Fixed

• The SBOM (Software Bill of Materials) is valid again for appliances with a package whose license is registered as "public domain." A handful of such packages caused the generated file to fail standard format validation, which could affect tools reading it, including the SBOM download feature. The affected entries are now recorded correctly.
• The software bill of materials (SBOM) now also lists the e-mail component built into the web interface, so it is included in the vulnerability check of every release. It was missing because it was not installed through a package manager.
• The automatic self-repair no longer repeats a full repair and its alert every two minutes while the same fault persists. It now escalates once per fault, and again only after the system has been healthy in between.

---

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.

---