strongSwan EAP: IKE Identity vs the Expected AAA Name

EAP authentication over IKEv2 can ask a client to validate two different server names in one connection. The gateway that terminates IKE presents one identity, and the EAP backend that terminates the inner TLS exchange may present another. In strongSwan those live in different configuration blocks, and putting a name in the wrong one produces a failure that looks like a certificate problem. Reading which validation failed is what tells you which block to edit.

One Connection, Two Server Identities

The first identity belongs to the IKE exchange. The client dials an address and expects the peer to prove a particular identity, usually the name in the gateway certificate.

The second belongs to EAP. With PEAP or TTLS, the client builds a TLS tunnel to the authentication server inside the IKE SA, and that inner server presents its own certificate. When the backend is a separate host, its name differs from the gateway's. A client that checks only the first name accepts whatever the second one asserts. A client configured with one name in both places fails as soon as the two genuinely differ.

Both names come from the operator's configuration rather than from whichever certificate makes the error go away. Asking the operator for the deployment details is faster than guessing at two hostnames.

Which Field Belongs to Which Layer

In swanctl, the address and the IKE identity are separate settings, and the EAP identity is a third.

The remote address selects where packets go, and the remote identity states what the peer must prove. The EAP expectation is written under the local block, because it describes this client's EAP exchange rather than the peer's IKE behaviour. That placement is the part people misread. The name sits in the client's configuration while describing a server, which is exactly why it looks misplaced.

connections {
    office {
        remote_addrs = vpn.example.com
        local {
            auth = eap-peap
            aaa_id = auth.example.com
        }
        remote {
            auth = pubkey
            id = vpn.example.com
        }
    }
}

That fragment is not a complete connection; trust material, credentials and child policies still have to be present. Copying it verbatim into a working file would replace settings you still need.

Why aaa_id Lives Under local

The local block describes what this end does during authentication, including the method it will use and the identity it expects the other end to present for that method. Nothing in it claims the AAA server runs on the same machine.

The default makes the trap sharper. When no explicit value is set, the expected AAA identity follows the remote identity, so a single-name deployment works and hides the distinction. An explicit value matters only when the EAP deployment really does terminate somewhere else. Setting it to a different name without that reason creates a failure the operator cannot reproduce. Read the deployment before inventing a second name.

Keep the value identical to what the backend certificate actually asserts, including the form of the name. A trailing dot or a wildcard that does not cover the host is enough to fail the check.

Frontends That Cannot Express the Split

A NetworkManager profile is not the same configuration interface as swanctl. The plugin behind it exposes a narrower set of identity controls, and which ones exist depends on the installed version.

That matters when the deployment genuinely needs two names. A field labelled server identity may configure one layer and not the other, so a profile can look correct and still fail the inner check. Check what the installed plugin supports before assuming the profile can express the arrangement. If it cannot, the choice belongs with the operator: a different provisioning path, or a corrected server identity design. Weakening PEAP or accepting any name changes the authentication policy instead of fixing it.

The alternative is not something to invent on the client. Ask for the supported arrangement in writing, then keep that answer with the profile.

Tell an Identity Mismatch From an Expired Certificate

A name mismatch and an expired certificate are different failures, and the log distinguishes them. Read the message before deciding which field to change.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 50 --no-pager

Setting the intended AAA identity does not renew a certificate or establish trust in its issuer, and renewing a certificate does not correct a wrong expected name. Read which validation failed before editing another identity field. Then reload the configuration and confirm the loaded connection shows the value you set, since an edited file that was never loaded changes nothing. Write both names and their layers into the deployment notes.