[Swan] OSX Connectivity debugging

Mr. Jan Walter hopping_hol at yahoo.com
Wed Jan 30 18:29:36 UTC 2019

 Actually, the issue turned out to be that the "local id" in the OSX VPN config had to be the CN on the client certificate. Yeah, obvious, right?
Anyways, I'll be writing up how to make OSX and Windows clients connect to an libreswan server, with a client subnet and NAT into the network the server is on. I have it all working on both platforms right now, and just need to work through some of the issues pam introduces. At the end of it all, one should be able to issue client certificates to groups of users, they use their own credentials through pam (possibly hooked into AD or other LDAP even) and connect into a network. Revoke a cert, a group of users goes away.
    On Wednesday, January 30, 2019, 3:53:27 AM EST, Kostya Vasilyev <kman at fastmail.com> wrote:  
 #yiv1692086773 p.yiv1692086773MsoNormal, #yiv1692086773 p.yiv1692086773MsoNoSpacing{margin:0;}
On Mon, Jan 28, 2019, at 11:04 PM, Mr. Jan Walter wrote:

Paul & list:

Okay, so last try on this, it's pretty frustrating. I made the changes in the ipsec.conf file per your suggestions, and of course, it gets farther.

OSX Log Facility Output:

[ ... ]
2019-01-28 14:51:16.609829-0500 0x168210   Default     0x0                  66177  0    neagent: (Security) [com.apple.securityd:SecError] Trust evaluate failure: [leaf SSLHostname]
2019-01-28 14:51:16.609832-0500 0x168210   Error       0x0                  66177  0    neagent: (NetworkExtension) [com.apple.networkextension:] Certificate evaluation error = kSecTrustResultRecoverableTrustFailure
2019-01-28 14:51:16.609840-0500 0x168210   Error       0x0                  66177  0    neagent: (NetworkExtension) [com.apple.networkextension:] Certificate is not trusted
2019-01-28 14:51:16.609844-0500 0x168210   Error       0x0                  66177  0    neagent: (NetworkExtension) [com.apple.networkextension:] Certificate authentication data could not be verified
2019-01-28 14:51:16.609847-0500 0x168210   Error       0x0                  66177  0    neagent: (NetworkExtension) [com.apple.networkextension:] Failed to process IKE Auth packet (connect)

Ipsec barf output:

[ ... ]
Jan 28 19:51:16 ip-10-0-0-194 pluto[2898]: "ikev2-cp"[1] #15: STATE_PARENT_R1: received v2I1, sent v2R1 {auth=IKEv2 cipher=AES_CBC_256 integ=HMAC_SHA2_256_128 prf=HMAC_SHA2_256 group=MODP2048}
Jan 28 19:51:16 ip-10-0-0-194 pluto[2898]: "ikev2-cp"[1] #15: certificate verified OK: O=Client1,CN=client1.zzz.net
Jan 28 19:51:16 ip-10-0-0-194 pluto[2898]: "ikev2-cp"[1] #15: No matching subjectAltName found
Jan 28 19:51:16 ip-10-0-0-194 pluto[2898]: "ikev2-cp"[1] #15: No matching subjectAltName found
Jan 28 19:51:16 ip-10-0-0-194 pluto[2898]: "ikev2-cp"[1] #15: IKEv2 mode peer ID is ID_FQDN: '@client1.zzz.net'
Jan 28 19:51:16 ip-10-0-0-194 pluto[2898]: "ikev2-cp"[1] #15: Authenticated using RSA
Jan 28 19:51:16 ip-10-0-0-194 pluto[2898]: "ikev2-cp"[1] #15: proposal 1:ESP:SPI=08fdfa42;ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;ESN=DISABLED chosen from remote proposals 1:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;ESN=DISABLED[first-match] 2:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;ESN=DISABLED 3:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;ESN=DISABLED 4:ESP:ENCR=AES_CBC_128;INTEG=HMAC_SHA1_96;ESN=DISABLED 5:ESP:ENCR=3DES;INTEG=HMAC_SHA1_96;ESN=DISABLED

Looks like you've got certificate validation errors on both sides, and libeswan proceeds anyway but OS X doesn't (and so overall it fails).

Libreswan error messages are more specific too - looks like (?) it's expecting to find client1.zzz.net in the client cert's subjectAltName but your certificate has none.

On the OS X side

 - I don't use this OS but recently had a lot of trouble getting a Mikrotik client to connect using certificate auth. Got it to work eventually, this forum post has the details:


- In libreswan config you have leftid=@zzz.net - but its leftcert has vv.zzz.net (and IP's) in its subjectAltName and does not have zz.net which is the id. Not sure if this matters but it is an obvious mismatch.

Something I'd try personally is to use PSK auth as a test - just to rule out any other causes (other than certificate errors) and if that works try to put back certificate auth.
-- K

Commands to make ca, server, client cert. server cert exported and imported to ipsec. CA, server, client certificates and keys exported using pk12util, and imported into OSX keystore. Tried "login" keystore and "system" keystore, CA cert marked "trust always", and each subsequent attempt marked server, and then client cert as "trust always".

The error message on the OSX Mojave side is the same, so there is something missing in the trust chain I don't see.

certutil -S -x -n "ca.zzz.net" -s "O=zzzz team CA,CN=ca.zzz.net" -k rsa -g 4096 -v 12 -d sql:${HOME}/ca -t "CT,," -2
certutil -S -c "ca.zzz.net" -n "vv.zzz.net" -s "O=VV Server Cert,CN=vv.zzz.net" -k rsa -v 12 -d sql:${HOME}/ca -t ",," -1 -6 --extSAN 'dns:vv.zzz.net,ip:,ip:'
certutil -S -c "ca.zzz.net" -n "client1.zzz.net" -s "O=Client1,CN=client1.zzz.net" -k rsa -v 12 -d sql:${HOME}/ca -t ",," -1 -6 -8 "client1.zzz.net"


onn ikev2-cp
    # The server's actual IP goes here - not elastic IPs
    # try to structure something to accept this offer: IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_384_192;PRF=HMAC_SHA2_384;DH=MODP1024
    # Clients
    # your addresspool to use - you might need NAT rules if providing full internet to clients
    # optional rightid with restrictions
    # rightid="C=CA, L=Toronto, O=Libreswan Project, OU=*, CN=*, E=*"
    # connection configuration
    # DNS servers for clients to use
    # Versions up to 3.22 used modecfgdns1 and modecfgdns2
    # recommended dpd/liveness to cleanup vanished clients
    # ikev2 fragmentation support requires libreswan 3.14 or newer
    # optional PAM username verification (eg to implement bandwidth quota
    # pam-authorize=yes


Swan mailing list
Swan at lists.libreswan.org

Swan mailing list
Swan at lists.libreswan.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20190130/e32da67d/attachment.html>

More information about the Swan mailing list