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>
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>
