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>
