EntryPoint diagnostics
Why an EntryPoint authentication failed — a structured walk through the common causes. Start from the symptom, narrow by variant. Covers EAP-PEAP, EAP-TLS with Microsoft Entra ID, iPSK, and Radius Proxy.
“The device can’t connect” is the top EntryPoint support call. Most issues come down to one of: RADIUS reachability, the per-Context shared secret, the IP access allow-list, the identity not being in the right Group, or (for EAP-TLS) the certificate chain. This page structures the diagnostic walk by symptom first, then by variant.
Start with the Context counters
Section titled “Start with the Context counters”Before anything else, look at the Context overview’s Groups / Devices / Online counters.
- No Devices counter movement at all when a test device tries to authenticate → the request isn’t reaching EntryPoint. Skip to section 1 below.
- Devices counter ticks but Online stays flat → the request reaches EntryPoint but Access-Reject is returned. Go to section 2 or 3 depending on whether you see a reject-with-detail in the WLAN controller logs.
- Online shows the device but the user says “disconnected” → accounting is stale (missing Interim Updates) or the device is actually off. See section 5.
1. Is the RADIUS packet reaching EntryPoint?
Section titled “1. Is the RADIUS packet reaching EntryPoint?”Symptoms. The client’s RADIUS logs show timeouts; the Context’s counters show no change.
What to check.
- The WLAN controller / switch / Meraki network has the Context’s Radius Hostname exactly right.
- The ports match (Authentication / Accounting from the Network Integration tab; RadSec port only if RadSec is enabled).
- Firewalls between the equipment and EntryPoint permit the RADIUS traffic (UDP 1812/1813 for plain RADIUS; TCP for RadSec).
- The source IP of the controller is inside an allowed CIDR under Configure RADIUS Access Restrictions on the Context. An empty allow-list denies all traffic.
See RADIUS clients.
2. Shared secret mismatch
Section titled “2. Shared secret mismatch”Symptoms. EntryPoint sees packets but rejects with a “bad authenticator” error; the client logs show Access-Reject with no useful detail.
What to check.
- Re-enter the shared secret on both sides — trailing whitespace is the classic typo.
- Confirm you’re editing the right Context. One Organization can have several EntryPoint Contexts, each with its own secret.
- After rotating the per-Context secret on EntryPoint, every attached piece of equipment needs updating. Until they’re all updated, equipment still using the old secret is rejected.
3. Identity / membership mismatch
Section titled “3. Identity / membership mismatch”Symptoms. The RADIUS round-trip completes and ends in Access-Reject. The WLAN controller logs show a rejection after reaching EntryPoint.
What to check — by variant:
EAP-PEAP (local Personal PEAP Account)
Section titled “EAP-PEAP (local Personal PEAP Account)”- The user has been invited into the expected PEAP Group — confirm on the Group’s Users tab.
- The Personal PEAP Account username and password typed into the user’s supplicant match what their Self-Service portal shows them.
- The Group itself exists and is referenced correctly from the Context.
See EAP-PEAP groups per company and Self-Service & Personal PEAP Accounts.
EAP-TLS with Microsoft Entra ID
Section titled “EAP-TLS with Microsoft Entra ID”- The certificate’s chain validates against a CA in the Context’s Trusted CAs list.
- The certificate isn’t expired.
- The CRL (if configured) doesn’t list the certificate as revoked.
- For Device Cert Groups: the value EntryPoint matches against the Group’s Certificate Group Identifier is actually present in the cert.
- The cert’s bearer (user UPN or device name) resolves in the Entra tenant.
- The bearer is a member of the Entra group the EntryPoint Group is mapped to.
- If Enable Device Compliance Check is on, Entra marks the device compliant.
See User certificates, Device certificates and Intune, and Entra group mapping.
MAB (inside a Device-Cert Group)
Section titled “MAB (inside a Device-Cert Group)”- The device’s MAC is on the MAB Device List of the expected Device Certificate Group.
- MAC format (colons vs dashes) imported cleanly — a subtle copy/paste error is enough to make entries mismatch.
- The WLAN controller is configured to fall back to MAB when 802.1X fails — otherwise MAB packets never arrive at EntryPoint.
See MAB fallback inside Device-Cert.
- The device’s MAC is in exactly one iPSK Group.
- The PSK on the device matches the Group’s current shared PSK. If the Group’s PSK was rotated recently, every device needs updating to the new key.
- The Cisco WLAN controller is sending MAB packets and expecting a PSK attribute in the Access-Accept — without that, iPSK can’t work.
- CoA listeners (if configured) point at the right Cisco controller so rotations propagate.
See iPSK Groups and shared PSK.
Radius Proxy
Section titled “Radius Proxy”- The upstream Remote Radius Server is reachable from the FQDN shown on the Remote Radius Server card.
- The upstream operator has allow-listed your EntryPoint deployment’s outbound FQDN on their side.
- Shared secret or RadSec certificate matches on both sides.
- For RadSec: the upstream’s CA is uploaded on EntryPoint and the port is set to the RadSec port.
- The upstream server knows the user in question — the forwarded request has to resolve to an identity upstream.
See Remote Radius Server and RadSec.
4. Method not enabled on the Context
Section titled “4. Method not enabled on the Context”Symptoms. The supplicant tries PEAP (or EAP-TLS) and gets a clean rejection without the request seeming to reach any Group.
What to check.
- Open Configuration → Basic Configuration → Client Authentication Methods. Confirm the method is toggled on and saved.
- For EAP-TLS User Certificate Groups: the Entra API Status card on the Identity Store configuration shouldn’t show an error.
- For EAP-TLS: at least one Trusted CA is uploaded on the Context.
5. Wireless / wired-side gotchas
Section titled “5. Wireless / wired-side gotchas”- SSID misconfigured — pointing at a different RADIUS server, or the security type doesn’t match (WPA2-Enterprise vs WPA2-PSK vs Identity PSK).
- Supplicant profile — wrong EAP type picked, CA trust missing, identity format wrong, certificate not installed.
- Missing Interim-Update accounting — the Devices counter on the Context doesn’t refresh, so sessions look stuck “offline” even though the device is connected. Recommended Interim interval: 600 seconds.
- MAC randomisation on personal devices — Wi-Fi profile on iOS / Android / Windows randomises MAC per SSID. A MAB entry added yesterday may not match today’s MAC. Use MAB only for equipment you control.
Reading counter cards and Connected Devices lists
Section titled “Reading counter cards and Connected Devices lists”- Context overview — Groups / Devices / Online counters. “Online” reflects accounting status; if your client equipment isn’t sending Interim Updates, this lags reality.
- Group’s Connected Devices tab — columns for Description, Last seen online, Added by, Added, IP address, Connection info, MAC, Device type, OS, Browser.
- Audit Log (under the Administration section of the Context’s nav) — records every admin-side change to the Context. Useful for “did someone just change something that broke auth”.
When nothing matches
Section titled “When nothing matches”- Capture the RADIUS exchange from the client side (tcpdump, Wireshark, or the equipment vendor’s debug tools). The actual reject reason almost always appears there.
- For iPSK, confirm the WLAN controller is actually sending the device MAC and asking EntryPoint for a PSK — without that, iPSK can’t work regardless of what’s configured in EntryPoint.
- For Radius Proxy, capture on the proxy’s forwarding leg to see whether the upstream is receiving the request at all.
- Check the Context’s Audit Log for a recent admin-side change that might have broken configuration.
- Rotate the Entra client secret if Entra API Status reads “expired”. Most surprising reject waves start here.