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
#[email protected]
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
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
