<html dir="ltr"><head></head><body bgcolor="#ffffff" text="#2e3436" link="#2a76c6" vlink="#2e3436" style="text-align:left; direction:ltr;"><div><font size="4"><br></font></div><div><font size="4">Hi Paul</font></div><div><font size="4">        I read a few documentation about similar problem with MacOS and tried a suggestion you have mentioned in them.  I didn't import a profile, but in the VPN configuration of Mac, under "Authentication Settings", I choose "None".  When I select "None", it throws up two options below  "Shared Secret" and "Certificate"... I choose "Certificate" and selected the corresponding client certificate and applied the change.  </font></div><div><font size="4"><br></font></div><div><font size="4">When I did this, it still does not connect, but there's a change in the message from the previous one</font></div><div><font size="4"><br></font></div><div><font size="4">May  1 19:55:55.592575: "MOBILE"[1] 1.2.3.4 #8: processing decrypted IKE_AUTH request: SK{IDi,N,N,IDr,AUTH,CERT,CP,N,N,SA,TSi,TSr}</font></div><div><font size="4">May  1 19:55:55.592602: loading root certificate cache</font></div><div><font size="4">May  1 19:55:55.593563: "MOBILE"[1] 1.2.3.4 #8: certificate verified OK: O=Sun,CN=Comet</font></div><div><font size="4">May  1 19:55:55.595941: "MOBILE"[1] 1.2.3.4 #8: reloaded private key matching left certificate 'sun.abc.com'</font></div><div><font size="4">May  1 19:55:55.595954: "MOBILE"[1] 1.2.3.4 #8: switched from "MOBILE"[1] 1.2.3.4 to "MOBILE"</font></div><div><font size="4">May  1 19:55:55.595979: "MOBILE"[1] 1.2.3.4: deleting connection instance with peer 1.2.3.4 {isakmp=#0/ipsec=#0}</font></div><div><font size="4">May  1 19:55:55.595992: "MOBILE"[2] 1.2.3.4 #8: IKEv2 mode peer ID is ID_FQDN: <a href="mailto:'@Comet">'@Comet</a>'</font></div><div><font size="4">May  1 19:55:55.596196: "MOBILE"[2] 1.2.3.4 #8: authenticated using RSA with SHA1</font></div><div><font size="4">May  1 19:55:55.611645: "MOBILE"[2] 1.2.3.4 #9: responding to IKE_AUTH message (ID 1) from 1.2.3.4:4500 with encrypted notification TS_UNACCEPTABLE</font></div><div><font size="4">May  1 19:55:55.611675: "MOBILE"[2] 1.2.3.4 #9: deleting state (STATE_V2_IKE_AUTH_CHILD_R0) aged 0.000041s and NOT sending notification</font></div><div><font size="4">May  1 19:55:55.611736: "MOBILE"[2] 1.2.3.4 #8: state transition 'Responder: process IKE_AUTH request' failed</font></div><div><font size="4">May  1 19:55:55.611782: "MOBILE"[2] 1.2.3.4 #8: deleting state (STATE_V2_ESTABLISHED_IKE_SA) aged 16.182256s and sending notification</font></div><div><font size="4">May  1 19:55:55.611869: "MOBILE"[2] 1.2.3.4: deleting connection instance with peer 1.2.3.4 {isakmp=#0/ipsec=#0}</font></div><div><font size="4">May  1 19:55:55.642613: packet from 1.2.3.4:4500: INFORMATIONAL message response has no corresponding IKE SA</font></div><div><font size="4"><br></font></div><div><font size="4"><br></font></div><div><font size="4">Thanks, Best</font></div><div><font size="4"><br></font></div><div><font size="4">BA</font></div><div><br></div><div><br></div><div>On Sat, 2021-05-01 at 16:43 +0530, Blue Aquan wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><font size="4"><br></font></div><div><font size="4"><br></font></div><div><font size="4">Dear Paul</font></div><div><font size="4">        The reason, I couldn't respond to your earlier message was due to certain limitations in finding a Mac OS for this testbed purpose.  I finally have one to conduct these tests and here are the logs on the Server when the Mac tries to connect.</font></div><div><font size="4"><br></font></div><div><font size="4"><br></font></div><div><font size="4">Please note, with the same configuration on the Server, Linux clients are able to connect.</font></div><div><font size="4"><br></font></div><div><font size="4">May  1 13:52:38.347004: "MOBILE"[1] 1.2.3.4: local IKE proposals (IKE SA responder matching remote proposals): </font></div><div><font size="4">May  1 13:52:38.347034: "MOBILE"[1] 1.2.3.4:   1:IKE=AES_GCM_C_256-HMAC_SHA2_512+HMAC_SHA2_256-NONE-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519</font></div><div><font size="4">May  1 13:52:38.347039: "MOBILE"[1] 1.2.3.4:   2:IKE=AES_GCM_C_128-HMAC_SHA2_512+HMAC_SHA2_256-NONE-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519</font></div><div><font size="4">May  1 13:52:38.347043: "MOBILE"[1] 1.2.3.4:   3:IKE=AES_CBC_256-HMAC_SHA2_512+HMAC_SHA2_256-HMAC_SHA2_512_256+HMAC_SHA2_256_128-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519</font></div><div><font size="4">May  1 13:52:38.347046: "MOBILE"[1] 1.2.3.4:   4:IKE=AES_CBC_128-HMAC_SHA2_512+HMAC_SHA2_256-HMAC_SHA2_512_256+HMAC_SHA2_256_128-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519</font></div><div><font size="4">May  1 13:52:38.347072: "MOBILE"[1] 1.2.3.4 #10: proposal 1:IKE=AES_CBC_256-HMAC_SHA2_256-HMAC_SHA2_256_128-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</font></div><div><font size="4">May  1 13:52:38.348823: "MOBILE"[1] 1.2.3.4 #10: sent IKE_SA_INIT reply {auth=IKEv2 cipher=AES_CBC_256 integ=HMAC_SHA2_256_128 prf=HMAC_SHA2_256 group=MODP2048}</font></div><div><font size="4">May  1 13:52:38.412735: "MOBILE"[1] 1.2.3.4 #10: dropping unexpected IKE_AUTH message containing INITIAL_CONTACT... notification; message payloads: SK; encrypted payloads: SA,IDi,IDr,N,TSi,TSr,CP; missing payloads: AUTH</font></div><div><font size="4">May  1 13:52:38.412766: "MOBILE"[1] 1.2.3.4 #10: responding to IKE_AUTH message (ID 1) from 1.2.3.4:500 with encrypted notification INVALID_SYNTAX</font></div><div><font size="4">May  1 13:52:38.412849: "MOBILE"[1] 1.2.3.4 #10: encountered fatal error in state STATE_PARENT_R1</font></div><div><font size="4">May  1 13:52:38.412920: "MOBILE"[1] 1.2.3.4 #10: deleting state (STATE_PARENT_R1) aged 0.065925s and NOT sending notification</font></div><div><font size="4">May  1 13:52:38.412954: "MOBILE"[1] 1.2.3.4: deleting connection instance with peer 1.2.3.4 {isakmp=#0/ipsec=#0}</font></div><div><font size="4"><br></font></div><div><font size="4"><br></font></div><div><font size="4"><br></font></div><div><font size="4">Thanks, Best</font></div><div><font size="4"><br></font></div><div><font size="4">BA</font></div><div><br></div><div><br></div><div>On Tue, 2021-04-20 at 15:38 -0400, Paul Wouters wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>On Tue, 20 Apr 2021, Blue Aquan wrote:</pre><br><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>Hi Team Libreswan</pre><pre>I have a Libreswan 4.3 (netkey) running on CentOS 8 which has a roadwarrior setup with the following configuration. All through I followed this</pre><pre>guide </pre><a href="https://libreswan.org/wiki/VPN_server_for_remote_clients_using_IKEv2"><pre>https://libreswan.org/wiki/VPN_server_for_remote_clients_using_IKEv2</pre></a><pre> </pre><pre>With a Linux client, the setup works flawlessly, but I am unable to replicate the same on a Mac client. I tried following the same step by creating a certificate for the</pre><pre>Mac client, but the Mac client throws up a lot of errors. I want to know if there's any standard procedure to follow while connecting from a Mac client...?</pre><br><pre>On a Linux, the same procedure works perfectly fine</pre><br><pre>On VPN Server</pre><br><pre>conn COMET</pre><pre>        left=1.2.3.4</pre><pre>        leftsubnet=192.168.1.0/24</pre><pre>        leftcert=sun.abc.com</pre><pre>        </pre><a href="mailto:leftid=@sun.abc.com"><pre>leftid=@sun.abc.com</pre></a><br></blockquote><br><pre>Note that for a Mac to accept this ID, it MUST appear as a</pre><pre>subjectAltName (SAN) of the type DNS: inside the certificate.</pre><br><pre>The mac also needs to have the CAcert that signed it of course. But it</pre><pre>should have that if you used a PKCS#12 formatted file (.p12).</pre><br><pre>Note that in the past, I've had issues with a MAC and its configuration</pre><pre>tool when you add a new connection and set it to PSK and fill in the ID,</pre><pre>and then change it to certificate. It somehow still would use the wrong</pre><pre>old ID instead of the cert. You might want to just delete the conn and</pre><pre>start a new one from scratch where you never select PSK or will in the</pre><pre>ID manually.</pre><br><pre>Paul</pre></blockquote>
</blockquote></body></html>