Why RADIUS Sees an IP Address Instead of the VPN Username

A Windows IKEv2 client connects, and the RADIUS request arrives with an address where the account name should be. Nothing has failed yet, which is the confusing part: the gateway is reporting the identity the client presented at the IKE layer. The user name your backend wants may come from a separate EAP exchange that has not happened. Decide who asks for it before changing the account.

Two identities travel in one connection

Two names can appear in one connection. The IKE identity identifies the peer during tunnel setup, and the eap-radius plugin initially copies it into RADIUS User-Name. The EAP identity is a different value, used for user authentication, and it may never be sent if nobody asks for it.

That is why the RADIUS log can show an address while the account exists and the password is correct. The backend is being asked about the wrong layer. The RADIUS attribute is only the transport for whichever name was chosen.

Ask the gateway to request an EAP identity

One supported arrangement has the gateway request the EAP identity before handing authentication to RADIUS. In the remote-authentication section of the connection, set the method to eap-radius and ask for the EAP identity explicitly. The fragment below belongs inside an existing connection block, not in a file of its own. Confirm the connection and the configuration backend before copying syntax from another deployment.

remote {
    auth = eap-radius
    eap_id = %any
}

With that in place, the backend receives the identity the client supplies in the EAP exchange rather than the IKE address. Nothing else about the connection changes.

Or let RADIUS start the EAP exchange

The other arrangement puts the first move on the RADIUS side. The plugin can send an EAP-Start indication instead of waiting for an initial identity response, which lets the server drive the exchange. That is plugin-level configuration, so it affects every connection using the plugin.

charon {
    plugins {
        eap-radius {
            eap_start = yes
        }
    }
}

Pick one arrangement with the RADIUS operator rather than enabling both and hoping. They describe different workflows, and a server that expects to initiate will not necessarily handle a gateway that starts the conversation. The plugin documentation describes both, including which identity each step carries.

Follow one attempt through both logs

Correlate a single attempt across both logs. Watch the IKE identity, then whether an EAP-Identity exchange occurs, then what name the authentication step receives. A backend that rejects the address before the EAP exchange can stop the process before your intended identity is ever seen.

journalctl -u strongswan -f

Keep the exact username format the identity system expects, domain prefix included. Never invent an account from an address-shaped value, and never switch authentication off to satisfy a policy rule. An EAP identity is an asserted name, and the method still has to prove it. Write the resulting name into the test record so the next attempt starts from a known state.

If the corrected flow reaches the right account and is still rejected, the next evidence is the EAP method and the backend policy, not the identity. Repeating a password reset cannot repair a value chosen at an earlier protocol layer.