Mailing List Archive: lifetime_ike_process(): vpnc killed by SIGABRT

lifetime_ike_process(): vpnc killed by SIGABRT

Dec 8, 2014, 2:11 PM

Post #1 of 7 (5133 views)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello,

I submitted this as a bug report to the Fedora (Red Hat) bugzilla
(https://bugzilla.redhat.com/show_bug.cgi?id=1171852). Many details
there, summary here.

On Fedora 20, configured a new VPN in NetworkManager, using the vpnc
back-end. The remote end is a Fortigate firewall. I configured per
http://www.justdailynotes.com/fortinet/linux/2014/11/24/Fortigate-IPSec-Linux-NetworkManager/

Later, running SVN trunk from the command line with "Debug 3", I receive
the output below. No SIGABRT, but still did not successfully connect to
the remote.

I realize this isn't a Cisco VPN server, so feel free to tell me to go
away! Also, I now realize that the information below doesn't show a
reproduction of the bugzilla report. No SIGABRT, vpnc simply won't
connect (will it *does* connect, but then closes the connection).

Does this look like a simple configuration error on my part? That would
be great!

Thanks for looking at this and at the Bugzilla bug report.

Best regards,

~David Klann

Configuration summary from the Fortigate (I don't have admin access to
this device):
# IKE version 1
# Mode = aggressive
# NAT Traversal = enabled
# Dead Peer Detection = enabled
# Phase 1
# ---
# AES256-MD5, AES256-SHA1
# DH Group = 2
# Phase 2
# ---
# AES256-MD5, AES256-SHA1
# Replay Detection = enabled
# Autokey Keep Alive = enabled

My vpnc.conf:

IPSec gateway ip.addr.goes.here
Vendor cisco
IPSec ID WIN
IKE Authmode psk
IPSec secret big-long-secret
Xauth username username
Xauth password another-big-long-secret
NAT Traversal Mode natt
IKE DH Group dh2
Perfect Forward Secrecy dh2
DPD idle timeout (our side) 10
Debug 3
No Detach

STDERR from running 'sudo vpnc vpnc.conf':

vpnc: quick mode response rejected: (ISAKMP_N_INVALID_MESSAGE_ID)(9)
this means the concentrator did not like what we had to offer.
Possible reasons are:
* concentrator configured to require a firewall
this locks out even Cisco clients on any platform except windows
which is an obvious security improvement. There is no workaround (yet).
* concentrator configured to require IP compression
this is not yet supported by vpnc.
Note: the Cisco Concentrator Documentation recommends against using
compression, except on low-bandwith (read: ISDN) links, because it
uses much CPU-resources on the concentrator

Debug output in the attached text file.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlSGIhoACgkQZtxZ++32cNgHfAD8DbkXFZm+DUzdIME1WD65el3k
A/YdgRdJ0GS0ENHAzv0A/RE1DDFpiXdSDOdDajB8VbiLoA9tid4uVQ24BfYiJ3M3
=fGK5
-----END PGP SIGNATURE-----

Re: lifetime_ike_process(): vpnc killed by SIGABRT [ In reply to ]

jmvpnc at loplof

Dec 10, 2014, 9:54 AM

Post #2 of 7 (5088 views)

Permalink

Hello David,

On Mon, Dec 08, 2014 at 04:11:39PM -0600, David Klann wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> I submitted this as a bug report to the Fedora (Red Hat) bugzilla
> (https://bugzilla.redhat.com/show_bug.cgi?id=1171852). Many details
> there, summary here.
>
> On Fedora 20, configured a new VPN in NetworkManager, using the vpnc
> back-end. The remote end is a Fortigate firewall. I configured per
> http://www.justdailynotes.com/fortinet/linux/2014/11/24/Fortigate-IPSec-Linux-NetworkManager/

> Later, running SVN trunk from the command line with "Debug 3", I receive
> the output below. No SIGABRT, but still did not successfully connect to
> the remote.

Thanks for the Debug. Rest see below.

Actually, the log is telling quite exactly where (but not why) the connection
attempt is going wrong:
Phase I (the IKEv1/ISAKMP) connection setup succeeds.
Phase 1,5 (Mode XAUTH and Mode Config) succeed.
Phase II connection setup fails.
We are sending a list of transform sets (combinations of crypto routines
that we offer the other side, configured in vpnc.conf).
The other side doesn't like the offer and rejects the connection.

> Does this look like a simple configuration error on my part? That would
> be great!

I guess that this is not a bug in the code of server or client but incompatible
parameter sets (transform sets). Once we find out which part of your phase 2
config the other side isn't happy with feel free to speculate whether this was
a) a config "error" and b) "simple".

Experience tells me the first thing I would change is to disable PFS (perfect
forward secrecy) in the vpnc config as I didn't see anything about this in
the justdailynotes link (or is it there and I did just miss it?).

Ciao
JÃ¶rg

> Configuration summary from the Fortigate (I don't have admin access to
> this device):

VPN concentrator

Phase I config:

> # IKE version 1
> # Mode = aggressive
> # NAT Traversal = enabled
> # Dead Peer Detection = enabled
> # Phase 1
> # ---
> # AES256-MD5, AES256-SHA1
> # DH Group = 2

Phase II config:

> # Phase 2
> # ---
> # AES256-MD5, AES256-SHA1
> # Replay Detection = enabled
> # Autokey Keep Alive = enabled
>
> My vpnc.conf:
>
> IPSec gateway ip.addr.goes.here
> Vendor cisco
> IPSec ID WIN
> IKE Authmode psk
> IPSec secret big-long-secret
> Xauth username username
> Xauth password another-big-long-secret
> NAT Traversal Mode natt
> IKE DH Group dh2
> Perfect Forward Secrecy dh2

Try other values here (my first attempt would be to comment this out - which
defaults the value to "server").
From vpnc --long-help
"conf-variable: Perfect Forward Secrecy <nopfs/dh1/dh2/dh5/server>"

> DPD idle timeout (our side) 10
> Debug 3
> No Detach

> vpnc: quick mode response rejected: (ISAKMP_N_INVALID_MESSAGE_ID)(9)

Quick mode is the name of the protocol used for phase 2 negotiation.

> this means the concentrator did not like what we had to offer.
> Possible reasons are:
> * concentrator configured to require a firewall
> this locks out even Cisco clients on any platform except windows
> which is an obvious security improvement. There is no workaround (yet).
> * concentrator configured to require IP compression
> this is not yet supported by vpnc.
> Note: the Cisco Concentrator Documentation recommends against using
> compression, except on low-bandwith (read: ISDN) links, because it
> uses much CPU-resources on the concentrator

If this doesn't help - and only then: Do you have the chance to ask the vpnc
concentrator admin to provide you with the reason why your connection attempt
was rejected? Replacing speculation from our side what the other side doesn't
like with facts by looking at the logs is always a boring but efficient approach
if possible ;-)

Ciao
JÃ¶rg
_______________________________________________
vpnc-devel mailing list
vpnc-devel@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/

Re: lifetime_ike_process(): vpnc killed by SIGABRT [ In reply to ]

dxklann at riseup

Dec 12, 2014, 10:58 AM

Post #3 of 7 (5077 views)

Permalink

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Greetings JÃ¶rg,

Thanks for your detailed response to my note. I have now had a chance to
modify settings in my vpnc.conf and have new results to report. I still
do not have access to the VPN server, but I hope to work with the
administrator of it later today. For now...

On 12/10/2014 11:54 AM, Joerg Mayer wrote:
> Hello David,
>
> On Mon, Dec 08, 2014 at 04:11:39PM -0600, David Klann wrote:
> Later, running SVN trunk from the command line with "Debug 3", I receive
> the output below. No SIGABRT, but still did not successfully connect to
> the remote.
>
> Thanks for the Debug. Rest see below.
>
> Actually, the log is telling quite exactly where (but not why) the
connection
> attempt is going wrong:
> Phase I (the IKEv1/ISAKMP) connection setup succeeds.
> Phase 1,5 (Mode XAUTH and Mode Config) succeed.
> Phase II connection setup fails.
> We are sending a list of transform sets (combinations of crypto routines
> that we offer the other side, configured in vpnc.conf).
> The other side doesn't like the offer and rejects the connection.
>
>> Does this look like a simple configuration error on my part? That would
>> be great!
>
> I guess that this is not a bug in the code of server or client but
incompatible
> parameter sets (transform sets). Once we find out which part of your
phase 2
> config the other side isn't happy with feel free to speculate whether
this was
> a) a config "error" and b) "simple".
>
> Experience tells me the first thing I would change is to disable PFS
(perfect
> forward secrecy) in the vpnc config as I didn't see anything about this in
> the justdailynotes link (or is it there and I did just miss it?).

I did not see a reference to disabling PFS on that site as well. But I
changed my configuration file to say "Perfect Forward Secrecy nopfs",
and here is the output with "Debug 1":

vpnc version 0.5.3
IKE SA selected psk+xauth-aes256-md5
NAT status: this end behind NAT? YES -- remote end behind NAT? no
got address 10.212.134.102
IPSEC SA selected aes256-sha1
vpnc: vpnc.c:1208: lifetime_ike_process: Assertion `a->next->type ==
IKE_ATTRIB_LIFE_DURATION' failed.

I uploaded the output of an invocation with the same configuration and
"Debug 3" to http://pastebin.com/qKHVhAhh

I will report back when I have information from the VPN server.

Thanks again for your help with this!

Best,

~David

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlSLOuoACgkQZtxZ++32cNixWgD/cauIQ1AVerTLoD+x7LHuBiq1
HF2kqe5R2FyHIr/nrWEBAMgSO+Orz4yIaknVpEkjLrvV0W6UVzq0MzULYDLoCjFn
=HIfu
-----END PGP SIGNATURE-----

_______________________________________________
vpnc-devel mailing list
vpnc-devel@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/

Re: lifetime_ike_process(): vpnc killed by SIGABRT [ In reply to ]

dxklann at riseup

Dec 12, 2014, 2:20 PM

Post #4 of 7 (5075 views)

Permalink

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Ha! It's working (sort of)!

On 12/10/2014 11:54 AM, Joerg Mayer wrote:
> Actually, the log is telling quite exactly where (but not why) the connection attempt is going
wrong: Phase I (the IKEv1/ISAKMP) connection setup succeeds. Phase 1,5
(Mode XAUTH and Mode Config) succeed. Phase II connection setup fails.
We are sending a list of transform sets (combinations of crypto routines
that we offer the other side, configured in vpnc.conf). The other side
doesn't like the offer and rejects the connection.
>> Does this look like a simple configuration error on my part? That would
>> be great!
>
> I guess that this is not a bug in the code of server or client but
incompatible
> parameter sets (transform sets). Once we find out which part of your
phase 2
> config the other side isn't happy with feel free to speculate whether
this was
> a) a config "error" and b) "simple".
>
> Experience tells me the first thing I would change is to disable PFS
(perfect
> forward secrecy) in the vpnc config as I didn't see anything about this in
> the justdailynotes link (or is it there and I did just miss it?).
>
> Ciao
> JÃ¶rg
>

After troubleshooting with the VPN administrator I came to the following
working configuration:

IPSec gateway ip.add.ress.here
Vendor cisco
IPSec ID GROUPNAME
IKE Authmode psk
IPSec secret super-secret-shared-passphrase
Xauth username klann
Xauth password another-super-secret-passphrase
NAT Traversal Mode cisco-udp
IKE DH Group dh2
Perfect Forward Secrecy nopfs
DPD idle timeout (our side) 3
Debug 1
# No Detach

Changing the to debug to "Debug 0", or simply NOT having a Debug
configuration value causes vpnc to emit the following error:

vpnc: vpnc.c:1208: lifetime_ike_process: Assertion `a->next->type ==
IKE_ATTRIB_LIFE_DURATION' failed.

So, this seems like it might be an actual bug. I haven't had a chance
yet to look at line 1208 if vpnc.c.

Thanks again for your helpful suggestions!

Best,

~David

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlSLakMACgkQZtxZ++32cNjPbwD+NxepsX1UH84W/i8Vq2VKtHHI
XbVXB0n9QvQ0oUG2emQBAJmkHsmss/TeoywrrVYqPRuzNmhed5twQlmCzI3Enhf7
=r18c
-----END PGP SIGNATURE-----

_______________________________________________
vpnc-devel mailing list
vpnc-devel@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/

Re: lifetime_ike_process(): vpnc killed by SIGABRT [ In reply to ]

mrbriancollins at gmail

Jun 21, 2015, 2:35 AM

Post #5 of 7 (4613 views)

Permalink

Did you ever get this figured out? I am trying in fedora 21 with a
Fortigate 300C as well and getting the same errors and issues.
I however have access to the fortigate....

Re: lifetime_ike_process(): vpnc killed by SIGABRT [ In reply to ]

jlayton at poochiereds

Jun 27, 2015, 3:35 AM

Post #6 of 7 (4603 views)

Permalink

On Sat, 27 Jun 2015 01:35:51 +0000
Brian Collins <mrbriancollins@gmail.com> wrote:

> hey Jeff thanks for the response. I will be patching my vpnc and testing. I
> hadn't tried this on previous FW revisions of the Fortigatge Firewalls. I
> have 2 300C's.
> I think I still have one supported that I will file a ticket on as well.
>
>

Thanks,

I reopened the Fedora bug, but the package maintainer (understandably)
would like the vpnc developers to commit the patch to SVN before taking
it into the package. So it would be good for Joerg (or whomever is
maintaining the SVN repo) to review and commit it if it's safe.

It seems like it ought to be fine though. vpnc already just returns and
ignores the payload when it gets an attribute format here that it
can't cope with. Getting an attribute type that it doesn't understand
ought to do the same.

-- Jeff

>
>
> On Fri, Jun 26, 2015 at 2:16 PM Jeff Layton <jlayton@poochiereds.net> wrote:
>
> > My company upgraded their firewall over the weekend so I got bitten by
> > this too. I did a little poking in the code and here's what I've
> > discovered so far.
> >
> > This looks like either a bug in a ISAKMP_N_IPSEC_RESPONDER_LIFETIME
> > payload being sent by the firewall, or a problem in vpnc in parsing it.
> > Since it had been working until they upgraded, I suspect it's the
> > former.
> >
> > This is the payload it's barfing on:
> >
> > PARSING PAYLOAD type: 0b (ISAKMP_PAYLOAD_N)
> > next_type: 0b (ISAKMP_PAYLOAD_N)
> > length: 0028
> > n.doi: 00000001 (ISAKMP_DOI_IPSEC)
> > n.protocol: 01 (ISAKMP_IPSEC_PROTO_ISAKMP)
> > n.spi_length: 10
> > n.type: 6000 (ISAKMP_N_IPSEC_RESPONDER_LIFETIME)
> > n.spi: 66548f57 ce7a153b ab19c18b 851d4fbb
> > n.data: 800b0001 00020004 00007080
> > t.attributes.type: 000b (IKE_ATTRIB_LIFE_TYPE)
> > t.attributes.u.attr_16: 0001 (IKE_LIFE_TYPE_SECONDS)
> > t.attributes.type: 0002 (IKE_ATTRIB_HASH)
> > t.attributes.u.lots.length: 0004
> > t.attributes.u.lots.data: 00007080
> > DONE PARSING PAYLOAD type: 0b (ISAKMP_PAYLOAD_N)
> >
> > As best I can tell (and IPsec is not really my forte'), this should
> > carry the lifetime for the key being negotiated via IKE. The first
> > attribute tells the units (seconds or kilobytes). The second attribute
> > should be the actual value. vpnc expects it to be an attribute type of
> > IKE_ATTRIB_LIFE_DURATION but it's not -- it's passing us a hash
> > algorithm instead (which makes no sense in the context of this payload).
> >
> > So, either we have bad parsing here or the fortigate firewall is
> > sending us a bogus payload.
> >
> > I'll be sending patch in a minute that seems to fix it for me. It just
> > makes vpnc ignore the payload in this case. I've seen some other
> > patches floating around that just comment out the assertion but I think
> > that's wrong, as we end up interpreting the value incorrectly in that
> > case.
> >
> > I'm planning to reopen this bug:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1171852
> >
> > ...and attach this patch in the hopes that we can get this added to the
> > stock fedora/epel packages. Having it merged into the vpnc SVN repo
> > might also be good.
> >
> > --
> > Jeff Layton <jlayton@poochiereds.net>
> >

--
Jeff Layton <jlayton@poochiereds.net>
_______________________________________________
vpnc-devel mailing list
vpnc-devel@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/

Re: lifetime_ike_process(): vpnc killed by SIGABRT [ In reply to ]

mbrancaleoni at gmail

Aug 3, 2015, 6:11 AM

Post #7 of 7 (4532 views)

Permalink

Hi,

I've tested the proposed patch on rh bugzilla (
https://bugzilla.redhat.com/show_bug.cgi?id=1171852 )
and works ok on a couple of clients that I currently use.

hope to see it merged :)

regards,
Matteo

Mailing List Archive

Mailing List Archive

Attached Files: