[Swan] OSX Connectivity debugging
Paul Wouters
paul at nohats.ca
Tue Jan 22 20:54:18 UTC 2019
On Tue, 22 Jan 2019, Mr. Jan Walter wrote:
> One more bit of data here is that libreswan thinks the client is connection and that it's up.
Yes, which means the OSX client is not happy with the AUTH from the
server, which is why I asked about the certificate on the server having
a SAN in the certificate that matches your leftid= line.
Paul
> On Tuesday, January 22, 2019, 2:23:00 PM EST, Mr. Jan Walter <hopping_hol at yahoo.com> wrote:
>
>
> NVM on the roaming clients question, the server cert needs the extended data.
>
> I generated a new vpn server cert with both the dns name, the local, and public ip address in the Alt data.
>
> I removed the esn= line from ipsec.conf, and now it gets this far, but the osx client states "authentication failed":
>
> "ikev2-cp"[1] xx.xx.xx.xx: 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 22 19:18:37 ip-10-0-0-194 pluto[21084]: "ikev2-cp"[1] xx.xx.xx.xx #1: 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 22 19:18:37 ip-10-0-0-194 pluto[21084]: "ikev2-cp"[1] xx.xx.xx.xx #1: 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 22 19:18:37 ip-10-0-0-194 pluto[21084]: "ikev2-cp"[1] xx.xx.xx.xx #1: certificate verified OK: O=Client3,CN=client3.zzz.net
> Jan 22 19:18:37 ip-10-0-0-194 pluto[21084]: "ikev2-cp"[1] xx.xx.xx.xx #1: No matching subjectAltName found
> Jan 22 19:18:37 ip-10-0-0-194 pluto[21084]: "ikev2-cp"[1] xx.xx.xx.xx #1: No matching subjectAltName found
> Jan 22 19:18:37 ip-10-0-0-194 pluto[21084]: "ikev2-cp"[1] xx.xx.xx.xx #1: IKEv2 mode peer ID is ID_IPV4_ADDR: '192.168.1.166'
> Jan 22 19:18:37 ip-10-0-0-194 pluto[21084]: "ikev2-cp"[1] xx.xx.xx.xx #1: Authenticated using RSA
> Jan 22 19:18:37 ip-10-0-0-194 pluto[21084]: "ikev2-cp"[1] xx.xx.xx.xx: constructed local ESP/AH proposals for ikev2-cp (IKE_AUTH
> responder matching remote ESP/AH proposals): 1:ESP:ENCR=AES_GCM_C_256;INTEG=NONE;ESN=DISABLED
> 2:ESP:ENCR=AES_GCM_C_128;INTEG=NONE;ESN=DISABLED 3:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_512_256,HMAC_SHA2_256_128;ESN=DISABLED
> 4:ESP:ENCR=AES_CBC_128;INTEG=HMAC_SHA2_512_256,HMAC_SHA2_256_128;ESN=DISABLED
> 5:ESP:ENCR=AES_CBC_128;INTEG=HMAC_SHA1_96;ESN=DISABLED (default)
> Jan 22 19:18:37 ip-10-0-0-194 pluto[21084]: "ikev2-cp"[1] xx.xx.xx.xx #1: proposal
> 1:ESP:SPI=08cd4a2d;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
> Jan 22 19:18:37 ip-10-0-0-194 pluto[21084]: "ikev2-cp"[1] xx.xx.xx.xx #1: received unsupported NOTIFY v2N_NON_FIRST_FRAGMENTS_ALSO
> Jan 22 19:18:37 ip-10-0-0-194 pluto[21084]: "ikev2-cp"[1] xx.xx.xx.xx #2: negotiated connection [0.0.0.0-255.255.255.255:0-65535
> 0] -> [10.0.0.240-10.0.0.240:0-65535 0]
> Jan 22 19:18:37 ip-10-0-0-194 pluto[21084]: "ikev2-cp"[1] xx.xx.xx.xx #2: STATE_V2_IPSEC_R: IPsec SA established tunnel mode
> {ESP/NAT=>0x08cd4a2d <0xeab6e0db xfrm=AES_CBC_256-HMAC_SHA2_256_128 NATOA=none NATD=xx.xx.xx.xx:4500 DPD=active}
>
>
> On Tuesday, January 22, 2019, 12:28:01 PM EST, Mr. Jan Walter <hopping_hol at yahoo.com> wrote:
>
>
> Thank you!
>
> Added modp2048 for every modp1024 line:
>
> ike=aes256-sha2_512;modp2048,aes128-sha2_512;modp2048,aes256-sha1;modp2048,aes128-sha1;modp2048,aes-sha2;modp2048,aes256-sha1;mod
> p1024,aes128-sha1;modp1024,aes-sha2;modp1024
>
> 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?
>
> How does this connection use case address roaming clients?
>
> Connection info:
>
> Jan 22 17:19:54 ip-10-0-0-194 pluto[19256]: "ikev2-cp"[2] xx.xx.xx.xx: 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 22 17:19:54 ip-10-0-0-194 pluto[19256]: "ikev2-cp"[2] xx.xx.xx.xx #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 22 17:19:54 ip-10-0-0-194 pluto[19256]: "ikev2-cp"[2] xx.xx.xx.xx #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 22 17:20:06 ip-10-0-0-194 pluto[19256]: "ikev2-cp"[2] xx.xx.xx.xx #2: certificate verified OK: O=Client3,CN=client3.zzz.net
> Jan 22 17:20:06 ip-10-0-0-194 pluto[19256]: "ikev2-cp"[2] xx.xx.xx.xx #2: No matching subjectAltName found
> Jan 22 17:20:06 ip-10-0-0-194 pluto[19256]: "ikev2-cp"[2] xx.xx.xx.xx #2: No matching subjectAltName found
> Jan 22 17:20:06 ip-10-0-0-194 pluto[19256]: "ikev2-cp"[2] xx.xx.xx.xx #2: IKEv2 mode peer ID is ID_IPV4_ADDR: '192.168.1.166'
> Jan 22 17:20:06 ip-10-0-0-194 pluto[19256]: "ikev2-cp"[2] xx.xx.xx.xx #2: Authenticated using RSA
> Jan 22 17:20:06 ip-10-0-0-194 pluto[19256]: "ikev2-cp"[2] xx.xx.xx.xx: constructed local ESP/AH proposals for ikev2-cp (IKE_AUTH
> responder 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
> Jan 22 17:20:06 ip-10-0-0-194 pluto[19256]: "ikev2-cp"[2] xx.xx.xx.xx #3: responding to IKE_AUTH message (ID 1) from
> xx.xx.xx.xx:4500 with encrypted notification NO_PROPOSAL_CHOSEN
> Jan 22 17:20:06 ip-10-0-0-194 pluto[19256]: "ikev2-cp"[2] xx.xx.xx.xx #3: deleting other state #3 (STATE_CHILDSA_DEL) aged 0.006s
> and NOT sending notification
> Jan 22 17:20:06 ip-10-0-0-194 pluto[19256]: "ikev2-cp"[2] xx.xx.xx.xx #2: deleting state (STATE_IKESA_DEL) aged 12.531s and NOT
> sending notification
> Jan 22 17:20:06 ip-10-0-0-194 pluto[19256]: packet from xx.xx.xx.xx:4500: deleting connection "ikev2-cp"[2] xx.xx.xx.xx instance
> with peer xx.xx.xx.xx {isakmp=#0/ipsec=#0}
>
>
> On Friday, January 18, 2019, 7:23:20 PM EST, Paul Wouters <paul at nohats.ca> wrote:
>
>
> Don’t use DH1 (modp1024), it is too weak and Apple will refuse it
>
> Sent from mobile device
>
> On Jan 18, 2019, at 17:33, Mr. Jan Walter <hopping_hol at yahoo.com> wrote:
>
> Same server, now hacking through the same config on the latest OSX:
>
> Set auth method to none, set certificate in that.
> CA cert set in system keystore and marked as trusted, the client2 cert in the login key store, seemed to work according to
> the logs.
> Set ExtSAN, so cert was generated as:
>
> certutil -S -c "ca.zzz.net" -n "client2.zzz.net" -s "O=Client2,CN=client2.zzz.net" -k rsa -v 12 -d sql:${HOME}/ca -t ",," -1
> -6 -8 "client2.zzz.net" --extSAN ip:11.11.11.11
>
> with the IP being the internet-sided of the NAT IP for the client. Note that the -8 arg should set the DNS Altname. Does
> that need reverse DNS lookup working right or something?
>
> Server logs:
> =====
> Jan 18 21:36:21 ip-10-0-0-194 pluto[14881]: "ikev2-cp"[1] 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=MODP1024
> 4:IKE:ENCR=AES_CBC_128;PRF=HMAC_SHA1;INTEG=HMAC_SHA1_96;DH=MODP1024
> 5:IKE:ENCR=AES_CBC_256,AES_CBC_128;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_256_128;DH=MODP1024
> Jan 18 21:36:21 ip-10-0-0-194 pluto[14881]: "ikev2-cp"[1] 11.11.11.11 #1: proposal
> 4:IKE:ENCR=AES_CBC_128;PRF=HMAC_SHA1;INTEG=HMAC_SHA1_96;DH=MODP1024 chosen from remote proposals
> 1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_256_128;DH=MODP2048
> 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[first-match]
> 5:IKE:ENCR=3DES;PRF=HMAC_SHA1;INTEG=HMAC_SHA1_96;DH=MODP1024
> Jan 18 21:36:21 ip-10-0-0-194 pluto[14881]: "ikev2-cp"[1] 11.11.11.11 #1: initiator guessed wrong keying material group
> (MODP2048); responding with INVALID_KE_PAYLOAD requesting MODP1024
> Jan 18 21:36:21 ip-10-0-0-194 pluto[14881]: "ikev2-cp"[1] 11.11.11.11 #1: responding to IKE_SA_INIT (34) message (Message ID
> 0) from 11.11.11.11:500 with unencrypted notification INVALID_KE_PAYLOAD
> Jan 18 21:36:21 ip-10-0-0-194 pluto[14881]: "ikev2-cp"[1] 11.11.11.11 #1: deleting state (STATE_PARENT_R0) aged 0.001s and
> NOT sending notification
> Jan 18 21:36:21 ip-10-0-0-194 pluto[14881]: packet from 11.11.11.11:500: deleting connection "ikev2-cp"[1] 11.11.11.11
> instance with peer 11.11.11.11 {isakmp=#0/ipsec=#0}
> Jan 18 21:36:21 ip-10-0-0-194 pluto[14881]: "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=MODP1024
> 4:IKE:ENCR=AES_CBC_128;PRF=HMAC_SHA1;INTEG=HMAC_SHA1_96;DH=MODP1024
> 5:IKE:ENCR=AES_CBC_256,AES_CBC_128;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_256_128;DH=MODP1024
> Jan 18 21:36:21 ip-10-0-0-194 pluto[14881]: "ikev2-cp"[2] 11.11.11.11 #2: proposal
> 4:IKE:ENCR=AES_CBC_128;PRF=HMAC_SHA1;INTEG=HMAC_SHA1_96;DH=MODP1024 chosen from remote proposals
> 1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_256_128;DH=MODP2048
> 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[first-match]
> 5:IKE:ENCR=3DES;PRF=HMAC_SHA1;INTEG=HMAC_SHA1_96;DH=MODP1024
> Jan 18 21:36:21 ip-10-0-0-194 pluto[14881]: "ikev2-cp"[2] 11.11.11.11 #2: STATE_PARENT_R1: received v2I1, sent v2R1
> {auth=IKEv2 cipher=AES_CBC_128 integ=HMAC_SHA1_96 prf=HMAC_SHA1 group=MODP1024}
> Jan 18 21:36:21 ip-10-0-0-194 pluto[14881]: "ikev2-cp"[2] 11.11.11.11 #2: certificate verified OK:
> O=Client2,CN=client2.zzz.net
> Jan 18 21:36:21 ip-10-0-0-194 pluto[14881]: "ikev2-cp"[2] 11.11.11.11 #2: No matching subjectAltName found
> Jan 18 21:36:21 ip-10-0-0-194 pluto[14881]: "ikev2-cp"[2] 11.11.11.11 #2: No matching subjectAltName found
> Jan 18 21:36:21 ip-10-0-0-194 pluto[14881]: "ikev2-cp"[2] 11.11.11.11 #2: IKEv2 mode peer ID is ID_IPV4_ADDR:
> '192.168.1.198'
> Jan 18 21:36:21 ip-10-0-0-194 pluto[14881]: "ikev2-cp"[2] 11.11.11.11 #2: Authenticated using RSA
> Jan 18 21:36:21 ip-10-0-0-194 pluto[14881]: "ikev2-cp"[2] 11.11.11.11: constructed local ESP/AH proposals for ikev2-cp
> (IKE_AUTH responder 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 18 21:36:21 ip-10-0-0-194 pluto[14881]: "ikev2-cp"[2] 11.11.11.11 #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 18 21:36:21 ip-10-0-0-194 pluto[14881]: "ikev2-cp"[2] 11.11.11.11 #2: IKE_AUTH responder matching remote ESP/AH
> proposals failed, responder SA processing returned STF_FAIL+v2N_NO_PROPOSAL_CHOSEN
> Jan 18 21:36:21 ip-10-0-0-194 pluto[14881]: "ikev2-cp"[2] 11.11.11.11 #3: responding to IKE_AUTH message (ID 1) from
> 11.11.11.11:4500 with encrypted notification NO_PROPOSAL_CHOSEN
> Jan 18 21:36:21 ip-10-0-0-194 pluto[14881]: "ikev2-cp"[2] 11.11.11.11 #3: deleting other state #3 (STATE_CHILDSA_DEL) aged
> 0.008s and NOT sending notification
> Jan 18 21:36:21 ip-10-0-0-194 pluto[14881]: "ikev2-cp"[2] 11.11.11.11 #2: deleting state (STATE_IKESA_DEL) aged 0.057s and
> NOT sending notification
> Jan 18 21:36:21 ip-10-0-0-194 pluto[14881]: packet from 11.11.11.11:4500: deleting connection "ikev2-cp"[2] 11.11.11.11
> instance with peer 11.11.11.11 {isakmp=#0/ipsec=#0}
> ====
>
> Config file:
> ====
> 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=ip-of-vv.zzz.net
> 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;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
> rightca=%same
> rightrsasigkey=%cert
> 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
> # ikev2 fragmentation support requires libreswan 3.14 or newer
> fragmentation=yes
> # optional PAM username verification (eg to implement bandwidth quota
> # pam-authorize=yes
> ===
>
> I got to this configuration through a combination of:
> https://dc77312.wordpress.com/2019/01/09/libreswan-ipsec-ikev2-vpn-on-rhel-8-beta-server-and-windows-10-client/
> https://libreswan.org/wiki/Configuration_examples
> https://lists.libreswan.org/pipermail/swan/2018/002902.html (also in one of Paul's earlier emails)
> https://github.com/libreswan/libreswan/issues/198 discussion
>
> And found the right ms-dh-downgrade keyword in the source code.
>
>
>
> Cheers,
>
> Jan
>
>
>
>
>
> _______________________________________________
> Swan mailing list
> Swan at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan
>
>
>
More information about the Swan
mailing list