On Mon, 2013-02-04 at 23:34 +0000, David Woodhouse wrote:
> On Mon, 2013-02-04 at 18:21 -0500, Brian D Peyser PhD wrote:
> > $ openconnect --script=/etc/vpnc/vpnc-script remoteaccessvpn.nih.gov
> ...
> > TUNSETIFF failed: Operation not permitted
>
> That's expected, if you're not running it as root. Everything worked OK,
> but it wasn't able to create and configure the tunnel network device.
>
> But it would have worked from the command line anyway. It was caching
> the result of the DNS lookup and using the same IP address every time it
> had to make a new connection, so you'd never have seen the original
> issue there. It was only when you had the *separate* authentication and
> connection stages (for example with the NM GUI, or using openconnect
> --authenticate followed by
> openconnect -C $COOKIE --servercert $FINGERPRINT $HOST
>
Yes, I ran again as root and it worked fine from the command line. I'm a
bit of a goof.
> > When I try to use the Network-Manager-openconnect GUI I get a segfault.
>
> That shouldn't happen. First thing I'd do is check that you aren't
> mixing versions. If you just ran './configure' then it probably installs
> to /usr/local, leaving the packaged versions in place? Try adding
> --prefix=/usr to the configure command line?
>
When I ran 'locate openconnect' it found /usr/sbin/openconnect:
$ /usr/sbin/openconnect --version
WARNING: This version of openconnect is v4.06 but
the libopenconnect library is v4.07-90-gb37161f
OpenConnect version v4.07-90-gb37161f
Using GnuTLS. Features present: DTLS (using OpenSSL)
$ /usr/local/sbin/openconnect --version
OpenConnect version v4.07-90-gb37161f
Using OpenSSL. Features present: TPM (OpenSSL ENGINE not present), DTLS
So it seems I did have the earlier version in /usr/sbin/openconnect
I did
$ ./configure --prefix=/usr
$ sudo make uninstall
$ ./configure
$ sudo make uninstall
$ ./configure --prefix=/usr
$ make
$ sudo make install
and it installed to /usr/sbin/ with the old version gone.
Now it still doesn't work from Network Manager, but the error in syslog
has changed:
Feb 4 22:17:15 S076804 NetworkManager[1437]: <info> VPN plugin state changed: starting (3)
Feb 4 22:17:15 S076804 NetworkManager[1437]: <info> VPN connection 'NIH Remote Access' (Connect) reply received.
Feb 4 22:17:15 S076804 NetworkManager[1437]: <warn> VPN plugin failed: 1
Feb 4 22:17:15 S076804 NetworkManager[1437]: <info> VPN plugin state changed: stopped (6)
Feb 4 22:17:15 S076804 NetworkManager[1437]: <info> VPN plugin state change reason: 0
Feb 4 22:17:15 S076804 NetworkManager[1437]: <warn> error disconnecting VPN: Could not process the request because no VPN connection was active.
Feb 4 22:17:15 S076804 NetworkManager[1437]: <info> Policy set 'XXXX' (wlan0) as default for IPv4 routing and DNS.
Feb 4 22:17:16 S076804 NetworkManager[1437]: keyfile: updating /etc/NetworkManager/system-connections/NIH Remote Access
The VPN plugin fails, but it no longer complains about the server SSL
certificate. However, it is not working from the command line now:
$ sudo openconnect remoteaccessvpn.nih.gov
openconnect: /usr/lib/x86_64-linux-gnu/libopenconnect.so.2: version `OPENCONNECT_2.1' not found (required by openconnect)
$ sudo find / -name libopenconnect.so.2
/usr/lib/libopenconnect.so.2
/usr/lib/x86_64-linux-gnu/libopenconnect.so.2
$ ll /usr/lib/libopenconnect.so.2
lrwxrwxrwx 1 root root 23 Feb 4 22:14 /usr/lib/libopenconnect.so.2 -> libopenconnect.so.2.1.0*
$ ll /usr/lib/x86_64-linux-gnu/libopenconnect.so.2
lrwxrwxrwx 1 root root 23 Aug 14 08:46 /usr/lib/x86_64-linux-gnu/libopenconnect.so.2 -> libopenconnect.so.2.0.0
So it looked like there was an old version of libopenconnect.so.2 that
was messing it up when I actually used the patched openconnect version.
$ sudo rm /usr/lib/x86_64-linux-gnu/libopenconnect.so
$ sudo cp /usr/lib/libopenconnect.so.2.1.0 /usr/lib/x86_64-linux-gnu/
$ sudo ln -s /usr/lib/x86_64-linux-gnu/libopenconnect.so.2.1.0 /usr/lib/x86_64-linux-gnu/libopenconnect.so
Now it runs from command line, and worked from Network Manager the first
try. I tried another time, and it failed. Relevant syslog:
Feb 5 09:54:41 S076804 NetworkManager[1437]: <info> Starting VPN service 'openconnect'...
Feb 5 09:54:41 S076804 NetworkManager[1437]: <info> VPN service 'openconnect' started (org.freedesktop.NetworkManager.openconnect), PID 16029
Feb 5 09:54:41 S076804 NetworkManager[1437]: <info> VPN service 'openconnect' appeared; activating connections
Feb 5 09:55:13 S076804 NetworkManager[1437]: <info> VPN plugin state changed: starting (3)
Feb 5 09:55:13 S076804 NetworkManager[1437]: <info> VPN connection 'NIH Remote Access' (Connect) reply received.
Feb 5 09:55:13 S076804 openconnect[16038]: Attempting to connect to server 156.40.250.131:443
Feb 5 09:55:13 S076804 openconnect[16038]: SSL negotiation with 156.40.250.131
Feb 5 09:55:13 S076804 openconnect[16038]: Server SSL certificate didn't match: 62283086430A2E57E1F7A2AAD9D666A86F10C0ED
Feb 5 09:55:13 S076804 NetworkManager[1437]: <warn> VPN plugin failed: 1
Feb 5 09:55:13 S076804 NetworkManager[1437]: <info> VPN plugin state changed: stopped (6)
Feb 5 09:55:13 S076804 NetworkManager[1437]: <info> VPN plugin state change reason: 0
Feb 5 09:55:13 S076804 NetworkManager[1437]: <warn> error disconnecting VPN: Could not process the request because no VPN connection was active.
Feb 5 09:55:13 S076804 NetworkManager[1437]: <info> Policy set 'Wired connection 1' (eth0) as default for IPv4 routing and DNS.
Feb 5 09:55:14 S076804 NetworkManager[1437]: keyfile: updating /etc/NetworkManager/system-connections/NIH Remote Access
Feb 5 09:55:18 S076804 NetworkManager[1437]: <info> VPN service 'openconnect' disappeared
I tried deleting the VPN connection from the Network Manager GUI and
making a new one, then I tried again. It brought up a dialog about not
recognizing the cert, I accepted it, then logged in and it failed. I got
the following in syslog:
Feb 5 10:00:27 S076804 openconnect[16097]: Server SSL certificate didn't match: 269123E181C7D9F3BE5AF8279FBBF7F66AF5D01D
I looked in /etc/NetworkManager/system-connections/NIH\ Remote\ Access
(which is the name of my connection):
...etc.
[vpn-secrets]
certsigs=7DC36D7822AE2044CC635249FDF4DD002AA52AFE
...etc.
So it got a different cert when it asked me to accept than when
openconnect checked. I repeated attempts to connect and eventually ended
up with something like:
Feb 5 11:51:12 S076804 openconnect[20965]: Server SSL certificate didn't match: 62283086430A2E57E1F7A2AAD9D666A86F10C0ED
While my system-connections file had:
certsigs=7DC36D7822AE2044CC635249FDF4DD002AA52AFE 324FDA4745B2C6DA5D7850ECA5F85BD88DA18C29 62283086430A2E57E1F7A2AAD9D666A86F10C0ED
Again, I tried doing command line connection and it worked! This time
using the two-step connection process:
$ eval `openconnect --authenticate https://remoteaccessvpn.nih.gov`
Attempting to connect to server 156.40.250.131:443
SSL negotiation with 156.40.250.131
Server certificate verify failed: unable to get local issuer certificate
Certificate from VPN server "156.40.250.131" failed verification.
Reason: unable to get local issuer certificate
Enter 'yes' to accept, 'no' to abort; anything else to view: yes
Connected to HTTPS on 156.40.250.131
POST https://156.40.250.131/
Got HTTP response: HTTP/1.0 302 Object Moved
SSL negotiation with 156.40.250.131
Server certificate verify failed: unable to get local issuer certificate
Connected to HTTPS on 156.40.250.131
GET https://156.40.250.131/+webvpn+/index.html
Please enter your username and password.
Username: XXXX
Password:
POST https://156.40.250.131/+webvpn+/index.html
$ [ -n $COOKIE ] && echo $COOKIE |
> sudo openconnect --cookie-on-stdin $HOST --servercert $FINGERPRINT
Attempting to connect to server 156.40.250.131:443
SSL negotiation with 156.40.250.131
Connected to HTTPS on 156.40.250.131
Got CONNECT response: HTTP/1.1 200 OK
CSTP connected. DPD 30, Keepalive 480
Connected tun0 as 129.43.230.49, using SSL
Established DTLS connection (using OpenSSL)
^CSend BYE packet: Client received SIGINT
$ echo $HOST
156.40.250.131
So this apparently works correctly with the patched version. It returns
the IP address as $HOST and not the hostname. However, when it runs from
the old network-manager-openconnect it doesn't work.
> And run 'ldd /usr/libexec/nm-openconnect-auth-dialog' (or wherever
> Ubuntu puts it) to check which version of the library it's running.
>
I ran that:
$ ldd /usr/lib/NetworkManager/nm-openconnect-auth-dialog | grep openconnect
libopenconnect.so.1 => /usr/lib/libopenconnect.so.1 (0x00007f798364e000)
It seems the network-manager-openconnect from Ubuntu 12.04 (v0.9.4.0) is
failing here since it doesn't use the new library. Correct?
I'd guess what I need to do is compile a new version of at least
network-manager-openconnect and network-manager-openconnect-gnome. Maybe
even more of those components, like network-manager (v0.9.4.0) and
network-manager-gnome (v0.9.4.1).
Any pointers on what I should try? I am planning on going back to the
old version for now in Ubuntu 12.04 and just picking one IP address to
use, but will set up a Fedora VM to see if an updated Network-Manager
plugin will make the difference here.
Since I am going back to the old version, I tried to run the command
line two-step authentication/connection to make sure that failed as
expected:
$ openconnect --version
OpenConnect version v3.15
$ eval `openconnect --authenticate https://remoteaccessvpn.nih.gov`
openconnect: unrecognized option '--authenticate'
bash: syntax error near unexpected token `('
Apparently the old version in Ubunutu 12.04 doesn't have the
'--authenticate' option. I tried '--cookieonly' but that just returns
the cookie, no $HOST or $FINGERPRINT. So I used the version in the PPA
on my other machine (also Ubuntu 12.04):
$ openconnect --version
OpenConnect version v4.06
Using GnuTLS. Features present: PKCS#11, DTLS (using OpenSSL)
Using that version, I got:
$ echo $HOST
remoteaccessvpn.nih.gov
I connected several times using that version with the command line
two-step process, but then I got a "Server SSL certificate didn't match:
blahblahblah" error when the server/fingerprint were mismatched. I guess
it just depends on whether I was lucky enough to get the same server for
both steps.
So, short conclusion is that I need updated Network Manager components
along with the patched openconnect. The patched openconnect
(v4.07-90-gb37161f) seems to work correctly for this use-case now!
