Recently I upgraded one of the gateways that does this to Stable-13 and, as part of that, StrongSwan went from 5.9.5 to 5.9.6. I also transitioned to using vici from stroke (yeah, I know, been using this for a while and probably should have long ago) and on -12 this seems to work when back-checked -- that is, I can boot the gateway using 12 on the same config files, but with 5.9.5, set to use vici in the startup script and everything works as expected thus apparently my conversion of the "older way" appears to be correct.
As an aside I am also at present chasing what looks like a new bogon out of Android 13 that, when the Windows machine is behind an Android tether, breaks routing entirely -- but I don't think that's related to the below because when I put the gateway back on -12 its still broken; thus I doubt that StrongSwan's fault. I'm chasing that separately.
What I am running into that I've traced to StrongSwan, however, is that suddenly the current StrongSwan code is very unhappy about the certificates I've been using. They're issued by my local CA and now StrongSwan is claiming that when using EAP-TLS it cannot validate them, shows the CN as the failed identifier and thus the connections fail. If I set the client on Windows to allow me to change the user parameter and enter the email address in the certificate (which IS in the SAN field - the "CN" of these certs is the full name of the person, not an email address) then the connection succeeds.
The swanctl.conf file segment for Windows is:
windows {
pools = remote_pool
local {
auth = pubkey
certs = ipgw-rsa.denninger.net.crt
id = ipgw.denninger.net
}
remote {
auth = eap-tls
cacerts = CudaSystems.Int.crt
eap_id = %any
}
children {
windows {
local_ts = 0.0.0.0/0
}
}
}
The error looks like the StrongSwan server is insisting on using the CN,
not looking at the SAN field of the presented certificate at all and, as
far as I can tell, its not validating that it was actually signed by the
intermediate certificate even though it does it have it and does know
that's the correct certificate to check it against, as it does request
it and in fact has it in the ca directory (and a status request does
show it.)
Using the "stroke" interface does not impact this; it appears to be something changed between 5.9.5 and 5.9.6 and the release notes imply this is likely the cause:
* The client identity (e.g. the IKE or EAP identity for EAP-TLS) is again enforced by libtls.And, it appears, Windows is insisting on using the CN when presenting the identity (instead of the field(s) in the SAN) unless you set the option on the VPN profile to allow an override -- and then you have to hand-key it on each connection. I don't believe there is any way to tell Windows to use the SAN identity or identities on its own.
I'm not sure if Windows did this to me and the 5.9.6 upgrade exposed it or what, but it certainly is rather annoying and, at present, it appears the only "fix" is to have the user enter their email address on each connection via Windows by telling to let the user change their identity when connecting.
-- Karl Denninger k...@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/
smime.p7s
Description: S/MIME Cryptographic Signature
