Mailing List Archive

Assertion failed: (a->next->type == IKE_ATTRIB_LIFE_DURATION), function lifetime_ike_process, file vpnc.c, line 1157
I get this issue on FreeBSD, while using psk+xauth (connecting to a
Fortinet VPN)

I've submitted this to FreeBSD ports, but only now noticed they asked to
submit this to upstream.

See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206937

For me it just work by commenting the line and so the assert doesn't fail,
vpn works fine... but its probably not the best way to handle it :)

If this could be fixed upstream in a way that doesn't need to comment it
would surely be better.

Thanks


Melhores Cumprimentos // Best Regards
-----------------------------------------------
*Miguel Clara*
*IT - Sys Admin & Developer*
Re: Assertion failed: (a->next->type == IKE_ATTRIB_LIFE_DURATION), function lifetime_ike_process, file vpnc.c, line 1157 [ In reply to ]
On Sat, 2016-08-27 at 14:51 +0100, Miguel C wrote:
>
> I get this issue on FreeBSD, while using psk+xauth (connecting to a
> Fortinet VPN)
>
> I've submitted this to FreeBSD ports, but only now noticed they asked
> to submit this to upstream.
>
> See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206937
>
> For me it just work by commenting the line and so the assert doesn't
> fail, vpn works fine... but its probably not the best way to handle
> it :)
>
> If this could be fixed upstream in a way that doesn't need to comment
> it would surely be better.
>
> Thanks
>

I sent a patch for this about a year ago. Look in the archives for this
list for:

    [PATCH] vpnc: skip parsing responder lifetime payload

Unfortunately, vpnc itself is not being actively maintained so it has
not been merged.

-- 
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: Assertion failed: (a->next->type == IKE_ATTRIB_LIFE_DURATION), function lifetime_ike_process, file vpnc.c, line 1157 [ In reply to ]
Am 04.09.2016 um 13:31 schrieb Jeff Layton:
> I sent a patch for this about a year ago. Look in the archives for this
> list for:
>
> [PATCH] vpnc: skip parsing responder lifetime payload
>
> Unfortunately, vpnc itself is not being actively maintained so it has
> not been merged.

This is really an unfortunate situation. As far as I'm concerned (Fedora
"maintainer") I have a hard to verifying correctness of the patches floating
around and as there is little/no technical discussion about the effects
(security?) I'm very hesitant to put "random" patches in a Fedora package.
I guess many of you remember Debian's openssl debacle.

As a way forward I could envision a github repo where someone brave enough
could collect these patches and tries to get other people to comment if these
patches are safe or not (adding Reviewed-by/Acked-by tags in git). Maybe this
could provide a way to establish a new "upstream" where at least the most
common problems are fixed.

If I see some kind of community and at least a basic review process I guess
Fedora could also import these patches.

Felix

_______________________________________________
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: Assertion failed: (a->next->type == IKE_ATTRIB_LIFE_DURATION), function lifetime_ike_process, file vpnc.c, line 1157 [ In reply to ]
On Sun, 2016-09-04 at 14:07 +0200, Felix Schwarz wrote:
> Am 04.09.2016 um 13:31 schrieb Jeff Layton:
> > I sent a patch for this about a year ago. Look in the archives for this
> > list for:
> >
> >     [PATCH] vpnc: skip parsing responder lifetime payload
> >
> > Unfortunately, vpnc itself is not being actively maintained so it has
> > not been merged.
>
> This is really an unfortunate situation. As far as I'm concerned (Fedora
> "maintainer") I have a hard to verifying correctness of the patches floating
> around and as there is little/no technical discussion about the effects
> (security?) I'm very hesitant to put "random" patches in a Fedora package.
> I guess many of you remember Debian's openssl debacle.
>
> As a way forward I could envision a github repo where someone brave enough
> could collect these patches and tries to get other people to comment if these
> patches are safe or not (adding Reviewed-by/Acked-by tags in git). Maybe this
> could provide a way to establish a new "upstream" where at least the most
> common problems are fixed.
>
> If I see some kind of community and at least a basic review process I guess
> Fedora could also import these patches.

I'm almost tempted to suggest that we add IPSec support to OpenConnect
and start to retire vpnc completely.

I thought about it before, but decided it wasn't a good idea. But that
was a while ago.

Since then, OpenConnect has gained multiple-protocol support, and
supports Juniper Network Connect. Which means it already *has* an ESP
implementation — one which isn't vulnerable to replay attacks, unlike
vpnc's.

It looks like it wouldn't actually take that much work to implement IKE
support in OpenConnect, and use the existing AH/ESP support. that also
gets you a lot of support for hardware and software OTP/OATH,  as well
as making it relatively simple to implement the certificate auth modes,
including full PKCS#11 and TPM support.

I'd start with the basics, and only UDP encapsulation support. Then we
can add the other things as and when it becomes apparent that they're
still relevant in 2016. Do we *really* need support for draft NAT-T
versions that predate the publication of RFC3947 in 2005, for example?

I'#m not volunteering to do it myself, but I'll happily give pointers
to someone who wants to have a go. 

--
dwmw2
Re: Assertion failed: (a->next->type == IKE_ATTRIB_LIFE_DURATION), function lifetime_ike_process, file vpnc.c, line 1157 [ In reply to ]
On Tue, Sep 6, 2016 at 5:11 AM, David Woodhouse <dwmw2@infradead.org> wrote:
>
> On Sun, 2016-09-04 at 14:07 +0200, Felix Schwarz wrote:
> > Am 04.09.2016 um 13:31 schrieb Jeff Layton:
> > > I sent a patch for this about a year ago. Look in the archives for this
> > > list for:
> > >
> > > [PATCH] vpnc: skip parsing responder lifetime payload
> > >
> > > Unfortunately, vpnc itself is not being actively maintained so it has
> > > not been merged.
> >
> > This is really an unfortunate situation. As far as I'm concerned (Fedora
> > "maintainer") I have a hard to verifying correctness of the patches floating
> > around and as there is little/no technical discussion about the effects
> > (security?) I'm very hesitant to put "random" patches in a Fedora package.
> > I guess many of you remember Debian's openssl debacle.

I use vpnc heavily and have encountered several bugs in it. Often,
it's exactly the situation that you describe: I find a years-old patch
from this mailing list that *seems* to fix or at least suppress the
bug, and build my own personal packages to fix it, with little
understanding of the security implications.

One of the well-known bugs is the issue of incorrect endianness in DPD
sequence numbers. Mihai Maties's patch to fix it is extremely simple
(http://lists.unix-ag.uni-kl.de/pipermail/vpnc-devel/2010-December/003492.html),
and the lack of this patch seems to be the source of a substantial
fraction of the vpnc bug reports in various distros and forums.

One of these patches seems
> > As a way forward I could envision a github repo where someone brave enough
> > could collect these patches and tries to get other people to comment if these
> > patches are safe or not (adding Reviewed-by/Acked-by tags in git). Maybe this
> > could provide a way to establish a new "upstream" where at least the most
> > common problems are fixed.
> >
> > If I see some kind of community and at least a basic review process I guess
> > Fedora could also import these patches.
>
> I'm almost tempted to suggest that we add IPSec support to OpenConnect
> and start to retire vpnc completely.
>
> I thought about it before, but decided it wasn't a good idea. But that
> was a while ago.

That would be an ideal solution in my opinion.

In addition to the security and maintainability issues, vpnc users
would also get the more modern command line interface, ocproxy
interface, and better debugging features of OpenConnect. (I'm
constantly wrangling new corporate VPNs, so being able to quickly
understand and diagnose non-standard behavior is a big plus for me!)

Dan
_______________________________________________
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: Assertion failed: (a->next->type == IKE_ATTRIB_LIFE_DURATION), function lifetime_ike_process, file vpnc.c, line 1157 [ In reply to ]
On Tue, 2016-09-06 at 09:37 -0700, Daniel Lenski wrote:
>
> > I'm almost tempted to suggest that we add IPSec support to OpenConnect
> > and start to retire vpnc completely.
> >
> > I thought about it before, but decided it wasn't a good idea. But that
> > was a while ago.
>
> That would be an ideal solution in my opinion.
>
> In addition to the security and maintainability issues, vpnc users
> would also get the more modern command line interface, ocproxy
> interface, and better debugging features of OpenConnect. (I'm
> constantly wrangling new corporate VPNs, so being able to quickly
> understand and diagnose non-standard behavior is a big plus for me!)

Want to give it a go?

It should mostly be fairly straight-forward. There are a couple of
minor complexities, but they shouldn't be hard to handle.

Firstly, just be aware that OpenConnect is licensed under LGPLv2, not
GPLv2. So you can't necessarily just lift code from vpnc and re-use it
without asking the original authors for permission. Although they'll
probably grant it if you ask, and much of the ISAKMP code seems to have
been BSD-licensed anyway.

And some parts you really *want* to rewrite in OpenConnect anyway. For
example the parts in isakmp-pkt.c which use a 'struct flow' to build up
a packet... would want to use OpenConnect's 'struct oc_text_buf', which
is increasingly misnamed as we now use it for building up ASN.1 and all
kinds of other buffers :)


Secondly, we'd want to work out how to fit into the OpenConnect two-
phase connection model — where we first authenticate (with access to
certificates and user interaction for passwords), and then hand off a
"cookie" to the back end to actually make the connection.

Strictly speaking that isn't mandatory — when run from the command line
it *can* just keep all the same connections. But if you want it to run
nicely from NetworkManager without putting extra effort in there, and
especially if you want it to support the various authentication use
cases which are either patched together with baler twine or just plain
not working in NetworkManager-vpnc, we'll want to try to make it fit.

And I think it can. I think we can all of the existing
while(do_load_balance) loop in the authentication phase, and then
everything from do_phase2_qm() in the final connection.

That does mean that we have all the IP config in OpenConnect's
authentication phase, and we'll want to pass that through in the
"cookie". But the cookie is just a free-form opaque string passed from
the authentication phase to the connection phase so that's purely an
internal implementation detail.

I think NAT is sufficiently pervasive that every server ought to be
doing what RFC3947 §7 recommends, and accepting a change of port? So
although you *can* remember the local port number that you used for the
UDP packets from the authentication phase, and you can *try* to bind to
that port again for the connection, it shouldn't actually matter too
much if you do end up on a different port.

I'm also tempted to suggest we never even bother to send from UDP port
500 in the first place; let's just pretend we're *always* behind NAT :)

But some of that obviously depends on how the servers behave, and what
we can get away with.

--
dwmw2
Re: Assertion failed: (a->next->type == IKE_ATTRIB_LIFE_DURATION), function lifetime_ike_process, file vpnc.c, line 1157 [ In reply to ]
What is the current status of this activity?

For an intermediate effort, I would suggest to use the following GitHub repository and incorporate any missing patches etc. there: https://github.com/breiter/vpnc <https://master.mailbutler.io/redirect/4DACECF4-FCCB-4552-88CC-716368920CB3>

What do you think?

> On 7 Sep 2016, at 11:27, David Woodhouse <dwmw2@infradead.org> wrote:
>
> On Tue, 2016-09-06 at 09:37 -0700, Daniel Lenski wrote:
>>
>>> I'm almost tempted to suggest that we add IPSec support to OpenConnect
>>> and start to retire vpnc completely.
>>>
>>> I thought about it before, but decided it wasn't a good idea. But that
>>> was a while ago.
>>
>> That would be an ideal solution in my opinion.
>>
>> In addition to the security and maintainability issues, vpnc users
>> would also get the more modern command line interface, ocproxy
>> interface, and better debugging features of OpenConnect. (I'm
>> constantly wrangling new corporate VPNs, so being able to quickly
>> understand and diagnose non-standard behavior is a big plus for me!)
>
> Want to give it a go?
>
> It should mostly be fairly straight-forward. There are a couple of
> minor complexities, but they shouldn't be hard to handle.
>
> Firstly, just be aware that OpenConnect is licensed under LGPLv2, not
> GPLv2. So you can't necessarily just lift code from vpnc and re-use it
> without asking the original authors for permission. Although they'll
> probably grant it if you ask, and much of the ISAKMP code seems to have
> been BSD-licensed anyway.
>
> And some parts you really *want* to rewrite in OpenConnect anyway. For
> example the parts in isakmp-pkt.c which use a 'struct flow' to build up
> a packet... would want to use OpenConnect's 'struct oc_text_buf', which
> is increasingly misnamed as we now use it for building up ASN.1 and all
> kinds of other buffers :)
>
>
> Secondly, we'd want to work out how to fit into the OpenConnect two-
> phase connection model — where we first authenticate (with access to
> certificates and user interaction for passwords), and then hand off a
> "cookie" to the back end to actually make the connection.
>
> Strictly speaking that isn't mandatory — when run from the command line
> it *can* just keep all the same connections. But if you want it to run
> nicely from NetworkManager without putting extra effort in there, and
> especially if you want it to support the various authentication use
> cases which are either patched together with baler twine or just plain
> not working in NetworkManager-vpnc, we'll want to try to make it fit.
>
> And I think it can. I think we can all of the existing
> while(do_load_balance) loop in the authentication phase, and then
> everything from do_phase2_qm() in the final connection.
>
> That does mean that we have all the IP config in OpenConnect's
> authentication phase, and we'll want to pass that through in the
> "cookie". But the cookie is just a free-form opaque string passed from
> the authentication phase to the connection phase so that's purely an
> internal implementation detail.
>
> I think NAT is sufficiently pervasive that every server ought to be
> doing what RFC3947 §7 recommends, and accepting a change of port? So
> although you *can* remember the local port number that you used for the
> UDP packets from the authentication phase, and you can *try* to bind to
> that port again for the connection, it shouldn't actually matter too
> much if you do end up on a different port.
>
> I'm also tempted to suggest we never even bother to send from UDP port
> 500 in the first place; let's just pretend we're *always* behind NAT :)
>
> But some of that obviously depends on how the servers behave, and what
> we can get away with.
>
> --
> dwmw2_______________________________________________
> 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/