System Settings

The system settings pages let you configure the identity, network connectivity and basic security of your PrivateLAN appliance.

System overview

• System name — a friendly name for the appliance, used to identify it in two-factor authentication apps
• Telemetry — controls whether PrivateLAN sends usage data to help improve the product:
• Enabled — sends events together with a unique instance identifier
• Anonymous — sends events without any identifying information
• Disabled — never sends telemetry

Network settings

Changes to network settings are applied immediately — make sure the new settings are correct before saving, especially if you are connected through the interface being changed.

When Eth1 runs on DHCP, two extra buttons are shown:

• Refresh — re-reads the address the interface currently holds and shows it on screen. It does not contact the DHCP server.
• Renew DHCP — releases the current lease and requests a new one. Use this when the WAN side has changed (for example a different VLAN or subnet on the uplink), because the appliance otherwise keeps using its previous address until the lease expires. The renew takes a few seconds; outbound traffic is briefly unavailable while the new lease is requested.

Security settings

The security page shows the status of the appliance's internal firewall. Administrators with the appropriate permissions can enable or disable SSH access through the firewall.

Web interface access restriction (IP/subnet)

Administrators with the Manage web interface IP restriction role see an extra panel on the security page that lets them restrict access to the web interface itself to specific networks. Enter one IP address or subnet (CIDR notation) per line, e.g. 172.16.100.0/24. Visitors from any other network then see a clear error message instead of the login page.

• Leave the field empty to disable the restriction — this is the default, meaning the web interface is reachable from any network.
• This restriction works at the application level (a "soft block" inside PrivateLAN itself), not as a firewall rule — the appliance's own internal background tasks keep working regardless of this setting.
• Make sure the IP address you are connecting from is included in the list before saving, or you may lose access to the web interface yourself.
• This role is separate from the general role required to view the security page, so this sensitive setting can be assigned to specific administrators only (see User Management).

API rate limits

Administrators with the Manage API rate limits role see a panel on the security page that sets how many API requests a single API key may make per minute. This protects the appliance and the switches behind it from a runaway integration; it is separate from the lockout that already applies to failed sign-in attempts, which keeps working regardless of this setting.

• General limit (100 by default) applies to every API endpoint.
• Switch-touching endpoints (10 by default) is a second, much smaller budget for the requests that open an SSH session to a switch or queue a job that does: device and switch actions, live device and switch status, service port activation, issuing or revoking a certificate, and starting a system update. Those requests count against both budgets, since a switch can only hold a few sessions at once.
• Requests that only read information the appliance has already collected — listing 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.
• Set a limit to 0 to switch it off. The switch-touching limit cannot be set higher than the general limit, because those requests always spend from both.
• A key that goes over a limit is refused with a clear answer stating how many seconds to wait. See the REST API documentation for the exact response and headers.
• This role is separate from the general role required to view the security page, so this setting can be assigned to specific administrators only (see User Management).

Devices settings

For administrators with the Edit camera role, the System page also has a Devices panel with a Camera Autostart option. This controls whether a device's live camera feed (see Camera Live View) starts automatically when you open that device's edit page, or only once you press Start stream yourself. It is enabled by default.

AI settings

Administrators with the Manage AI assistant settings role see a System / AI page that controls the Tux assistant for the whole system. This role is separate from the general roles used elsewhere on the System page, so it can be assigned to specific administrators only (see User Management).

• Mode — Disable turns the assistant off entirely, for every user, regardless of any individual permission. Read only (the default) lets the assistant look up information but never change anything. Full control additionally allows the assistant to make changes — but only for a given user if that user is also separately granted the matching permission, and only after you approve each change in the conversation. This mode acts as a ceiling: it can only take permissions away, never grant them on its own. See Tux, the AI assistant for what Full control does and does not allow.
• Backend — choose between the PrivateLAN-hosted assistant (the default) or a customer on-prem AI server that you run yourself. When on-prem is selected, you provide a server URL and API key for your own OpenAI-compatible AI server (such as a locally hosted model), and may optionally add extra instructions in a system prompt field, which are appended to the assistant's standard instructions. The API key is stored encrypted and is never displayed again once saved.
• Response timeout (on-prem only) — how long the appliance waits for your AI server to answer, between 10 and 600 seconds, 120 by default. A model running on your own hardware can need considerably longer than a cloud service, particularly on the first question after it has been loaded into memory. Note that Full control requires a model that supports tool calling; a model without it can answer questions but cannot carry anything out.