[Swan] Looking for assistance: libreswan pluto 3.15 interop with vxWorks (Interpeak) 6.5 ipsec

Tue Feb 27 21:49:25 UTC 2018

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. <jonathan.sadler at coriant.com> 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: E=nmsmaster at envisionplusdomain.com.,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:paul at nohats.ca] 
> Sent: Tuesday, February 27, 2018 11:08 AM
> To: Sadler, Jonathan B. <jonathan.sadler at coriant.com>
> Cc: swan at lists.libreswan.org
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20180227/5c848e08/attachment-0001.html>