That’s a bug in 3.15 where it did not allow more then one CERT payload. Please upgrade to a later version.
Paul Sent from my iPhone > On Feb 27, 2018, at 16:45, Sadler, Jonathan B. <[email protected]> > wrote: > > Thanks for the quick response. > > I thought some MTU issues may exists, so I had inserted the fragment=forced > in the config. After getting your response pointing out issues with > fragmentation and knowing that the Interpeak IKE is supposed to handle > message sizes up to 10000 bytes, I did some path MTU tests and found an > Ethernet switch in the path that was limiting Ethernet frames to 512 bytes > payload. Not useful... > > After swapping the switch out, things seem better, but still not coming up > roses. Here is the current output from /var/log/secure: > Feb 27 16:30:36 Linux69 pluto[22722]: "target" #1: initiating v2 parent SA > Feb 27 16:30:36 Linux69 pluto[22722]: "target" #1: STATE_PARENT_I1: sent > v2I1, expected v2R1 > Feb 27 16:30:37 Linux69 pluto[22722]: | Sending [CERT] of certificate: > [email protected].,CN=TNMSLinux69.envisionplusdomain.com.,OU=Test,O=Coriant,ST=IL,C=US > Feb 27 16:30:37 Linux69 pluto[22722]: "target" #2: STATE_PARENT_I2: sent > v2I2, expected v2R2 {auth=IKEv2 cipher=aes_128 integ=sha1_96 prf=sha > group=MODP2048} > Feb 27 16:30:37 Linux69 pluto[22722]: "target" #2: payload(s) > (ISAKMP_NEXT_v2CERT) unexpectedly repeated. Message dropped. > Feb 27 16:30:37 Linux69 pluto[22722]: "target" #2: payload(s) > (ISAKMP_NEXT_v2CERT) unexpectedly repeated. Message dropped. > Feb 27 16:30:38 Linux69 pluto[22722]: "target" #2: payload(s) > (ISAKMP_NEXT_v2CERT) unexpectedly repeated. Message dropped. > Feb 27 16:30:39 Linux69 pluto[22722]: "target" #2: payload(s) > (ISAKMP_NEXT_v2CERT) unexpectedly repeated. Message dropped. > Feb 27 16:30:40 Linux69 pluto[22722]: "target" #3: STATE_PARENT_R1: received > v2I1, sent v2R1 {auth=IKEv2 cipher=aes_128 integ=sha1_96 prf=sha > group=MODP2048} > Feb 27 16:30:41 Linux69 pluto[22722]: "target" #2: payload(s) > (ISAKMP_NEXT_v2CERT) unexpectedly repeated. Message dropped. > Feb 27 16:30:41 Linux69 pluto[22722]: "target" #3: payload(s) > (ISAKMP_NEXT_v2CERT) unexpectedly repeated. Message dropped. > Feb 27 16:30:41 Linux69 pluto[22722]: | ikev2_parent_inI2outR2_tail returned > STF_FAIL with v2N_INVALID_SYNTAX > Feb 27 16:30:41 Linux69 pluto[22722]: "target" #3: sending unencrypted > notification v2N_INVALID_SYNTAX to 172.23.129.50:500 > Feb 27 16:30:41 Linux69 pluto[22722]: "target" #3: missing payload(s) > (ISAKMP_NEXT_v2SK). Message dropped. > Feb 27 16:30:41 Linux69 pluto[22722]: "target" #3: sending unencrypted > notification v2N_INVALID_SYNTAX to 172.23.129.50:500 > Feb 27 16:30:41 Linux69 pluto[22722]: "target" #3: missing payload(s) > (ISAKMP_NEXT_v2SK). Message dropped. > > And from vxWorks SYSLOG: > TUE FEB 27 21:39:27 2018: ipike[57a49230]: Notice: New exchange started > (IKE_SA_INIT with message ID: 0) > TUE FEB 27 21:39:27 2018: ipike[57a49230]: Notice: Received message > 172.22.103.146[500], IKE_SA_INIT, #1(4), ID 0 > TUE FEB 27 21:39:27 2018: ipike[57a49230]: Info: selected 'aes' as encryption > algorithm > TUE FEB 27 21:39:27 2018: ipike[57a49230]: Info: selected '128' as key length > TUE FEB 27 21:39:27 2018: ipike[57a49230]: Info: selected 'sha1' as hash > algorithm > TUE FEB 27 21:39:27 2018: ipike[57a49230]: Info: selected 'sha1' as integrity > algorithm > TUE FEB 27 21:39:27 2018: ipike[57a49230]: Info: selected 'modp2048' as DH > group description > TUE FEB 27 21:39:27 2018: ipike[57a49230]: Notice: Sending message > 172.22.103.146[500], (IKE_SA_INIT), #2(4), ID 0 > TUE FEB 27 21:39:27 2018: ipike[57a49230]: Notice: Received message > 172.22.103.146[500], IKE_SA_INIT, #3(4), ID 0 > TUE FEB 27 21:39:27 2018: ipike[57a49230]: Notice: Message > 172.22.103.146[500] already processed, (IKE_SA_INIT), #2(4), ID 0 > TUE FEB 27 21:39:27 2018: ipike[57a49230]: Notice: Resending message > 172.22.103.146[500], (IKE_AUTH), #2(4), ID 0, 1(5) > TUE FEB 27 21:39:27 2018: ipike[57a49230]: Notice: Received message > 172.22.103.146[500], IKE_AUTH, #3(4), ID 1 > TUE FEB 27 21:39:27 2018: ipike[57a49230]: Info: selected 'aes' as encryption > algorithm > TUE FEB 27 21:39:27 2018: ipike[57a49230]: Info: selected '128' as key length > TUE FEB 27 21:39:27 2018: ipike[57a49230]: Info: selected 'sha1' as integrity > algorithm > TUE FEB 27 21:39:27 2018: ipike[57a49230]: Info: selected 'off' for ESN > TUE FEB 27 21:39:28 2018: ipike[57a49230]: Notice: Sending message > 172.22.103.146[500], (IKE_AUTH), #4(4), ID 1 > TUE FEB 27 21:39:28 2018: ipike[57a49230]: Info: CHILD SA exchange done in > 670 ms (peer: 172.22.103.146, message ID: 1) > TUE FEB 27 21:39:28 2018: ipike[57a49230]: Info: IKE SA INIT done in 670 ms > (peer: 172.22.103.146, message ID: 1) > TUE FEB 27 21:39:28 2018: ipike[57a49230]: Notice: Received message > 172.22.103.146[500], IKE_AUTH, #5(4), ID 1 > TUE FEB 27 21:39:28 2018: ipike[57a49230]: Notice: Message > 172.22.103.146[500] already processed, (IKE_AUTH), #4(4), ID 1 > TUE FEB 27 21:39:28 2018: ipike[57a49230]: Notice: Resending message > 172.22.103.146[500], (IKE_AUTH), #4(4), ID 1, 2(5) > TUE FEB 27 21:39:28 2018: ipike[57a49230]: Notice: Received message > 172.22.103.146[500], IKE_AUTH, #5(4), ID 1 > TUE FEB 27 21:39:28 2018: ipike[57a49230]: Notice: Message > 172.22.103.146[500] already processed, (IKE_AUTH), #4(4), ID 1 > > The Linux system thinks things are better, showing IKE SAs that are > authenticated: > 000 Total IPsec connections: loaded 1, active 0 > 000 > 000 State Information: DDoS cookies not required, Accepting new IKE > connections > 000 IKE SAs: total(7), half-open(1), open(0), authenticated(6), anonymous(0) > 000 IPsec SAs: total(1), authenticated(1), anonymous(0) > 000 > > But the vxWorks system is not as happy: > [vxWorks]# ike list > [0] initiator cookie: 0x199a30a4c4a77457 responder cookie: 0xeaf67966e11cd5e8 > created 13 seconds ago as initiator, ref.count: 1, state: CONSTRUCTING > peer addr: 172.22.103.146, local addr: 172.23.129.50 > sent bytes: 2048, received bytes: 4380 > > Config is same as before, removing the fragmentation=forced directive. > > Any thoughts? > > Jonathan Sadler > > -----Original Message----- > From: Paul Wouters [mailto:[email protected]] > Sent: Tuesday, February 27, 2018 11:08 AM > To: Sadler, Jonathan B. <[email protected]> > Cc: [email protected] > Subject: Re: [Swan] Looking for assistance: libreswan pluto 3.15 interop with > vxWorks (Interpeak) 6.5 ipsec > > On Tue, 27 Feb 2018, Sadler, Jonathan B. wrote: > > > Please point me to a troubleshooting guide if you feel it would help my > > debugging. > > > > I’m attempting to get a tunnel using IKEv2 and x509 certs established > > between a linux system with pluto 3.15 and an embedded system using vxWorks > > 6.5. I have the certificates incorporated in the NSS database and am > > having issues getting to phase2. > > > Feb 27 11:32:58 Linux69 pluto[26056]: "target" #2: missing payload(s) > > (ISAKMP_NEXT_v2SA+ISAKMP_NEXT_v2IDr+ISAKMP_NEXT_v2AUTH+ISAKMP_NEXT_v2TSi+ISAKMP_NEXT_v2TSr). > > Message dropped. > > > > Feb 27 11:32:58 Linux69 pluto[26056]: packet from 172.23.129.50:500: > > sending unencrypted notification v2N_INVALID_MESSAGE_ID to > > 172.23.129.50:500 > > This means it throws an error to libreswan. > > > TUE FEB 27 16:57:19 2018: ipike[57f84540]: Notice: Message > > 172.22.103.146[500] already processed, (IKE_SA_INIT), #2(4), ID 0 > > > > TUE FEB 27 16:57:19 2018: ipike[57f84540]: Notice: Resending message > > 172.22.103.146[500], (IKE_AUTH), #2(4), ID 0, 1(5) > > > > TUE FEB 27 16:57:20 2018: ipike[57f84540]: Notice: Received message > > 172.22.103.146[500], IKE_AUTH, #3(4), ID 1 > > > > TUE FEB 27 16:57:20 2018: ipike[57f84540]: Error: the payloads extends > > beyond the end of the ISAKMP package > > > > TUE FEB 27 16:57:20 2018: ipike[57f84540]: Warning: ISAKMP message > > dropped, error code 20 > > that's weird. It claims we sent a badly formed IKE packet? > > > TUE FEB 27 16:57:20 2018: ipike[57f84540]: Notice: Received message > > 172.22.103.146[500], IKE_AUTH, #3(4), ID 1 > > > > TUE FEB 27 16:57:20 2018: ipike[57f84540]: Error: payload check failed > > since 53 is an unsupported payload type > > Type 53 is an encrypted fragment (see RFC 7383). If it does not support that, > then why was FRAGMENTATION performed. libreswan has an "override" > when using fragmentation=force which obviously should not be used with > implementations that do not support fragmentation. > > > Here is the config I’m using: > > > > conn target > > type=tunnel > > fragmentation=force > > So remove this fragmentation=force line :) > > Paul
_______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
