testing a new SSL+ESP VPN

[David Woodhouse]

On Tue, 2016-10-04 at 09:13 -0500, Daniel Lenski wrote:
> Hi all,
> 
> I've encountered a new flavor of corporate VPN, and I followed some of
> the helpful advice given on this list for supporting the Juniper VPN
> (http://openconnect-devel.infradead.narkive.com/ZPtB8Gyt/compatibility-with-juniper-ssl-vpn).
> 
> A bit of work with mitmproxy and Wireshark show me that this one is
> very similar to the Juniper VPN which OpenConnect already supports, at
> least in the configuration that I have access to:
> 
>     1. Client submits a simple HTTPS form with username and password
> to https://gateway.company.com/ssl-vpn/login.esp
>     2. Server returns a random authentication cookie
>     3. Client submits a form with the cookie to
> https://gateway.company.com/ssl-vpn/getconfig.esp
>     4. Server returns an XML configuration file, which contains:
>         a) The usual routing information
>         b) An IPsec configuration section with algorithms and specific
> keys and SPIs to use
>     4. Client and server stop talking TLS and start communicating via
> UDP-encapsulated-ESP

Sounds like you've made good progress with understanding this.

What happens if the ESP channel *cannot* be established? Does it keep
talking over TCP? That's one of the main advantages of an SSL VPN,
surely?

For Juniper, I got the TCP mode working, and *then* added ESP support.

> I would be very glad to add support for this authentication process
> VPN to OpenConnect, but first I would like to try to play around with
> connecting to it "manually" to verify that I understand its operation
> correctly and am not overlooking anything important.
> 
> Is there a good way to create a UDP-encapsulated-ESP tunnel using
> Linux command line tools, and setup the keys and routing for it
> manually to test whether it works properly? Or is there an easy way to
> adapt the openconnect source code to do this?

It can be done with 'ip xfrm', something like this:
https://gist.github.com/vishvananda/7094676

You might do better just to go ahead and add it to OpenConnect though.
Forget the HTTPS and XML config part for now; just hard-code it for now
so that 'obtain_cookie' and other methods do nothing but return
success, and set up an ESP connection with *fixed* parameters from your
manual testing. Then you can flesh out the HTTPS/XML parts later, if
you want to do it in that order.

The ESP parts of OpenConnect are *mostly* generic, without any Juniper-
specific bits in them. The main case I see where that's *not* true is
where we use Juniper-specific numbering in vpninfo->esp_enc and
vpninfo->esp_hmac, and the trick where we send zero-length data packets
as a probe, and expect those back from the server before we consider
the connection 'established' over UDP.

-- 
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/20161004/f299d33b/attachment-0001.bin>