Stand up wireless 802.1X (WPA-Enterprise)

When you need this

You already have 802.1X in monitor mode working on a wired switch, and now you want a wireless SSID to authenticate against the same l2trace RADIUS server. This is WPA-Enterprise (WPA2-Enterprise or WPA3-Enterprise): the access point is the authenticator, the client is the supplicant, and l2trace is the RADIUS server that decides.

The wired setup and the wireless setup are almost identical from l2trace’s side. There is exactly one thing wireless needs that wired does not, and l2trace now handles it for you.

The one difference: session keys

A wired switch authorizes a port and then forwards frames in the clear. It never needs an encryption key, so an Access-Accept with no key attributes is enough.

A wireless AP cannot do that. After the RADIUS server says Accept, the AP runs a 4-way handshake with the client to derive the over-the-air encryption keys, and it needs a Pairwise Master Key (PMK) to do it. The AP never sees that key directly; the RADIUS server hands it over in the Access-Accept as the salt-encrypted MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes, derived from the PEAP TLS session. Without them the client authenticates but never associates, which looks like a silent 4-way-handshake timeout on the client.

l2trace derives and emits those keys automatically on a successful PEAP authentication. There is nothing to enable. If you want the details of how the key is derived and why it is done the way it is, see How the wireless session keys are derived.

Steps

1. Register the AP as a RADIUS client

An access point is a NAS like any switch. Register it as a device with its management IP, and give it a radius_secret the same way a switch gets one, as an env:// URI resolved through the secrets layer:

-- the AP's management IP is the source l2trace matches RADIUS packets against
UPDATE device_collector
SET auth = auth || '{"radius_secret": "env://AP_RADIUS_SECRET"}'
WHERE device_id = (SELECT id FROM device WHERE hostname = 'ap-lobby-1');

The shared secret must match on both sides. l2trace resolves it from its environment; the AP stores it in its RADIUS profile.

2. Configure the WPA-Enterprise SSID on the AP

On the controller or the AP itself, create a WLAN with:

• Security: WPA2-Enterprise or WPA3-Enterprise (802.1X), not Personal / PSK.
• RADIUS server: l2trace’s address on UDP 1812 (auth). Accounting on 1813 is optional and not consumed yet.
• Shared secret: the same value env://AP_RADIUS_SECRET resolves to.

The AP must be able to reach the l2trace RADIUS server, and l2trace must have the AP’s source IP in its client registry (step 1). A packet from an unregistered source IP, or one whose Message-Authenticator does not verify, is dropped.

3. Provision a test identity and connect

PEAP / EAP-MSCHAPv2 authenticates a username and password from the credential store. Point a laptop or phone at the SSID with a test identity, and watch the server log: a full PEAP handshake, then the Accept carrying the MS-MPPE keys, then the client associating.

Monitor mode behaves differently on wireless

On a wired switch, monitor mode is safe because the switchport runs authentication open: an Access-Accept with no VLAN changes nothing. There is no equivalent on wireless. On a wireless SSID, an Access-Accept is association.

l2trace keeps monitor mode honest anyway. A monitor-mode PEAP failure (a bad password, an unknown user) still returns Access-Accept so a wired port is never cut, but it deliberately carries no MS-MPPE keys. With no keys the AP’s 4-way handshake fails and the client does not get on the air, while the discrepancy is still recorded. So a bad credential in monitor mode is logged, not admitted.

Caution

Because an Accept is access on wireless, do not treat a wireless SSID as a zero-impact monitor surface the way you would a wired port running authentication open. Prove the policy on a lab SSID first, exactly as you would before enforcing on a production wired port.

Validation status

Wireless WPA2-Enterprise is validated end to end against real hardware: a Ubiquiti UniFi 6 Lite access point running OpenWrt, with a real wpa_supplicant client. A PEAP / EAP-MSCHAPv2 authentication succeeded, l2trace derived the MS-MPPE session keys, the AP ran its 4-way handshake, and the client fully associated with CCMP encryption (wpa_state=COMPLETED, pairwise_cipher=CCMP).

Two offline checks back that up and do not need an access point: the TLS 1.2 PRF matches OpenSSL’s TLS1-PRF byte for byte, and two independent TLS endpoints (the server and an in-process supplicant) derive the identical 64-octet master session key, which is an interoperability proof, not just self-consistency.

Caution

The TLS 1.2 PRF hash must follow the negotiated cipher suite. The SHA384 AEAD suites use SHA-384, not the SHA-256 default, and a wrong PRF hash yields a wrong key that the peer rejects in the 4-way handshake as an opaque timeout. See how the session keys are derived.

When you run your first real AP, watch for the client reaching the 4-way handshake: if authentication succeeds but association times out, the keys are the thing to look at first.

See also

• Stand up 802.1X in monitor mode, the wired base this builds on
• How the wireless session keys are derived, the PRF, the key-log, and the monitor-mode gate
• The security model, and the sharp edges, where wireless access control sits in the threat model
• Manage secrets, the env:// URI a radius_secret uses