[vpnc-devel] Assertion failed: (a->next->type == IKE_ATTRIB_LIFE_DURATION), function lifetime_ike_process, file vpnc.c, line 1157

[David Woodhouse]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20160907/58df1d02/attachment-0001.bin>