12934 Supplicant Stopped Responding To ISE During PEAP Tunnel Establishment | Fast Fix Checklist

If you’re seeing “12934 supplicant stopped responding to ise during peap tunnel establishment” in Live Logs, you’re not alone. It’s one message that feels vague, yet it points to a set of failure points. ISE is waiting for the next EAP packet. It never shows up, or it arrives too late, so the session ends.

This article helps you pin down where the EAP chat stops, then clear the blocker without guesswork. You’ll get a staged view of PEAP, a triage table, and checks for the endpoint, the NAS, and ISE.

What 12934 Really Means In PEAP

PEAP starts with a TLS handshake between the client and ISE. If the client rejects the server certificate, can’t agree on TLS settings, or loses packets mid-handshake, it may stop sending EAP responses. ISE records that stall as “supplicant stopped responding,” tagged with 12934. Cisco’s generic resolution text points you to three areas: the supplicant config, the NAS forwarding EAP, and timeouts or transport issues between NAS and ISE.

Where You’ll See It In ISE

You’ll usually spot 12934 in Live Logs. In the detailed report, the exchange often ends right after ISE sends a TLS message. On wireless, WLC noise can clutter the timeline, so anchor on the EAP sequence and its timestamps.

What It Is Not

12934 is not a clean “bad password” sign. It also does not prove the switch or controller is wrong. It only tells you ISE did not receive what it expected next.

When Supplicant Stopped Responding During PEAP Tunnel Setup Shows Up

When you slice PEAP into stages, you can aim your checks instead of chasing every setting. The NAS passes EAPOL from the endpoint and wraps it in RADIUS to ISE. ISE replies with EAP inside RADIUS. The endpoint decides whether to continue.

1. Start The Exchange — Outer identity is exchanged and ISE selects PEAP.
2. Negotiate TLS — ISE presents its server certificate and TLS options, and the endpoint validates trust and crypto rules.
3. Run Inner Auth — The encrypted tunnel carries MSCHAPv2 or inner EAP-TLS, then ISE returns Accept.

12934 most often lands in stage two. A packet capture on the access port or WLAN can show the last server packet that the client ignored.

Fast Triage For 12934 Supplicant Stopped Responding To ISE During PEAP Tunnel Establishment

These checks cover the highest-hit causes. If only a slice of endpoints fail, lean toward endpoint policy or driver issues first. If all endpoints fail at once, lean toward certificates, timers, or a network path change.

Endpoint Causes And Fixes That Clear 12934

On many incidents, the endpoint is the one that stopped talking. Windows uses Wired AutoConfig for wired 802.1X and WLAN AutoConfig for wireless. In managed fleets, a small mismatch in the deployed profile can make the client bail out mid-handshake.

Server Certificate Trust And Server Name Rules

PEAP depends on the client trusting the server certificate that ISE presents. If the issuing CA is not trusted, or the profile pins the wrong server name, the client may drop the exchange with no prompt.

Clock drift can break PEAP in a quiet way. If the endpoint time is off, certificate validity checks fail and the client may stop responding. Check NTP, BIOS clock, and time zone on failing devices. If you use CRL or OCSP checking, confirm the endpoint can reach those URLs on the network it is authenticating to. A reboot after time sync can clear cached errors.

1. Verify The CA Chain On The Endpoint — Ensure root and intermediate CA certificates are present in the right store for machine auth.
2. Match The Server Name List — Align “connect to these servers” with the certificate SAN entries ISE actually presents.
3. Retest With Validation On — Avoid leaving validation disabled; use it only as a quick proof of trust failure.

TLS Version Mismatch And Cipher Blocks

Hardening baselines can disable older TLS versions or ciphers. If ISE and the endpoint can’t agree on a common set, the TLS handshake stops and ISE logs 12934.

1. Keep TLS 1.2 Enabled End To End — Verify the endpoint and ISE both allow TLS 1.2 for EAP.
2. Check Recent Baseline Changes — Review any policy that disabled ciphers, SHA-1, or RSA key exchange on the endpoint.

Profile Drift From GPO Or MDM

“Works in one OU, fails in another” usually means profile drift. Some Windows builds will also try once at logon, then pause before retrying, which can look like a dead endpoint.

1. Confirm The Effective 802.1X Profile — Compare the applied wired or Wi-Fi profile on a good and bad device.
2. Clear Stale Profiles — Remove older profiles that still pin retired server names or old CA thumbprints.
3. Restart AutoConfig Services — Restart Wired AutoConfig or WLAN AutoConfig, then force a reauth on the port or SSID.

NIC Drivers And Power Saving

If failures cluster around a laptop model, dock, or NIC chipset, treat the driver as suspect. Cisco forum replies often point to driver upgrades as the fix. Power saving can also pause the adapter long enough to miss an EAP request.

1. Update The NIC Driver — Use the OEM driver package, not only the Windows inbox driver.
2. Disable Adapter Power Saving — Turn off “allow the computer to turn off this device” for affected adapters.

Client Logs That Pinpoint The Stop

ISE can only report a stall. The endpoint logs often show the cause, such as certificate trust failure or TLS alerts. On Windows, Event Viewer under Wired-AutoConfig or WLAN-AutoConfig is a strong starting point. For AnyConnect Network Access Manager, a DART bundle can capture EAP details.

NAS And Network Checks That Stop The Drop

The NAS sits between the endpoint and ISE. It must pass EAP cleanly inside RADIUS. If timers are too short, fragments get dropped, or the AAA path is filtered, the endpoint can time out and stop replying, leaving ISE to log 12934.

RADIUS And 802.1X Timeouts

TLS needs several round trips. On busy WLANs or high-latency links to a central ISE cluster, default timers can be tight.

1. Raise EAP And RADIUS Timeouts — Set values that fit your slowest site and busiest roaming window.
2. Align Retry Counts — Keep retries high enough to ride out short loss, while avoiding a storm during outages.

MTU And Fragment Handling

Large TLS messages can lead to fragmented UDP. If an ACL or firewall drops fragments, the exchange stalls and ISE logs 12934. This shows up more on guest or remote segments with odd MTU settings.

1. Capture RADIUS On The Path — Confirm all TLS fragments arrive between NAS and ISE.
2. Allow UDP Fragments For AAA — Ensure security devices do not silently drop RADIUS fragments.
3. Standardize MTU Values — Keep MTU consistent across trunks, tunnels, and access VLANs.

Port Stability During Authentication

On wired, a flapping port can reset EAP mid-handshake. On wireless, aggressive roaming settings can interrupt the exchange on clients that don’t handle fast transitions well.

1. Check Link Flaps And Errors — Review interface counters for drops, CRC errors, or speed/duplex churn.
2. Test With A Simple SSID Profile — Temporarily disable extra WLAN features for a test user to isolate the EAP path.

ISE Checks That Keep PEAP Stable

12934 is usually a symptom, not an ISE fault, yet ISE settings can trigger client bailouts, most often around certificates. Start by matching the Live Log detail to the PEAP stage where the session ended. Then verify the EAP certificate, its chain, and consistency across PSNs.

Validate The EAP Server Certificate

If you renewed the EAP certificate recently, confirm the full chain is present and that the certificate includes the names clients expect. Mixed certificates across PSNs can create “works on one node, fails on another” behavior.

1. Confirm The Certificate Assigned To EAP — Ensure each PSN uses the intended EAP certificate, not a self-signed fallback.
2. Install Intermediate Certificates — Make sure ISE can present a complete chain during TLS.

Match The Inner Method End To End

Inside the PEAP tunnel, many sites run MSCHAPv2, while some run inner EAP-TLS. A mismatch between the endpoint profile and the ISE policy can end the session right after the tunnel forms.

1. Confirm The Inner Method In The Profile — Verify endpoints are set for the inner method you expect.
2. Validate The Identity Source Path — Check AD join health and user or machine lookup for the identity type in play.

Pair Logs With Captures

A capture is often the fastest truth source. If the server certificate arrives and the next client packet never comes, the endpoint likely rejected trust or crypto. If the client replies on the wire but ISE never receives it, the NAS or network path is the suspect.

1. Span The Client Port — Capture EAPOL to confirm the endpoint and NAS exchange is complete.
2. Capture UDP/1812 — Confirm EAP payloads pass intact from NAS to ISE with no gaps.

Hardening Steps So 12934 Stops Showing Up

Once the outage is over, a few guardrails keep 12934 from returning after a Windows update or a certificate rollover. Aim for consistency across endpoints, NAS devices, and ISE nodes.

1. Standardize Certificate Renewal — Renew early, publish the CA chain to endpoints, and keep SAN names stable across PSNs.
2. Deploy One Authoritative Profile — Use one wired and one wireless profile via GPO or MDM, then remove legacy profiles.
3. Track Driver Baselines — Push NIC driver versions that pass 802.1X reliably on your hardware fleet.
4. Keep AAA Timers Consistent — Set timeouts that work for the slowest site, then keep them aligned across the estate.

If the message “12934 supplicant stopped responding to ise during peap tunnel establishment” still appears after these steps, compare a known-good capture to a failing one. The difference is often one missing fragment, one name mismatch, or one endpoint policy change.

Cisco forum post on 12934 failure reason

Cisco forum post on 5411 and Windows GPO tuning

Microsoft thread on 802.1X with ISE error 12934

Send us your feedbackTell us what you thought about this post

Name * Email *

Your comment *

Quick check — what is …? *

Send feedback