OPENCONNECT(8) | System Manager's Manual | OPENCONNECT(8) |
openconnect - Multi-protocol VPN client, for Cisco AnyConnect VPNs and others
openconnect |
[--config configfile] [-b,--background] [--pid-file pidfile] [-c,--certificate cert] [-e,--cert-expire-warning days] [-k,--sslkey key] [-C,--cookie cookie] [--cookie-on-stdin] [--compression MODE] [-d,--deflate] [-D,--no-deflate] [--force-dpd interval] [--force-trojan interval] [-F,--form-entry form:opt=value] [-g,--usergroup group] [-h,--help] [--http-auth methods] [--external-browser browser] [-i,--interface ifname] [-l,--syslog] [--timestamp] [--passtos] [-U,--setuid user] [--csd-user user] [-m,--mtu mtu] [--base-mtu mtu] [-p,--key-password pass] [-P,--proxy proxyurl] [--proxy-auth methods] [--no-proxy] [--libproxy] [--key-password-from-fsid] [-q,--quiet] [-Q,--queue-len len] [-s,--script vpnc-script] [-S,--script-tun] [-u,--user name] [-V,--version] [-v,--verbose] [-x,--xmlconfig config] [--authgroup group] [--authenticate] [--cookieonly] [--printcookie] [--cafile file] [--disable-ipv6] [--dtls-ciphers list] [--dtls12-ciphers list] [--dtls-local-port port] [--dump-http-traffic] [--no-system-trust] [--pfs] [--no-dtls] [--no-http-keepalive] [--no-passwd] [--no-xmlpost] [--non-inter] [--passwd-on-stdin] [--protocol proto] [--token-mode mode] [--token-secret {secret[,counter]|@file}] [--reconnect-timeout seconds] [--resolve host:ip] [--sni host] [--servercert sha1] [--useragent string] [--version-string string] [--local-hostname string] [--os string] [--server] [https://]host[:port][/group] |
The program openconnect connects to VPN servers which use standard TLS/SSL, DTLS, and ESP protocols for data transport.
It was originally written to support Cisco "AnyConnect" VPN servers, and has since been extended with experimental support for Juniper Network Connect (--protocol=nc), Junos/Ivanti Pulse VPN servers (--protocol=pulse), PAN GlobalProtect VPN servers (--protocol=gp), F5 Big-IP VPN servers (--protocol=f5), Fortinet Fortigate VPN servers (--protocol=fortinet), and Array Networks SSL VPN servers (--protocol=array).
The connection happens in two phases. First there is a simple HTTPS connection over which the user authenticates somehow - by using a certificate, or password or SecurID, etc. Having authenticated, the user is rewarded with an authentication cookie which can be used to make the real VPN connection.
The second phase uses that cookie to connect to a tunnel via HTTPS, and data packets can be passed over the resulting connection. When possible, a UDP tunnel is also configured: AnyConnect uses DTLS, while Juniper and GlobalProtect use UDP-encapsulated ESP. The UDP tunnel may be disabled with --no-dtls, but is preferred when correctly supported by the server and network for performance reasons. (TCP performs poorly and unreliably over TCP-based tunnels; see http://sites.inka.de/~W1011/devel/tcp-tcp.html.)
Any option except the config option may be specified in the file.
The --mca-certificate option sets the secondary certificate for multi-certificate authentication (according to Cisco's terminology, the SSL client certificate is called the "machine" certificate, and the second certificate is called the "user" certificate).
The --mca-key option sets the private key for the secondary certificate (see --mca-certificate).
By default, only stateless compression algorithms which do not maintain state from one packet to the next (and which can be used on UDP transports) are enabled. By setting the mode to all stateful algorithms (currently only zlib deflate) can be enabled. Or all compression can be disabled by setting the mode to none.
DPD mechanisms vary by protocol and by transport (TLS or DTLS/ESP), but are all functionally similar: they enable either the VPN client or the VPN server to transmit a signal to the peer, requesting an immediate reply which can be used to confirm that the link between the two peers is still working.
With some protocols, this path may function as a login group or realm, hence the naming of this option. For example, the following invocations of OpenConnect are equivalent:
openconnect --usergroup=loginPath vpn.server.com openconnect https://vpn.server.com/loginPath
If VALUE is not specified, this option will cause a hidden form field to be treated as a standard text-input field.
This option should not be used to enter passwords. --passwd-on-stdin should be used for that purpose. Not only will this option expose the password value via the OpenConnect process's command line, but unlike --passwd-on-stdin this option will not recognize the case of an incorrect password, and stop trying to re-enter it repeatedly.
--mca-key-password provides the passphrase for the secondary certificate (see --mca-certificate).
stat --file-system --printf=%i\\n $CERTIFICATEIt is not the same as the 128-bit UUID of the file system.
This option sets the maximum inbound and outbound packet queue sizes in OpenConnect itself, which control how many packets will be sent and received in a single batch, as well as affecting other buffering such as the socket send buffer (SO_SNDBUF) for network connections and the OS tunnel device.
Ultimately, the right size for a queue is "just enough packets that it never quite gets empty before more are pushed to it". Any higher than that is simply introducing bufferbloat and additional latency with no benefit. With the default of 32, we are able to saturate a single Gigabit Ethernet from modest hardware, which is more than enough for most VPN users.
If OpenConnect is built with vhost-net support, it will only be used if the queue length is set to 16 or more. This is because vhost-net introduces a small amount of additional latency, but improves total bandwidth quite considerably for those operating at high traffic rates. Thus it makes sense to use it when the user has indicated a preference for bandwidth over latency, by increasing the queue size.
On Windows, a relative directory for the default script will be handled as starting from the directory that the openconnect executable is running from, rather than the current directory. The script will be invoked with the command-based script host cscript.exe.
As an alternative, define the VPN server as non-option command line argument.
Many VPNs require a selection from a dropdown or list during the authentication process. This selection may be known as authgroup (on Cisco VPNs), realm (Juniper, Pulse, Fortinet), domain (F5), and gateway (GlobalProtect). This option attempts to automatically fill the appropriate protocol-specific field with the desired value.
When invoked with this option, OpenConnect will not actually create the VPN connection or configure a tunnel interface, but if successful will print something like the following to stdout:
COOKIE='3311180634@13561856@1339425499@B315A0E29D16C6FD92EE...' HOST='10.0.0.1' CONNECT_URL='https://vpnserver.example.com' FINGERPRINT='469bb424ec8835944d30bc77c77e8fc1d8e23a42' RESOLVE='vpnserver.example.com:10.0.0.1'Thus, you can invoke openconnect as a non-privileged user (with access to the user's PKCS#11 tokens, etc.) for authentication, and then invoke openconnect separately to make the actual connection as root:
eval `openconnect --authenticate https://vpnserver.example.com`; [ -n ["$COOKIE"] ] && echo ["$COOKIE"] | sudo openconnect --cookie-on-stdin $CONNECT_URL --servercert $FINGERPRINT --resolve $RESOLVE
Earlier versions of OpenConnect produced only the HOST variable (containing the numeric server address), and not the CONNECT_URL or RESOLVE variables. Subsequently, we discovered that servers behind proxies may not respond correctly unless the correct DNS name is present in the connection phase, and we added support for VPN protocols where the server URL's path component may be significant in the connection phase, prompting the addition of CONNECT_URL and RESOLVE, and the recommendation to use them as described above. If you are not certain that you are invoking a newer version of OpenConnect which outputs these variables, use the following command-line (compatible with most Bourne shell derivatives) which will work with either a newer or older version:
sudo openconnect --cookie-on-stdin ${CONNECT_URL:-$HOST} --servercert $FINGERPRINT ${RESOLVE:+--resolve=$RESOLVE}
PFS is available in Cisco ASA releases 9.1(2) and higher; a suitable cipher suite may need to be manually enabled by the administrator using the ssl encryption setting.
However, Cisco's support team has failed to give any competent response to the bug report and we don't know under what other circumstances their bug might manifest itself. So this option exists to disable ALL re-use of HTTP sessions and cause a new connection to be made for each request. If your server seems not to be recognizing your certificate, try this option. If it makes a difference, please report this information to the openconnect-devel@lists.infradead.org mailing list.
Some servers will force the client to use such an authentication mode if the client advertises it, but fallback to a more "scriptable" authentication mode if the client doesn't appear to support it.
This option is a temporary safety net, to work around potential compatibility issues with the code which falls back to the old method automatically. It causes OpenConnect to behave more like older versions (4.08 and below) did. If you find that you need to use this option, then you have found a bug in OpenConnect. Please see https://www.infradead.org/openconnect/mail.html and report this to the developers.
This option enables use of these insecure ciphers, as well as the use of SHA1 for server certificate validation.
See https://www.infradead.org/openconnect/protocols.html for details on features and deficiencies of the individual protocols.
OpenConnect does not yet support all of the authentication options used by Pulse, nor does it support Host Checker/TNCC with Pulse. If your Junos/Ivanti Pulse VPN is not yet supported with --protocol=pulse, then --protocol=nc may be a useful fallback option.
RSA SecurID secrets can be specified as an Android/iPhone URI or a raw numeric CTF string (with or without dashes).
For Yubikey OATH the token secret specifies the name of the credential to be used. If not provided, the first OATH credential found on the device will be used.
For OIDC the secret is the bearer token to be used.
FILENAME, if specified, can contain any of the above strings. Or, it can contain a SecurID XML (SDTID) seed.
If this option is omitted, and --token-mode is "rsa", libstoken will try to use the software token seed saved in ~/.stokenrc by the "stoken import" command.
Note that sending different values for the SNI and 'Host:' header violates HTTP standards and is prevented by many cloud hosting providers.
The allowed fingerprint types are SHA1, SHA256, and PIN-SHA256. They are distinguished by the 'sha1:', 'sha256:' and 'pin-sha256:' prefixes to the encoded hash. The first two are custom identifiers providing hex encoding of the peer's public key, while 'pin-sha256:' is the RFC7469 key PIN, which utilizes base64 encoding. To ease certain testing use-cases, a partial match of the hash will also be accepted, if it is at least 4 characters past the prefix.
Some VPN servers may require specific values matching those sent by proprietary VPN clients in order to successfully authenticate or connect. For example, when connecting to a Cisco VPN server, --useragent 'AnyConnect Windows 4.10.06079' or --useragent 'Cisco AnyConnect VPN Agent for Windows 2.2.0133', or when connecting to a Pulse server, --useragent 'Pulse-Secure/9.1.11.6725'.
In the data phase of the connection, the following signals are handled:
See https://www.infradead.org/openconnect/contribute.html for various features that we wish OpenConnect had, and https://www.infradead.org/openconnect/protocols.html for information on the quirks and limitations of the individual VPN protocols.
ocserv(8)
David Woodhouse <dwmw2@infradead.org>