Short answer: StrongSwan IKEv2 road-warriors (iOS, macOS, Windows) speak EAP-MSCHAPv2. OpenLDAP can only simple-bind (PAP). Those are not the same protocol, so StrongSwan cannot authenticate an LDAP password by itself. FreeRADIUS sits in the middle: it reads the user’s ntPassword from LDAP and finishes MS-CHAP. That is the supported design, not a leftover workaround.
What the VPN client actually sends
Native IKEv2 profiles on phones and laptops do not send a clear password to the gateway. They speak EAP-MSCHAPv2: a challenge-response. The gateway (or a RADIUS server behind it) must already know the NT hash, or be able to compute one, in order to check the response.
That rules out a direct LDAP bind from StrongSwan. A bind needs the plaintext password. The client never hands it over.
StrongSwan also has no plugin that does EAP-MSCHAPv2 against OpenLDAP. The road-warrior conn that uses the directory is rightauth=eap-radius (the eap-radius / charon plugin), not eap-mschapv2 with an LDAP URL.
What OpenLDAP can and cannot do
OpenLDAP is a directory. For password checks it can simple-bind: accept a DN and a plaintext password, or reject them. That is PAP. It cannot answer an MS-CHAP challenge.
So these do not work for phone IKEv2 against OpenLDAP:
- Pointing StrongSwan at LDAP and hoping it binds
- EAP-GTC or PAP on the client — the stock phone profile still sends MSCHAPv2
- Uncommenting FreeRADIUS
Auth-Type LDAPand expecting EAP to start working
The last one is a common false lead. FreeRADIUS’s own inner-tunnel example says, next to the commented Auth-Type LDAP block: that stanza means “check a plaintext password against the LDAP database,” and EAP will not work because EAP does not supply a plaintext password. The comment is explicit: LDAP servers are databases, not authentication servers. FreeRADIUS is the authentication server.
The working path
- Client EAP-MSCHAPv2 → StrongSwan (
rightauth=eap-radius) - StrongSwan RADIUS plugin → FreeRADIUS
- FreeRADIUS LDAP module searches the user, maps
ntPassword→control:NT-Password, and completes MS-CHAP
On the LDAP side you need an NT hash (ntPassword or equivalent), not only userPassword. Samba / mail schemas often already store that hash when the same password is used for other services. An authorization attribute (we use mailActivated) is optional but useful so disabled accounts cannot dial in.
Site-to-site IPsec is a different problem. Those conns are usually PSK or certificates and never touch RADIUS. A road-warrior conn that does not use the directory can stay on local eap-mschapv2 secrets.
Approaches that look simpler and fail
| Approach | Why it fails if the VPN password is the LDAP password |
|---|---|
| StrongSwan LDAP bind / EAP-GTC / PAP | The client sends MSCHAPv2, not a clear password |
| Authelia, Keycloak, or OIDC in front of IKEv2 | Native VPN clients do not speak OIDC |
| Drop RADIUS, keep MSCHAPv2 hashes only on the gateway | Duplicates secrets; the VPN drifts from the directory |
Auth-Type LDAP inside FreeRADIUS |
Needs plaintext; EAP does not provide it |
SSO in front of the web admin sites is the right tool for browsers. It is the wrong tool for IKEv2.
When you can retire FreeRADIUS
You can drop the RADIUS hop if you drop “type your directory password in the VPN profile”:
- Client certificates (
rightauth=pubkeyor EAP-TLS) - WireGuard (or similar) device keys
- Local EAP-MSCHAPv2 secrets, if you accept that the VPN password is not the directory password
Those are UX and enrollment changes, not a missing StrongSwan switch. Until you accept one of them, keep FreeRADIUS.
Why this stays published
We hit this on a homelab IKEv2 setup that shares mail passwords with OpenLDAP, and the same protocol mismatch shows up in production stacks. The useful search result is not “delete RADIUS” and not “bind LDAP from charon”. It is: EAP-MSCHAPv2 + OpenLDAP needs an authentication server that can read NT hashes. FreeRADIUS is that server.
本文由 HoHo 與 AI 協作整理，最後更新於 2026 年 10 月 1 日。