[Swan] OSX Connectivity debugging

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.
Cheers,
Jan
    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] 11.11.11.11 #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] 11.11.11.11 #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] 11.11.11.11 #15: No matching subjectAltName found
Jan 28 19:51:16 ip-10-0-0-194 pluto[2898]: "ikev2-cp"[1] 11.11.11.11 #15: No matching subjectAltName found
Jan 28 19:51:16 ip-10-0-0-194 pluto[2898]: "ikev2-cp"[1] 11.11.11.11 #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] 11.11.11.11 #15: Authenticated using RSA
Jan 28 19:51:16 ip-10-0-0-194 pluto[2898]: "ikev2-cp"[1] 11.11.11.11 #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:

https://forum.mikrotik.com/viewtopic.php?f=2&t=31563&p=711471#p711471

- 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:22.22.22.22,ip:10.0.0.194'
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"

ipsec.conf:

onn ikev2-cp
    authby=rsasig
    ikev2=insist
    cisco-unity=yes
    # The server's actual IP goes here - not elastic IPs
    left=10.0.0.194
    leftsourceip=22.22.22.22
    leftcert=vv.zzz.net
    leftid=@zzz.net
    leftsendcert=always
    #leftsubnet=0.0.0.0/0
    leftrsasigkey=%cert
    # try to structure something to accept this offer: IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_384_192;PRF=HMAC_SHA2_384;DH=MODP1024
    ike=aes256-sha2_512;modp2048,aes128-sha2_512;modp2048,aes256-sha1;modp2048,aes128-sha1;modp2048,aes-sha2;modp2048,aes256-sha1;modp1024,aes128-sha1;modp1024,aes-sha2;modp1024
    #esp=aes_gcm256-null,aes_gcm128-null,aes256-sha2_512,aes128-sha2_512
    # Clients
    right=%any
    # your addresspool to use - you might need NAT rules if providing full internet to clients
    rightaddresspool=10.0.0.240-10.0.0.250
    # optional rightid with restrictions
    # rightid="C=CA, L=Toronto, O=Libreswan Project, OU=*, CN=*, E=*"
    rightca=%same
    rightrsasigkey=%cert
    rightid=%fromcert
    #
    # connection configuration
    # DNS servers for clients to use
    #modecfgdns=8.8.8.8,193.100.157.123
    # Versions up to 3.22 used modecfgdns1 and modecfgdns2
    #modecfgdns1=8.8.8.8
    #modecfgdns2=193.110.157.123
    narrowing=yes
    # recommended dpd/liveness to cleanup vanished clients
    dpddelay=30
    dpdtimeout=120
    dpdaction=clear
    auto=add
    rekey=no
    #ms-dh-fallback=yes
    #msdh-downgrade=yes
    ms-dh-downgrade=yes
    leftxauthserver=yes
    rightxauthclient=yes
    leftmodecfgserver=yes
    rightmodecfgclient=yes
    # ikev2 fragmentation support requires libreswan 3.14 or newer
    fragmentation=yes
    # optional PAM username verification (eg to implement bandwidth quota
    # pam-authorize=yes

Cheers,

Jan
_______________________________________________
Swan mailing list
Swan at lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan

_______________________________________________
Swan mailing list
Swan at lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan

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