Configure Linux OpenConnect towards Clavister NetWall

What is OpenConnect?

OpenConnect is both a protocol and an open source project for creating SSL VPN clients that are compatible with multiple types of remote SSL VPN servers. Such clients are compatible with the Clavister OneConnect interface feature in Clavister cOS Core. More details about the protocol can be found at http://www.infradead.org/openconnect/. On Linux there are two clients: the command line client (the openconnect package) and the graphical client (the GNOME NetworkManager OpenConnect plugin). This guide covers both, and shows how the firewall confirms the user is logged in.

Installing the OpenConnect client

Install OpenConnect according to whether Linux or Unix is being used. Pre-compiled binaries are available for Debian, Ubuntu and Fedora. For other operating systems such as NetBSD, FreeBSD and Solaris, it can be compiled from the source code or using NetBSD pkgsrc.

# Debian and Ubuntu, command line client
sudo apt install openconnect

# Graphical client (NetworkManager integration)
sudo apt install network-manager-openconnect-gnome

The server certificate

The OneConnect interface presents a server certificate during the TLS handshake. The certificate must be a complete server certificate, imported together with its private key, and its Common Name (CN) or one of the Subject Alternative Names (SAN) must match the address that clients use to reach the server.

If the certificate is not suitable, the TLS handshake fails before the OneConnect layer runs. In that case the firewall writes no connection log, and a packet capture on the client shows only a few packets with no useful reply. This is a common reason a OneConnect server appears to do nothing when a client connects. Install a valid certificate from your CA whose name matches the public name of the VPN service, and assign it to the OneConnect interface.

Connecting using the command line client

Connect to Clavister NetWall by typing openconnect https://hostname in a shell.

Note: The hostname entered must be the same as either the Common Name (CN) or one of the Subject Alternative Name (SAN) of the certificate used by the OneConnect interface in cOS Core.

Connection Example

root@linux:~# openconnect https://myvpn.mydomain.tld
POST https://myvpn.mydomain.tld
Connected to 192.0.2.10:443
SSL negotiation with myvpn.mydomain.tld
Server certificate verify failed: signer not found

Certificate from VPN server "myvpn.mydomain.tld" failed verification.
Reason: signer not found
To trust this server in future, perhaps add this to your command line:
    --servercert pin-sha256:PUNgII37RWw2NGMqumSkqDAfQBPPKaIUuVJYT8FneeY=
Enter 'yes' to accept, 'no' to abort; anything else to view: yes
Connected to HTTPS on myvpn.mydomain.tld
XML POST enabled
Please enter your username
Username:user
POST https://myvpn.mydomain.tld/auth
Please enter your password
Password:
POST https://myvpn.mydomain.tld/auth
Got CONNECT response: HTTP/1.1 200 CONNECTED
CSTP connected. DPD 30, Keepalive 32400
Connected as 172.28.1.200, using SSL, with DTLS in progress
Established DTLS connection (using GnuTLS). Ciphersuite (DTLS1.2)-(ECDHE-RSA)-(AES-128-GCM).

For a self-signed certificate you can pin it directly instead of accepting it interactively:

openconnect --servercert pin-sha256:<hash> https://myvpn.mydomain.tld

Authentication methods

The OneConnect interface authentication source is set on the firewall. The standard Linux client works with all of the following.

RADIUS with a one-time code (multi factor)

When the RADIUS server is set up to return a challenge, the client asks for the password first and then for the one-time code. The login looks like this:

Password: ********
Enter your 6-digit passcode:
Got CONNECT response: HTTP/1.1 200 CONNECTED
CSTP connected.
Connected as 10.99.0.10, using SSL

On the firewall side this is the standard RADIUS Access-Challenge flow: the first request checks the password and the server replies with a challenge, the second request carries the one-time code and the server accepts it. The native Linux client handles the second prompt without any extra software.

Graphical client (NetworkManager)

Add a new VPN connection of type OpenConnect and set the Gateway to the server address. Select the OpenConnect option in the VPN Protocol list.

The NetworkManager OpenConnect connection, with the OpenConnect protocol selected and the Gateway set to the firewall address.

Start the connection. The client opens a dialog, shows the server certificate for confirmation, and asks for the credentials. After you accept the certificate and sign in, the tunnel is established. The graphical client uses the same OpenConnect engine as the command line client.

Verifying on the firewall

When a client is connected, the firewall lists the user. In the Web Interface, go to Status > User Authentication.

User Authentication Status showing the connected user, the assigned tunnel address, and the OneConnect interface.

From the CLI the same information is available with:

Device:/> userauth -list

Notes and troubleshooting

• The address entered in the client must match the Common Name or a Subject Alternative Name of the certificate used by the OneConnect interface.
• No log and no tunnel, only a few packets in a capture, points to a TLS handshake that fails because of an unsuitable server certificate. Install a proper certificate and assign it to the interface.
• No protocol flag is required. The OpenConnect client uses the correct protocol automatically.
• DTLS over UDP improves performance. If UDP is blocked on the path, the tunnel still works over TLS only.

Related articles