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.
