[Openswan Users] Leopard IPsec initial test - failed

[Paul Wouters]

Teh good news is that certifiacte imports are much much better, and actually work.
No more messing with Keychain. The bad news is, the IPsec is broken:

Oct 27 05:00:24 aivd pluto[21017]: packet from 10.112.44.200:500: received Vendor ID payload [RFC 3947] method set to=110
Oct 27 05:00:24 aivd pluto[21017]: packet from 10.112.44.200:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike] meth=109, but already using method 110
Oct 27 05:00:24 aivd pluto[21017]: packet from 10.112.44.200:500: ignoring unknown Vendor ID payload [8f8d83826d246b6fc7a8a6a428c11de8]
Oct 27 05:00:24 aivd pluto[21017]: packet from 10.112.44.200:500: ignoring unknown Vendor ID payload [439b59f8ba676c4c7737ae22eab8f582]
Oct 27 05:00:24 aivd pluto[21017]: packet from 10.112.44.200:500: ignoring unknown Vendor ID payload [4d1e0e136deafa34c4f3ea9f02ec7285]
Oct 27 05:00:24 aivd pluto[21017]: packet from 10.112.44.200:500: ignoring unknown Vendor ID payload [80d0bb3def54565ee84645d4c85ce3ee]
Oct 27 05:00:24 aivd pluto[21017]: packet from 10.112.44.200:500: ignoring unknown Vendor ID payload [9909b64eed937c6573de52ace952fa6b]
Oct 27 05:00:24 aivd pluto[21017]: packet from 10.112.44.200:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already using method 110
Oct 27 05:00:24 aivd pluto[21017]: packet from 10.112.44.200:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using method 110
Oct 27 05:00:24 aivd pluto[21017]: packet from 10.112.44.200:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 110
Oct 27 05:00:24 aivd pluto[21017]: packet from 10.112.44.200:500: received Vendor ID payload [Dead Peer Detection]
Oct 27 05:00:24 aivd pluto[21017]: "l2tp"[4] 10.112.44.200 #5: responding to Main Mode from unknown peer 10.112.44.200
Oct 27 05:00:24 aivd pluto[21017]: "l2tp"[4] 10.112.44.200 #5: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Oct 27 05:00:24 aivd pluto[21017]: "l2tp"[4] 10.112.44.200 #5: STATE_MAIN_R1: sent MR1, expecting MI2
Oct 27 05:00:24 aivd pluto[21017]: "l2tp"[4] 10.112.44.200 #5: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): no NAT detected
Oct 27 05:00:24 aivd pluto[21017]: "l2tp"[4] 10.112.44.200 #5: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Oct 27 05:00:24 aivd pluto[21017]: "l2tp"[4] 10.112.44.200 #5: STATE_MAIN_R2: sent MR2, expecting MI3
Oct 27 05:00:24 aivd pluto[21017]: "l2tp"[4] 10.112.44.200 #5: Main mode peer ID is ID_DER_ASN1_DN: 'C=ca, ST=Ontario, O=Xelerance, OU=Support Staff, CN=ken.xelerance.com, E=ken at xelerance.com'
Oct 27 05:00:24 aivd pluto[21017]: "l2tp"[4] 10.112.44.200 #5: no crl from issuer "C=ca, ST=Ontario, L=Toronto, O=Xelerance, OU=Teaching, CN=Xelerance Root CA, E=ca at xelerance.com" found (strict=no)
Oct 27 05:00:24 aivd pluto[21017]: "l2tp"[4] 10.112.44.200 #5: I am sending my cert
Oct 27 05:00:24 aivd pluto[21017]: "l2tp"[4] 10.112.44.200 #5: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Oct 27 05:00:24 aivd pluto[21017]: "l2tp"[4] 10.112.44.200 #5: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_RSA_SIG cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp1024}
Oct 27 05:00:24 aivd pluto[21017]: "l2tp"[4] 10.112.44.200 #5: byte 2 of ISAKMP Hash Payload must be zero, but is not
Oct 27 05:00:24 aivd pluto[21017]: "l2tp"[4] 10.112.44.200 #5: malformed payload in packet
Oct 27 05:00:24 aivd pluto[21017]: "l2tp"[4] 10.112.44.200 #5: sending notification PAYLOAD_MALFORMED to 10.112.44.200:500

On OSX, we see:

Oct 26 23:02:06 mbp pppd[851]: pppd 2.4.2 (Apple version 314) started by root, uid 501
Oct 26 23:02:06 mbp pppd[851]: L2TP connecting to server 'aivd.xelerance.com' (193.110.157.131)...
Oct 26 23:02:06 mbp pppd[851]: IPSec connection started
Oct 26 23:02:07 mbp pppd[851]: IPSec connection failed <IKE Error 22 (0x16) Invalid cert authority>

So hopefully it is just a simple keychain import bug, which we can work
around plus a bug in returning errors  in IKE.

It seems you need to still move/change the trust of the PKCS#12 CA-cert.
But it will not allow you to move it into the System Roots" (the old X509 Anchors)

Paul