EAP through a VPN gateway: who terminates the method

Helpdesk tickets describe a failed VPN login and a RADIUS policy that demands a stronger method as if they were the same problem, and they are not. The gateway either accepts a credential and forwards it, or it carries an EAP conversation between the client and the authentication server. Which of those happens decides whether a server-side change can fix anything at all. Read the exchange before you edit the server group.

Two authentication paths that look alike in a log

In the first path, the VPN gateway collects a username and password and sends a RADIUS Access-Request with a password attribute. The authentication server compares it with its credential store and answers accept or reject. The client never runs an EAP method, because nothing asked it to.

In the second path, the client and the authentication server run the EAP method end to end, and the gateway forwards EAP-Message attributes between them. The gateway still terminates the outer RADIUS conversation, but the method logic lives at the two endpoints.

Both paths produce a line in a log that says authentication failed. Only the second one can be affected by which EAP method the server prefers, and only the first can be affected by how the gateway reads the password. Treating them as interchangeable is how teams spend a day changing server groups for a client that was never going to speak PEAP.

Where the method actually runs

RFC 3579 defines the pass-through arrangement: the NAS carries EAP packets in RADIUS attributes and does not need method-specific code for every EAP type. That is why a gateway can support PEAP and EAP-TLS without implementing either one.

A gateway that submits a password is not carrying PEAP, even if the backend would accept PEAP from another client. Enabling PEAP in the server policy does not add a method to a client that never offered one.

PPP authentication settings belong to the PPP service. They do not silently reconfigure every IPsec or legacy XAuth path that uses the same AAA server, so a change that works for one access type can leave the other untouched.

What the NAS must support

Pass-through shifts the requirement from method code to carrier support. The gateway must be able to carry EAP over its VPN protocol, and the RADIUS client on it must be able to send and receive EAP-Message attributes of the sizes involved.

For IKEv2, EAP is part of a defined authentication flow, and the server identity and trust checks come from that flow. A PEAP label borrowed from an 802.1X deployment does not transfer automatically, because the negotiation around it differs.

The client side has requirements too. It must be configured for the method, trust the server certificate the method presents, and have credentials the method can use. A certificate-based method with no client certificate fails before RADIUS sees anything, which is a provisioning problem rather than a server policy problem.

Read one attempt before changing policy

Capture a single approved attempt at the gateway and at the authentication server. Look for EAP-Message attributes in the RADIUS request. Their presence tells you the pass-through path is in use; their absence points at a credential exchange.

On a Linux gateway, a capture on the RADIUS port shows which attributes are on the wire:

sudo tcpdump -ni any -X 'udp port 1812' -c 20

Then compare the rejection point. A failure at the gateway before any RADIUS packet means the client and gateway disagreed on the method. A RADIUS reject carrying EAP attributes means the endpoints ran the method and one of them refused the result.

Plan the migration as one end-to-end change

Changing the method means changing the client configuration, the gateway's carrier support, the server's method policy, and the credential store together. Do them in that order and keep a working path until the new one is proven. A server-side change alone is a guess, and it usually breaks the clients that were working. Stage the change on one test identity before touching the group.

Record the combination that works: VPN protocol, EAP carrier, peer method, server method, credential type, and server identity check.

Keep administrative login AAA separate from VPN authentication unless the task explicitly includes both. A change intended for remote access should not remove your ability to manage the device that terminates it.