A native Ubuntu NAC appliance. FreeRADIUS makes network access decisions; the management API configures policy; local services collect events and expose diagnostics.
PortGuardNAC is a RADIUS policy and monitoring appliance. Switches and access points enforce admission and VLAN placement; endpoint traffic does not pass through the appliance.
A wired or wireless endpoint connects through a switch or access point. The network device sends an 802.1X request or, where supported, a per-device Wi-Fi key request to RADIUS.
FreeRADIUS processes authentication and consults local policy services. The appliance returns RADIUS Access-Accept or Access-Reject, with VLAN attributes where configured.
The switch or AP applies the result. RADIUS accounting and authentication events feed the dashboards. A configured switch can receive a Change of Authorization request.
Each appliance runs native Ubuntu services under systemd. The diagram groups services by responsibility; it does not depict separate hardware or a path for endpoint traffic. The supervised two-node HA setup is shown below.
nginx serves the dashboard over HTTPS. The local API manages administrators, identities, network policies, certificates, maintenance settings and audit records.
FreeRADIUS processes RADIUS and EAP requests. A separate helper applies privileged changes, including RADIUS configuration and guarded system package operations.
Local workers collect RADIUS events and supply dashboard data. Redis supports internal event delivery; a separately configured exporter provides bounded NAC metrics.
nginx.service → portguardnac.service (management); freeradius.service + portguardnac-ctrl.service (NAC and privileged control); portguardnac-radius-collector.service + portguardnac-dashboard-api.service (events and dashboard data); portguardnac-redis.service (internal event bus). Verified application releases are installed by a separate root-controlled maintenance service.
SQLite stores application configuration and selected operational data; RADIUS events and accounting have their own local records. Redis is an internal event bus, not the long-term audit archive. Encrypted backup packages, application audit records and Linux host audit logs are stored separately and have different retention controls.
Authentication methods, identity sources and enforcement rules are configured separately. Their availability depends on the network device, certificates and enabled integrations.
FreeRADIUS terminates supported EAP methods, including EAP-TLS and password-based methods. The appliance can issue and manage client certificates; supplicants should validate the configured RADIUS server certificate.
Access policies can use local identities and data from configured LDAP/LDAPS or Microsoft Entra ID integrations. Dashboard administrators can sign in locally or, when configured, through LDAP/LDAPS, Entra ID OIDC or SAML 2.0. Federated users require an assigned appliance role.
Access policies can allow or reject a request and return network attributes such as a VLAN. The switch or access point applies them. Where supported and configured, Change of Authorization can request reauthentication, disconnection or a VLAN change.
Unique Pre-Shared Key (UPSK) assigns an individual Wi-Fi key and VLAN to a known device on a dedicated SSID. The AP must support RADIUS-assigned PSKs through Tunnel-Password and dynamic VLAN attributes. Administrators can rotate or revoke keys in NAC → Wireless Keys.
MAC authentication bypass (MAB) is available for devices that cannot use 802.1X, subject to compatible switch configuration and explicit policy. Captive portal and voucher flows can be enabled for selected guest scenarios.
Optional Microsoft Intune and Defender integrations provide read-only posture data. Enforcement is tied to an explicitly bound device certificate; monitor mode records findings without changing network access. Unknown or stale posture is not treated as compliant in enforce mode.
Authentication and accounting records support session state, method reporting, VLAN visibility and troubleshooting. Endpoint IP addresses appear when the network device supplies them.
The dashboards show access events, device state and classified IoT/OT incidents. A registered sensor must submit an HMAC-authenticated anomaly report before it becomes an IoT/OT incident.
For an eligible incident, PortGuardNAC can arm a quarantine policy and send CoA to an enabled switch with a fresh accounting session. The operator then verifies isolation and records a triage decision.
An optional HTTPS metrics endpoint exposes bounded diagnostic and alarm metrics with a bearer token and source allowlist. Prometheus can collect those metrics for Grafana dashboards; SNMP monitoring is available separately.
A read-only advisory checks for one MAC with fresh active RADIUS accounting on different NAS devices. Roaming and delayed accounting can produce false positives; the appliance does not automatically block or move the endpoint. EAP-TLS provides stronger device identity.
HTTPS terminates at nginx. Administrator sessions use a signed cookie, role-based permissions and configurable multifactor authentication.
Management-to-control requests use mutual TLS. The local telemetry API is bound to loopback and reached through the reverse proxy; it is not an mTLS service.
Systemd restrictions limit service access. The control helper uses a separate service account for delegated operations; the management and telemetry processes do not each have a dedicated OS account.
Selected administrative and security actions enter the appliance audit trail; RADIUS event records are separate. Application release signatures and checksums are verified before installation.
| Connection | Purpose | When needed |
|---|---|---|
| Administrator → appliance HTTPS | Dashboard and management API | Administrative access |
| Switch/AP → appliance RADIUS | Authentication on UDP 1812; accounting on UDP 1813 | 802.1X, MAB or compatible Wi-Fi access |
| Appliance → switch/AP CoA | Reauthentication, disconnect or VLAN change on the configured UDP port | Only for supported, enabled network devices |
| Registered sensor → appliance HTTPS | HMAC-authenticated IoT/OT anomaly reports | Only when sensor integration is configured |
| HA secondary → primary SSH | Pinned-host-key transport for signed configuration snapshots; source-IP-restricted export account | Only in an explicitly paired HA pilot |
| Prometheus → appliance HTTPS | Token-protected diagnostic metrics with a source allowlist | Optional external monitoring |
| Appliance → external services | Identity, posture, update, registry or feed connections | According to the enabled feature and network mode |
Use a trusted management network and permit only the traffic required by the deployment. Actual switch, AP and identity-provider settings are customer-specific. Vendor-signed license data is validated locally; the installation registry does not make network access decisions.
Application releases are signed, verified and installed by a root-controlled maintenance service with health checks. Ubuntu packages use a guarded APT workflow; some updates require a reboot.
The appliance can create encrypted backup packages. Keep an independent recovery passphrase outside the appliance and test restoration on an isolated VM before relying on a recovery plan.
The support bundle contains selected health, service, configuration-summary and recent diagnostic results. Known secrets and private keys are excluded; anonymization and encryption are optional. The customer reviews and sends the file manually, with any recovery passphrase shared separately. Application-event and Linux host audit retention are managed separately.
The two-node HA implementation is included in the current 1.1.15 customer ISO for supervised pilot deployments. It has passed isolated VMware and lab RADIUS fallback tests but is not yet qualified for production failover on a customer's physical switches. An Enterprise HA-pair entitlement binds one signed license to two named appliance IDs; it does not authorize a third VM. Each node retains a separate IP. Both can answer RADIUS, while the switch or controller chooses its backup server using its own timeout and retry settings. There is no floating IP or automatic management-writer election.
The standby pulls a signed snapshot about 15 seconds after it starts, then on a 30-second timer after each completed pull. The primary publishes on a 30-second timer. A stale sync is visible in HA status; the standby continues to serve its last verified policy. VMware testing proved RADIUS authentication while the primary VM was powered off. Failover time must be measured on the actual switch.
Snapshots contain RADIUS secrets and EAP private key material. They are transferred over SSH using a pinned host key and source-IP-restricted export account, then checked with an Ed25519 signature before import. Protect both nodes and their backups; do not treat replication as a backup.
Each appliance keeps its own OS hostname, IP address, SSH host key and management HTTPS identity. The signed snapshot copies the shared RADIUS EAP certificate, key and trust bundle. The secondary activates those files in FreeRADIUS before acknowledging the import. Supplicant profiles must trust the certificate issuer and an expected server name present in that certificate; authenticate a test client against both RADIUS addresses.
Ubuntu and application updates are not pushed between nodes. Each node requires its own authorized maintenance and validation; both must run the same PortGuardNAC release before replication resumes. A promoted standby becomes writable only after the old primary is fenced. The old primary does not automatically rejoin as standby.
Physical switch failover timing, accounting and CoA behavior after fallback, issued certificate-package availability and complete recovery tests remain open. HA in the current 1.1.15 ISO remains a supervised pilot until those checks pass.
Use Admin → High Availability on each appliance. A Super Admin and a signed Enterprise HA-pair entitlement for the two Appliance IDs are required to change HA configuration. Keep the nodes on the same PortGuardNAC release, with distinct management IPs and synchronized clocks.
Install the same release on both appliances, assign separate management IPs and hostnames, and record both Appliance IDs in License / Legal. Obtain the signed Enterprise HA-pair license and activate it on both nodes. Allow the secondary to reach the primary HA export service over SSH. Back up each node before pairing.
On the configuration writer, choose Initialize primary. Record the primary SSH host key and snapshot signing public key. Verify both values through a trusted channel before entering them on the secondary.
On the second node, enter the primary IP and verified keys, then choose Join secondary. Copy the secondary SSH public key to the primary. On the primary, enter that key and the secondary IP, then choose Authorize secondary.
Choose Start publishing on the primary, then Start replication on the secondary. Check the imported sequence, sync age, release match and 100% configuration progress. The primary publishes and the secondary pulls on approximately 30-second timers; a full progress bar alone does not prove network failover.
Configure every switch or AP with both RADIUS server IPs and the correct shared secrets. Test a real 802.1X accept and reject against each node. Confirm FreeRADIUS on the secondary presents the shared PortGuardNAC EAP certificate and that supplicants trust its expected server name.
With a test port and an approved change window, make the primary RADIUS address unavailable and measure switch fallback. Restore it and verify normal authentication. For updates, back up and validate the secondary first, then the primary; packages are not forwarded automatically. Management promotion requires fencing the old primary and an explicit console action.
The node hostnames, management HTTPS certificates, SSH host keys, licenses, audit logs and update history remain local. The signed snapshot copies shared NAC policy, managed certificate material and RADIUS EAP trust. See the HA certificate troubleshooting guide.
Core NAC decisions remain local. The appliance can contact update catalogs and a limited installation registry. Configured cloud identity, posture, vulnerability feeds, remote backup and monitoring services may require additional connections. The registry heartbeat can be disabled.
Local NAC operation can run without internet access. Air-gapped mode stops online update checks and installation-registry heartbeats. Import vendor-signed application releases locally and use a trusted signed local APT repository for Ubuntu updates. Plan internal identity, time, DNS and certificate services; cloud integrations cannot refresh offline.
The core diagram describes the customer appliance; the two-node HA diagram and setup sequence describe the supervised pilot included in the current 1.1.15 customer ISO. Available flows depend on the installed release, configuration and compatible network devices and identity services.