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

Tue Feb 27 21:45:07 UTC 2018

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/7366590a/attachment-0001.html>