Arista SD-Branch Part 9: Wireless EAP-TLS, UPSK and Guest Portal Policy with AGNI

14 October 2026 CloudVisionAGNISD-BranchArista CampusWireless802.1XUPSK

The wired policy in Part 8 and the wireless policy here use the same AGNI. What changes is the enforcement point: the access point, configured in CV-CUE. This post follows Arista’s published wireless lab material for AP onboarding, an EAP-TLS SSID, UPSK and a guest portal. I have not deployed any of it.

Step one: RadSec for the access points

Access points need the same RadSec trust as switches, set up through CV-CUE and AGNI.

  1. In AGNI, add the AP as an access device using its serial number.
  2. In CV-CUE, place the AP in a folder, then generate a CSR for it under a certificate tag and download it.
  3. Paste the CSR into AGNI to get a signed client certificate, and download the RadSec CA certificate. Note the RadSec server hostname.
  4. Upload the signed certificate to the AP in CV-CUE using the same certificate tag.
  5. Create a RADIUS server definition in CV-CUE with RadSec enabled, port 2083, the AGNI hostname, the CA certificate and the certificate tag.

The certificate tag is the detail that trips people up. The tag used when the CSR was generated has to be the tag used when uploading the certificate and creating the RADIUS server. If they differ, the server definition cannot find the right certificate.

EAP-TLS on an SSID

For an enterprise SSID the pattern mirrors the wired network.

  • In AGNI: a wireless network that requires EAP-TLS, and a segment matching that network name and authentication type with an Allow Access action and a role profile.
  • In CV-CUE: an SSID whose client authentication uses the RadSec server for authentication and accounting, and role-based control set to match the default 802.1X VSA so that the role AGNI returns decides the client’s role.

Clients need a certificate, which is where AGNI’s onboarding helps. The datasheet describes a self-service SSO onboarding flow backed by the built-in PKI, or you can use Intune or Jamf to push certificates from an external CA.

UPSK for devices that cannot do 802.1X

Many IoT devices have a passphrase field and nothing else. A single shared passphrase for all of them means one leaked device compromises the lot. UPSK gives each user or device group its own key on the same SSID, and AGNI maps the key to a group and a role. Arista’s lab covers configuring unique pre-shared keys and grouping devices. Revoking one device’s key does not touch the rest, which a shared PSK cannot offer.

Guest access with a captive portal

The guest design has two halves.

AGNI:

  • A guest network using captive portal authentication with an internal portal.
  • A portal set to click-through, re-authenticating guests every time, with the portal URL copied out for CV-CUE.
  • A segment that matches the guest network name and assigns a guest role profile.

CV-CUE:

  • A portal role that redirects statically to the AGNI portal URL, with HTTPS redirection on.
  • A guest role. The lab uses VLAN 0 for simplicity. In production, set a real guest VLAN, and apply firewall rules and bandwidth limits here.
  • A guest SSID using RADIUS MAC authentication over RadSec, with role assignment from the default 802.1X VSA.

Start with a plain MAC authentication test before adding the portal, so you know RadSec and roles work before you debug redirection.

Tunnelling guest traffic

To keep guest traffic off the branch LAN, the lab tunnels it. A tunnel profile in CV-CUE creates a VXLAN interface with a remote endpoint and a VNI offset, and the guest SSID’s network mode is set to L2 tunnel using that profile. On the switch side, the guest VLAN maps to a VNI, and you confirm clients show addresses in the guest VLAN. In the lab the tunnel terminates on spine switches in CloudVision as a Service.

For a small branch without a spine pair, the practical equivalent is a guest VLAN that is isolated at the firewall. Tunnelling to a central point earns its keep when many branches should share one guest breakout.

Verification

Join the SSID, confirm the portal appears, then check the client under Monitor, Clients in CV-CUE and under Sessions in AGNI. If the client appears in CV-CUE and not in AGNI, the problem is RadSec or the RADIUS server definition. If it appears in both but lands in the wrong role, look at the segment.

Sources