Skip to content

Useragent string not being detected by ocserv

Created by: ibrawley

The OpenConnect-GUI for Windows calls (I presume) openconnect.exe. But along the way, the useragent string is being set to "OpenConnect-GUI 1.5.3...." which isn't being detected as being an OpenCOnnect client by ocserv (see the switch statement handle the user agent header in the header_value_check() function in worker_http.c for ocserv).

Would it be possible when calling openconnect.exe, it uses the option '--useragent "OpenConnect VPN Agent ....."' so that it can be detected?

Another fix could be for ocserv to detect openconnect-gui's useragent string as well (will be sending an email to their list about that shortly).

The reason is because of the way that ocserv handles IPv6 compatibility. When the user agent is detected as not being OC, IPv6 isn't fully functional.

There are actually three things that aren't what is expected... (1) OC-GUI presenting itself as not being "OpenConnect VPN Agent" (2) ocserv not detecting OC-GUI being an OpenConnect client and so not providing full IPv6 split routes, etc properly (3) There is also a bug in vpnc-script.js in how it handles IPv6 split routes. When iterating through adding the routes, it uses "CISCO_SPLIT_INC_ind_MASKLEN" instead of "CISCO_IPV6_SPLIT_ind_MASKLEN".

Specifications

  • Version: OpenConnect-GUI 1.5.3 (built 25-Mar-2018)
  • Platform: Windows 10 (64 bit)

Steps to Reproduce the Issue

  1. Try connecting to ocserv server that is doing split IPv6 routes using OpenConnect-GUI.
  2. Use OpenConnect-GUI to connect to an ocserv server, checkout logs to see UserAgent

Expected Behavior

Expected behaviour is that the client will be offered the IPv6 split routes from the server (which it doesn't because the server believes that it isn't an OpenConnect client (though it does give an IPv6 address)) and for the client to add those routes correctly.

Actual Behavior

Currently the ocserv server will not detect the client as being an OpenConnect client so parses out the IPv6 split routes and doesn't offer them to the client. The client then, seeing no routes, will set a pseudo default IPv6 route of 2000::/3 through the tunnel instead.

I have a small patch to ocserv that will match on the "OpenConnect-GUI" user agent, but then I see the the next issue with vpnc-script.js using the wrong subnet masks when adding the IPv6 routes.