How the VPN works

Openconnect VPN server is an Internet-layer VPN server. That is, it provides the client with an IP address and a list of routes that this IP may access. Since this is not a Link-layer VPN a separate subnet must be allocated for the VPN addresses.

The subnet addresses are specified by the 'ipv4-network' and 'ipv4-netmask' configuration options (and the corresponding ipv6 options). The routes that are pushed to the client are specified by the 'route' option. For each client two IPv4 addresses are assigned, its VPN address and its local image (remember this is a point-to-point connection). The image isn't known to the client (the anyconnect protocol doesn't forward it).

Note that ocserv doesn't do any packet forwarding or filtering between the networks. It is expected that the server has any required routes or firewall rules, set up. You may conditionally enable firewall rules, or even enable routing rules through the client using the 'connect-script' and 'disconnect-script' scripts based on the user who connected. Note that it is important for these scripts not to hang, and terminate without long delays. You may find some examples in the scripts/ directory.

Authentication

Authentication in openconnect VPN server occurs in the initial HTTP over TLS session. In that session the client is provided with an XML authentication page. The server is authenticated using its certificate and the client, either by its certificate, or via a username and password pair which are forwarded to PAM, or a combination of both password and certificate. Because PAM supports various authentication types, the password entered by the user could be a one-time-password or whatever else supported by PAM. After the user is authenticated he is provided with a cookie that can be used for future connections. The lifetime of the cookie is configurable using the 'cookie-validity' option, and is renewed on every client connection.

After the user is authenticated, directly, or via the cookie, he issues a CONNECT HTTP command over the established TLS session which results to a direct connection with the VPN. Additionally the user could connect using UDP and Datagram TLS. That connection is authenticated using session resumption and a master key provided by the server.

No compression

This server supports no compression by default. While this may be awkward to be listed as a feature, there can be very efficient plaintext recovery attacks on TLS when compression is enabled. These attacks can be even more powerful in a VPN setting. For this reason compression is disabled, and we are considering other approaches to allow operation on bandwidth limited systems.

Valid XHTML 1.0! Valid CSS!