Network device onboarding

Network device onboarding

RADIUS, 802.1X, MAB, guest WiFi, DHCP relay and AAA dead-server detection for the top SME network device vendors. Connecting via the Arbiter Edge RadSec appliance: no per-vendor SDK, no plugin, no inbound firewall rule.

How Arbiter connects to your network

Arbiter is a cloud-hosted, multi-tenant RADIUS service. Your switches and access points never talk to the cloud directly. Instead, they talk to one or more Arbiter Edge appliances on your LAN over standard RADIUS UDP. The Edges tunnel everything to Arbiter cloud over a mutually-authenticated TLS connection (RadSec, RFC 6614, TCP/2083).

Customer LAN (trusted)Switch802.1X / MABauthenticatorAccess point802.1X / MABauthenticatorArbiter Edge Aterminates RADIUS, relays DHCP,injects Message-Authenticator30-day local cacheArbiter Edge Bactive / failover-readysame tenant PSK and certas Edge ARADIUS UDP / 1812DHCP relay / UDP 67Public internetArbiter cloudpolicy + authHetzner Falkenstein, DERadSec TCP/2083mTLS, outbound only
Two Edge appliances on the LAN, active and failover-ready, take plain RADIUS UDP from your switches and access points and tunnel encrypted RadSec out to Arbiter cloud. Nothing inbound, no per-vendor agent and the Edges hold a 30-day local cache so authentication keeps working if the WAN drops.

Recommended deployment

  • Two Edge appliances per site in active/active. Both terminate RADIUS independently. Configure each network device with both Edges as RADIUS servers.
  • Same tenant PSK on both Edges. No per-device reconfiguration during failover.
  • DHCP helper to both Edges alongside your real DHCP server. The Edge only listens; it never responds, so adding it to the helper list has zero impact on DHCP service.

What you configure on every device

The integration surface is small. Everything else in the per-vendor guides is just the same handful of settings in each platform's native syntax.

SettingValue
RADIUS server (primary)Edge appliance #1 LAN IP
RADIUS server (secondary)Edge appliance #2 LAN IP
Auth port1812/udp
Accounting port1813/udp
CoA port3799/udp (some Cisco WLCs use 1700)
Shared secretTenant PSK from your Arbiter portal
DHCP helper / relayEdge #1 and #2 LAN IPs (plus your real DHCP server)
Captive portal URLhttps://<shortname>-<portal-id>-guest.arbiter.ie/

AAA dead-server detection

The default RADIUS timeout / retry behaviour on most platforms produces 15+ seconds of auth delay before the NAS tries the secondary server. With two Edges per site, the recommended cadence is: declare a server dead after a 30-second window across four consecutive attempts, then hold the dead flag for 3 minutes before retrying.

The canonical pattern on Cisco IOS:

! 1. Declare the server dead after 30s with no reply across 4 attempts
radius-server dead-criteria time 30 tries 4

! 2. Hold the dead flag for 3 minutes before retrying
radius-server deadtime 3
SettingRecommended
Dead-criteria window30 seconds
Dead-criteria attempts4 consecutive failed tries
Dead time3 minutes
Active probeEnabled where the vendor supports it (e.g. Cisco automate-tester, AOS-CX radius-server tracking)

Per-vendor syntax for each setting is in the per-vendor pages linked below. Vendors with no formal dead-criteria knob (Omada, MikroTik) document the limitation inline.

Message-Authenticator

Arbiter cloud enforces Message-Authenticator (RFC 3579 §3.2) on every tenant FreeRADIUS client block. This defends against the BlastRADIUS class of attacks (CVE-2024-3596).

You don't need to disable anything or set a per-NAS mode. Modern NAS platforms emit Message-Authenticator natively; for legacy switches that can't, the Edge appliance injects the attribute on the inner hop using the tenant PSK.

Vendors

Pick your platform for the vendor-specific syntax. All ten use the same Arbiter integration; only the CLI or dashboard idiom changes.

Cisco Catalyst

IOS / IOS-XE

Cisco Meraki

MS switches, MR access points

Aruba CX

AOS-CX 10.x

Aruba Instant / Instant On

Controller-less APs + SMB cloud line

Ubiquiti UniFi

UDM / Cloud Key / Network Application

Fortinet

FortiGate + FortiSwitch + FortiAP

HPE Aruba AOS-Switch

2530 / 2930 / 3810 (legacy 'ProCurve')

MikroTik

RouterOS 7.x

Juniper EX

JunOS 21.x+

TP-Link Omada

Controller-managed switches and EAPs

Validation checklist

Once a device is configured, validate against the Arbiter portal rather than the vendor's own RADIUS test tooling. Vendor tools confirm reachability but not policy outcomes.

Expand the five checks

1. RADIUS reachability

  • In the Arbiter tenant portal, open the NAS Devices tab. The newly configured switch or AP should appear within seconds of its first auth attempt.
  • The Source IP column should show the NAS LAN IP. If it shows the Edge IP instead, the NAS isn't reaching the Edge directly. Check L2/L3 path and ACLs.

2. Authentication outcome

  • Open the Auth Log tab. Each device that tries to authenticate appears with timestamp, MAC, NAS, auth method (MAB or dot1x) and policy outcome.
  • An Access-Accept with a Tunnel-Private-Group-Id means VLAN assignment worked end-to-end.
  • An Access-Reject with no policy match means the device fell through every policy. Usually a missing default-allow or a deliberate Tier 1 reject.

3. DHCP fingerprinting

  • Open the device's drawer in the Devices tab. Within a minute of DHCP traffic, the Vendor, Profile and Hostname fields should populate.
  • If they don't, the Edge isn't receiving DHCP. Recheck the ip helper-address list on the VLAN's SVI.

4. CoA delivery

  • Trigger a CoA from the portal: select an endpoint then Actions then Disconnect, or change its policy to force a VLAN change.
  • The CoA Actions tab shows the dispatch state. delivered_at populated means the frame was written to the tunnel; a NAS ACK appears as a separate audit-log entry.
  • If the action stays queued, check the NAS's CoA listener (dynamic-author / dyn-authorization/ radius-coa) and the per-NAS CoA port in the Arbiter portal.

5. Dead-server failover

  • Stop one Edge appliance (systemctl stop arbiter-edge).
  • Trigger an auth from a wired or wireless client.
  • In the Auth Log, the request should be served by the surviving Edge (visible via the Source IP of the inbound RadSec tunnel).
  • Restart the Edge. After dead-time expires (5 minutes with the recommended config), traffic should rebalance.

Glossary

Expand acronyms and protocol terms
TermMeaning
802.1XIEEE port-based network access control. The supplicant (client) authenticates to the authenticator (switch / AP) which proxies credentials to a RADIUS server.
MABMAC Authentication Bypass. RADIUS authentication using the device MAC as the username, used for devices that cannot do 802.1X (printers, IoT, some phones).
EAP-TLSCertificate-based 802.1X variant. Both supplicant and server present X.509 certificates.
RadSecRFC 6614. RADIUS over TLS over TCP/2083. mTLS variant used between Arbiter Edge and Arbiter cloud.
CoAChange-of-Authorisation, RFC 5176. Server-initiated message to a NAS to alter or terminate an existing session.
NASNetwork Access Server. RADIUS term for the device a client physically connects to (a switch, AP or wireless controller).
Message-AuthenticatorRFC 3579 / RFC 2869 attribute 80. HMAC-MD5 over the RADIUS packet; defends against CVE-2024-3596 (BlastRADIUS).
Edge applianceCustomer-side VM or physical appliance that terminates RADIUS UDP from the LAN and tunnels to Arbiter cloud over RadSec.
Tenant PSKRADIUS shared secret. One per Arbiter tenant. Used between NAS and Edge.

Don't see your vendor?

We add vendor guides on demand. If you're integrating Arbiter with kit not covered here, email support@arbiter.ie with the platform name and model and we will review it for a write-up.

Spotted something wrong in one of the guides above? Let us know at support@arbiter.ie with the vendor and the line that's off and we will correct it.

All guides