Trouble with network-manager-openconnect-gnome when using a gateway with multiple IP addresses

David Woodhouse dwmw2 at
Sun Feb 3 16:14:07 EST 2013

On Sun, 2013-02-03 at 04:18 -0500, Brian D Peyser PhD wrote:
> I noticed that when I tried to connect repeatedly, the IP address
> sometimes changed (and I would get different server certificates). There
> are apparently multiple IPs for the same host name. That finally gave me
> an idea, and I just made a connection with one of the IP addresses for
> the gateway instead of the "correct" hostname. I got a dialog asking if
> I would accept the certificate, I accepted it, and it connected! I'm not
> sure where the problem is, but at least it is working for now.

Right. What happens is the GUI side will connect to the server and do
the proper certificate validation (including asking the user if
necessary). Then it hands off three pieces of information to the
openconnect process that's run to make the actual connection — the
server's hostname, a SHA1 of the SSL certificate, and the webvpn cookie
which is what's used to authenticate.

If you have multiple different servers on a single round-robin DNS name,
that explains why you see this problem. When it makes the final
connection, it gets a *different* server to the one it used for
authentication, and the SHA1 of the cert obviously doesn't match.

The fix for this isn't in the nm-auth-dialog; it's in openconnect
itself. We already update vpninfo->hostname when we get HTTP redirects
for load balancing, etc.  We should also update it in
connect_https_socket() in ssl.c, to contain a numeric IP address, if
we've had to do a DNS lookup there. That'll ensure that any future
reconnections are to the *same* host.

I'll have a look at that and give you a patch to test... maybe tomorrow.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <>

More information about the openconnect-devel mailing list