Skip to content

Instantly share code, notes, and snippets.

@doriantaylor
Last active September 30, 2022 18:42
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
Star You must be signed in to star a gist
Save doriantaylor/1ecfc2cd04630f70b471abd831b11162 to your computer and use it in GitHub Desktop.
IKEv2 stock mac initiator and strongswan responder

Fewer things are more of a pain in the ass to get working than IPSec and the built-in Mac client is no exception. As such I decided to jot down some contemporaneous notes so I didn't forget how much of a pain in the ass it was.

First off, in the networking control panel, authentication by Certificate actually means auth = eap-tls in Strongswan. If you want ordinary pubkey authentication, you select authentication None, and then put your certificate in there. I know, it makes no sense to call an X.509 certificate "not authentication", but that's where it goes. Also—and this is the part that kept me up until 4am—you need something in the preshared key field (can be foo, doesn't matter) even if the radio button is set to the certificate. If you don't do this, the Strongswan side will be happy and complete the connection but on the Mac side you will get hours of "unknown error".

Okay, now the certificates themselves: probably the most important thing is that there is a subjectAltName field in both the client and server certificates that matches its respective CN (this shouldn't be necessary but it is). You can have more than one subjectAltName, but you must have one that matches the CN. Also, for the server, the CN (ostensibly? I wouldn't chance it?) has to match the responder's hostname and there should probably be a DNS PTR record for it too.

That may be cargo culting but again I wouldn't chance it; VPN clients are notoriously opaque about why they ultimately choose not to connect.

Also worth noting that the Mac client has a relatively narrow list of encryption proposals, so you can tidy up the negotiation if you prune those on the Strongswan side.

So, both the remote and the local identifiers in the Mac control panel the have to be the CN-plus-subjectAltName in their respective certificates. The client's certificate can have either an email address or a hostname as its CN (or presumably arbitrary text but that's not very useful). Assume these identifiers are case-sensitive, and you might want to check whatever thing you're using as a certificate authority grants the appropriate roles.

I use TinyCA2 and I had to hack the underlying OpenSSL config a bit to ensure server certificates (CN is a hostname rather than an email address) also had client capability.

Another note about the certificates is I use a PKCS12 combined key/cert for clients and ordinary separate PEM files for servers.

Finally, there is the matter of the CA certificate itself: it has to be trusted in Keychain Access. I found I had to put it in the System keychain rather than login (even though the client cert appears to be fine there). Expect to plug in your password half a dozen times, because Keychain. You may also only need to enable trust settings for the CA certificate for EAP and IPSec, but I just ran the board on it because I (ironically) don't trust it. Or rather, I trust the CA I made and control more than I trust Apple to communicate my preferences properly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment