Using OpenConnect instead of Pulse 8.1r7

[Bill Broadley]

On 06/03/2016 03:29 AM, David Woodhouse wrote:
> I'd recommend using GnuTLS instead of OpenSSL.

Ah, and apt install libgnutls-dev and ./configure picked it up.

> This isn't a personal certificate (which would have a corresponding
> private key), issued to you personally, is it? It's "This is the
> certificate which identifies our VPN server; download it because the
> VPN server doesn't have a *proper* certificate that's signed by one of
> the known public CAs."

Ah, sorry, exactly right.

> Right, that really does look like it's the *server's* certificate. So
> you'd want to use that with '--cafile vpn.example.com.pem'. Although I
> don't see a complaint in your log that the server's certificate wasn't
> accepted, so you might not need it.

I tried it and got a fair number of ugly messages.
POST https://vpn.example.com/dana-na/auth/url_3/login.cgi
SSL negotiation with vpn.example.com
Server certificate verify failed: signer not found
Connected to HTTPS on vpn.example.com
Got HTTP response: HTTP/1.1 302 Moved
GET 
https://vpn.example.com/dana-na/auth/url_3/welcome.cgi?p=user-confirm&id=state_bf19b7b3273c5cf1cb0cb
SSL negotiation with vpn.example.com
Server certificate verify failed: signer not found

But I was very pleased to see that it worked.  If I added --cafile:
OST https://vpn.example.com/dana-na/auth/url_3/login.cgi
SSL negotiation with vpn.example.com
Connected to HTTPS on vpn.example.com
Got HTTP response: HTTP/1.1 302 Moved
GET 
https://vpn.example.com/dana-na/auth/url_3/welcome.cgi?p=user-confirm&id=state_8eb656c722f82e1077
SSL negotiation with vpn.example.com
Connected to HTTPS on vpn.example.com

And that worked a well, perfect.

> Using the stock OpenConnect 7.06 (using GnuTLS) on Fedora 24, it works
> for me when I connect to what I think is your 'vpn.example.com'...

Ah, I mistakenly thought I needed the recently committed --proto flag.

I can confirm that OpenConnect 7.06 that comes with Ubuntu 16.04 also works.

> At this point if I had a username and password it looks like I should
> be able to proceed and get at least Legacy IP connectivity (we need to
> implement the Pulse protocol before we get IPv6).

I tried a my username/pass and it worked.  I ssh'd into a host and 
verified my IPv4 address was from the VPN pool and not the address of my 
local client.  So I'm successfully VPN'd into the remote network without 
using an unsigned proprietary 32 bit binary.

>> My end goal is to get a Puppet managed OpenConnect working for linux
>> clients that enables IPv4 and IPv6.
>
> You'll be using NetworkManager, I assume? So Puppet would be poking the
> NM configuration into place with 'nmcli con add ...'?

Turns out even using Pulse I'm not getting IPv6, I suspect he vpn server 
doesn't have IPv6 connectivity.  IPv6 adoption is still pretty early 
there.  Hopefully by whispering in the right ear I can get that fixed.

The closest things I've done so far are tweaking the firewall settings 
with the puppetlabs supported firewall module, and a small tweak to 
networkmanager.conf to choose unbound for the local resolver.  Now that 
it works I'll dig around for potential solutions.  A GUI wrapper will be 
needed for the Username/Password and a nice user friendly enable/disable 
VPN button.  If network manager can be prodded into doing that all the 
better.

Many thanks for the help, I'll tinker with puppetizing it.