[Swan] OSX Connectivity debugging
Mr. Jan Walter
hopping_hol at yahoo.com
Wed Jan 23 23:14:33 UTC 2019
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 ip18.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=MODP1024Jan 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=MODP1024Jan 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.netJan 23 23:03:33 ip-10-0-0-194 pluto[25632]: "ikev2-cp"[2] 11.11.11.11 #2: No matching subjectAltName foundJan 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.11Jan 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 connectionJan 23 23:03:33 ip-10-0-0-194 pluto[25632]: "ikev2-cp"[2] 11.11.11.11 #2: No matching subjectAltName foundJan 23 23:03:33 ip-10-0-0-194 pluto[25632]: "ikev2-cp"[2] 11.11.11.11 #2: No matching subjectAltName foundJan 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 foundJan 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_FAILEDJan 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 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 # # 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
On Wednesday, January 23, 2019, 1:38:42 PM EST, Paul Wouters <paul at nohats.ca> wrote:
On Tue, 22 Jan 2019, Mr. Jan Walter wrote:
> Generated cert with now-changed public IP address for client. Does the --extSAN ip:xx.xx.xx.xx need to the public ip address of the client's
> NAT gateway or the internal IPv4 address on the LAN of the client?
The SAN should be the IP that others connect to. So the public/elastic
one.
> How does this connection use case address roaming clients?
Client certificates should not use IP based SAN's. They can use a @fqdn
SAN or just stick with sending the Distinguished Name (DN) using leftif=%fromcert
> matching remote ESP/AH proposals): 1:ESP:ENCR=AES_GCM_C_256;INTEG=NONE;DH=NONE;ESN=DISABLED
> 2:ESP:ENCR=AES_GCM_C_128;INTEG=NONE;DH=NONE;ESN=DISABLED 3:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_512_256;DH=NONE;ESN=DISABLED
> 4:ESP:ENCR=AES_CBC_128;INTEG=HMAC_SHA2_512_256;DH=NONE;ESN=DISABLED
> Jan 22 17:20:06 ip-10-0-0-194 pluto[19256]: "ikev2-cp"[2] xx.xx.xx.xx #2: no local proposal matches remote proposals
> 1:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;ESN=DISABLED 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
> Jan 22 17:20:06 ip-10-0-0-194 pluto[19256]: "ikev2-cp"[2] xx.xx.xx.xx #2: IKE_AUTH responder matching remote ESP/AH proposals failed, responder
> SA processing returned STF_FAIL+v2N_NO_PROPOSAL_CHOSEN
This is a phase2/esp mismatch. Looks like DH groups might not match. Try
changing the pfs= setting?
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20190123/6bf6e6c0/attachment-0001.html>
More information about the Swan
mailing list