Creating a VPN connection on Ubuntu with OpenConnect

Remote access to a workplace or study network is a common need on Ubuntu, especially when the files, dashboards and internal tools involved sit behind an organisation’s security perimeter. OpenConnect provides a free, open-source client for compatible Cisco AnyConnect and related gateways, while NetworkManager turns it into a desktop connection that behaves like Wi-Fi or Ethernet. The graphical and terminal routes both lead to the same encrypted tunnel, but the certificate and routing checks often determine whether the connection is genuinely secure.

Australian users may encounter these tools on an NBN connection at home, a Telstra or Optus mobile hotspot, or a managed work laptop. The consumer market offers many paid subscriptions, but workplace access usually depends on an employer-managed account, approved gateway and supplied second-factor method. That distinction matters: a commercial privacy service and a workplace remote-access system may share the word VPN while offering completely different levels of control, support and logging.

Local network conditions also shape the experience. A café near Brisbane’s Queen Street Mall or public Wi-Fi at Melbourne Airport may be convenient for a workday, although a captive sign-in page must be completed before the tunnel can start. Many Australian fixed-line IPv4 connections sit behind carrier-grade NAT, which is usually fine for outbound traffic but can prevent an inbound connection to a service on the same home network. IPv6 support varies by internet provider and access plan.

Support arrangements can cross time zones: Perth sits three hours behind Sydney during Australian standard time, and many workplace support windows follow eastern-state hours. The conversational local tone helps—Australians often use “no worries” or “give it a go” when something needs another attempt—but a precise error message is still the fastest route to a fix. The useful starting point is to gather the gateway details, establish trust in the server certificate and create one test profile before adjusting routes or adding extra clients.

Gather the gateway and authentication details

Start with the instructions supplied by your employer or institution, not a guessed hostname. You normally need the exact gateway address, account name, password or approved second factor, and the protocol expected by the service. A portal page may describe the service as Cisco AnyConnect, Cisco Secure Client, GlobalProtect or Pulse, while the administrator may separately provide instructions for an OpenConnect-compatible setup.

Credentials often have more than one layer. A password may be followed by a time-based code from an authenticator app, while some organisations require a certificate issued to the device. If the gateway uses a company certificate authority, install the organisation’s CA certificate before attempting sign-in; otherwise OpenConnect may correctly reject the server even when its address is right. Keep the issued file and its passphrase in the approved password manager, not in a chat message.

A workplace administrator can provide a PEM-encoded CA certificate. On Ubuntu, a file such as company-vpn-ca.crt can be copied into the system trust store with:

sudo cp company-vpn-ca.crt /usr/local/share/ca-certificates/company-vpn-ca.crt
sudo update-ca-certificates

If IT manages the computer through deployment tools, that process may already be complete. Never bypass hostname or certificate validation merely to make an error disappear: that check protects the credentials and traffic sent to the gateway.

Install OpenConnect and create a desktop profile

Ubuntu’s NetworkManager provides the most convenient route. Install the OpenConnect plug-in and client from the repositories:

sudo apt update
sudo apt install network-manager-openconnect openconnect

The package named network-manager-openconnect supplies the desktop integration, while openconnect provides the underlying command-line program. Installing both is useful for a normal desktop and for diagnosing a profile outside the graphical interface.

Open Settings, choose Network and add a VPN connection. Select OpenConnect as the provider, enter the exact gateway address supplied by your administrator, and give the profile a clear name such as “Work VPN”. Choose the matching protocol when the field is not set to automatic. Save the profile, activate it and enter the account credentials when prompted. A separate client certificate should only be selected when your organisation has issued one and supplied the expected format.

The terminal path is handy when the desktop interface does not expose a needed option. For a Cisco-compatible gateway, replace the placeholder with the address from your portal and run:

export GATEWAY='address supplied by your portal'
sudo openconnect --protocol=ocsp "$GATEWAY"

OpenConnect will ask for the username, password and any required second factor. Avoid placing a password directly in the command, since shell history and process listings can expose it. Other vendors may require a different protocol setting; the administrator’s documentation should specify that rather than leaving you to guess.

Connect the tunnel and confirm its routes

Activate the saved profile from the system menu or run nmcli connection up "Work VPN". A successful connection should appear as active in nmcli connection show --active. OpenConnect generally receives its routes and DNS configuration from the gateway through NetworkManager. Depending on the organisation’s policy, it may send all traffic through the encrypted tunnel or route only internal addresses while ordinary browsing continues directly.

That routing choice affects which internal resources you can reach. For teams already hosting a Git server on an office machine, the VPN must also carry traffic to that server’s private address; the server’s internet-facing repository is a different path altogether. Split-tunnel rules can also leave shared printers or local management pages unreachable if their address ranges were not included by the administrator.

Check the result rather than trusting the padlock icon alone. Run ip route, ip -brief address and resolvectl status to look for the tunnel interface, expected routes and VPN-provided DNS. An IP lookup service in a browser can reveal the address seen outside the connection. If an internal hostname resolves but does not open, the problem may be routing rather than encryption; if public sites work but internal names do not, inspect DNS. IPv6 deserves a separate check when the server sends only IPv4 routes.

Protect credentials and keep access predictable

Desktop VPN profiles can remember a secret in the login keyring, but a saved password is still a local credential. On a shared or travel computer, prefer an approved certificate, smart card or one-time access method, and lock the session when the machine is unattended. Automatic reconnection is convenient for a work laptop, yet it should follow the organisation’s policy on untrusted networks. Disconnecting is explicit: nmcli connection down "Work VPN" or the network menu’s switch ends the tunnel.

Keep the client, trust certificates and account details aligned with the gateway’s updates. A retired gateway, expired certificate or changed multi-factor method can produce an error that looks like a local network fault. Check the device clock with timedatectl, because time-based codes and valid certificates fail when the clock drifts. If an old AnyConnect service now requires a newer client, use the supported replacement rather than weakening certificate checks.

Also separate a working tunnel from assumptions about privacy. The internet service provider can usually see that traffic is going to a gateway, while the gateway operator handles the rest of the connection. Company systems may keep audit records, and a VPN does not make an activity lawful or exempt it from workplace policy. For home users, the commercial VPN market includes both subscription and limited free services, so the data and logging terms deserve the same attention as the price.

If the client seems to leave a process running after its window closes, stopping background processes can clear a stale session before you restart NetworkManager. This is useful when a password prompt never returns, but confirm which process belongs to the VPN rather than terminating an unrelated system service.

Troubleshoot failures and make the first test

Start by classifying the failure. A captive portal on airport or hotel Wi-Fi must be accepted in a browser first. A timeout before any credential prompt points towards the gateway address, firewall or network; a certificate error points towards trust or time; a rejected password or expired code points towards the account; and a connection that succeeds but cannot reach an internal service usually points towards routing or DNS. In Australia, switching between fixed-line broadband and a Telstra or Optus hotspot can isolate the network, while watching mobile data allowances and fair-use limits.

For a visible clue, inspect the latest NetworkManager entries with journalctl -u NetworkManager --no-pager. The same profile can also be run directly with the terminal command from earlier, which prints more detail about TLS, authentication and server negotiation. Keep any test brief, and avoid repeatedly entering credentials into an unverified page. Regional travel beyond Perth, Adelaide or Melbourne can expose mobile coverage gaps, so an offline copy of essential documents is more useful than a perfect signal.

Before leaving the setup session, test both required outcomes: an internal resource that only the corporate network can reach and an internal hostname that relies on workplace DNS. Record the gateway address, certificate details and any second-factor instructions in the organisation’s approved password manager. The concrete next step is an authenticated test of one profile created with the exact gateway address and CA certificate from your administrator.