[Swan] OSX Connectivity debugging

Thu Jan 24 01:59:27 UTC 2019

On Wed, 23 Jan 2019, Mr. Jan Walter wrote:

> I think that one is out of date. Here is the latest log. Error on OSX is "authentication failed". It really looks like it hates that there is no AltName in the client cert, which is pretty weird.

> 11.11.11.11 is the client public ip
> 18.22.22.22 is the server Elastic IP
> 
> Jan 23 23:03:33 ip-10-0-0-194 pluto[25632]: "ikev2-cp"[2] 11.11.11.11: constructed local IKE proposals for ikev2-cp (IKE SA responder matching remote proposals):
> 1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_512;INTEG=HMAC_SHA2_512_256;DH=MODP2048 2:IKE:ENCR=AES_CBC_128;PRF=HMAC_SHA2_512;INTEG=HMAC_SHA2_512_256;DH=MODP2048
> 3:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA1;INTEG=HMAC_SHA1_96;DH=MODP2048 4:IKE:ENCR=AES_CBC_128;PRF=HMAC_SHA1;INTEG=HMAC_SHA1_96;DH=MODP2048
> 5:IKE:ENCR=AES_CBC_256,AES_CBC_128;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_256_128;DH=MODP2048 6:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA1;INTEG=HMAC_SHA1_96;DH=MODP1024
> 7:IKE:ENCR=AES_CBC_128;PRF=HMAC_SHA1;INTEG=HMAC_SHA1_96;DH=MODP1024 8:IKE:ENCR=AES_CBC_256,AES_CBC_128;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_256_128;DH=MODP1024
> Jan 23 23:03:33 ip-10-0-0-194 pluto[25632]: "ikev2-cp"[2] 11.11.11.11 #2: proposal 1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_256_128;DH=MODP2048 chosen from remote proposals
> 1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_256_128;DH=MODP2048[first-match] 2:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_256_128;DH=ECP_256
> 3:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_256_128;DH=MODP1536 4:IKE:ENCR=AES_CBC_128;PRF=HMAC_SHA1;INTEG=HMAC_SHA1_96;DH=MODP1024 5:IKE:ENCR=3DES;PRF=HMAC_SHA1;INTEG=HMAC_SHA1_96;DH=MODP1024
> Jan 23 23:03:33 ip-10-0-0-194 pluto[25632]: "ikev2-cp"[2] 11.11.11.11 #2: 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 23 23:03:33 ip-10-0-0-194 pluto[25632]: "ikev2-cp"[2] 11.11.11.11 #2: certificate verified OK: O=Client2,CN=client2.zzz.net
> Jan 23 23:03:33 ip-10-0-0-194 pluto[25632]: "ikev2-cp"[2] 11.11.11.11 #2: No matching subjectAltName found
> Jan 23 23:03:33 ip-10-0-0-194 pluto[25632]: "ikev2-cp"[2] 11.11.11.11 #2: certificate does not contain ID_IP subjectAltName=11.11.11.11
> Jan 23 23:03:33 ip-10-0-0-194 pluto[25632]: "ikev2-cp"[2] 11.11.11.11 #2: Peer public key SubjectAltName does not match peer ID for this connection
> Jan 23 23:03:33 ip-10-0-0-194 pluto[25632]: "ikev2-cp"[2] 11.11.11.11 #2: No matching subjectAltName found
> Jan 23 23:03:33 ip-10-0-0-194 pluto[25632]: "ikev2-cp"[2] 11.11.11.11 #2: No matching subjectAltName found
> Jan 23 23:03:33 ip-10-0-0-194 pluto[25632]: "ikev2-cp"[2] 11.11.11.11 #2: Peer ID '10.4.9.62' mismatched on first found connection and no better connection found

The client's pre-NAT IP is used as ID. It should really use a SAN based
ID or the DN as ID. While libreswan continues since right=%any, you are
leaking the pre-NAT IP ranges from your clients, which you should not
do.

> Jan 23 23:03:33 ip-10-0-0-194 pluto[25632]: "ikev2-cp"[2] 11.11.11.11 #2: responding to IKE_AUTH message (ID 1) from 11.11.11.11:10700 with encrypted notification AUTHENTICATION_FAILED

It seems we failed to authenticate anyway?

> Jan 23 23:05:35 ip-10-0-0-194 pluto[25632]: "ikev2-cp"[2] 11.11.11.11 #3: proposal 1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_256_128;DH=MODP2048 chosen from remote proposals
> 1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_256_128;DH=MODP2048[first-match] 2:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_256_128;DH=ECP_256
> 3:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_256_128;DH=MODP1536 4:IKE:ENCR=AES_CBC_128;PRF=HMAC_SHA1;INTEG=HMAC_SHA1_96;DH=MODP1024 5:IKE:ENCR=3DES;PRF=HMAC_SHA1;INTEG=HM    leftsubnet=0.0.0.0/0
> 
> conn 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=18.22.22.22

Do not use leftsourceip= if your leftsubnet is 0.0.0.0/0 anyway?

>     leftcert=vv.zzz.net
>     #leftid=@vv.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

add 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

Paul