You can configure a split-tunnel VPN with OpenConnect and NetworkManager by explicitly defining static IPv4 routes in the connection profile. This approach ensures that only traffic destined for specific corporate subnets is routed through the tunnel, while all other internet traffic remains on your local network interface.
Understanding Split-Tunnel Routing
A standard VPN configuration typically pushes a default route (0.0.0.0/0) to the client, forcing all internet traffic through the encrypted tunnel. While this provides maximum security, it often leads to performance issues and breaks access to local resources like printers or LAN devices. A split-tunnel configuration allows you to maintain high-speed local internet access while securely reaching internal company resources.
To achieve this, you must prevent NetworkManager from accepting the server’s default route and instead manually specify which subnets should use the VPN gateway. This requires editing the connection properties directly within the NetworkManager GUI or via command-line tools. The key is to disable the automatic routing of all traffic and replace it with precise subnet definitions.
Configuring via NetworkManager GUI
The most user-friendly method involves using the graphical settings editor. Open your system settings and navigate to the Network section. Locate your existing OpenConnect VPN connection and click the gear icon to edit its details. Switch to the IPv4 Settings tab, where the core logic resides.
In the Method dropdown, ensure it is set to "Automatic (VPN) addresses only" or "Manual". If you select Manual, you will need to enter the IP address provided by the VPN server in the Addresses field. However, the critical step is managing the Routes section below the address fields. By default, NetworkManager might try to add a default route. You must clear any existing default routes and add new entries for each specific subnet you wish to reach.
For example, if your company uses the 192.168.10.0/24 subnet, you would add a route with Target: 192.168.10.0, Netmask: 255.255.255.0, and Gateway left blank or set to the VPN interface automatically. This tells the kernel to send packets for that range into the tunnel. Do not add a route with Target 0.0.0.0 and Netmask 0.0.0.0, as this re-enables full tunneling.
Command-Line Configuration with nmcli
For users who prefer terminal-based management or automated scripts,
nmcli offers precise control over routing tables. First, identify your connection name using
nmcli con show. Then, modify the IPv4 settings to remove the default route and add specific subnet routes.
Use the following command structure to delete any existing default routes associated with the VPN connection:
nmcli con mod "Your-VPN-Name" ipv4.ignore-auto-routes yes
nmcli con mod "Your-VPN-Name" ipv4.never-default yes
The
ignore-auto-routes flag prevents the VPN server from pushing its own routing table, which usually includes the dangerous default route. The
never-default flag ensures that even if a default route somehow appears, the system prioritizes the local interface. Next, add the specific subnets you need to access:
nmcli con mod "Your-VPN-Name" ipv4.routes "192.168.10.0/24"
nmcli con mod "Your-VPN-Name" ipv4.routes "10.0.0.0/8"
Each call to
ipv4.routes adds another destination. You can chain multiple subnets by separating them with spaces in a single command, though distinct commands are clearer for auditing. After making these changes, reconnect the VPN to apply the new routing rules. Verify the result by running
ip route and confirming that no
default dev tun0 line exists, but specific subnet lines do.
Verifying and Troubleshooting Connectivity
Once connected, test the split-tunnel setup by pinging an internal resource and an external website. Internal resources should respond quickly through the tunnel, while external sites should resolve via your local DNS and ISP. If you cannot reach the internal subnet, check the NetworkManager logs for errors regarding route installation. Common issues include typos in the subnet mask or conflicts with local network ranges.
If you find that some internal services are unreachable, it may be because they reside in a different subnet than the one you configured. In such cases, you may need to add additional routes. For complex environments with many dispersed subnets, consider reviewing how other clients handle similar setups, such as those described in our guide on
Accessing LAN Devices: WireGuard VPN Setup with Peers Behind Different VPN Clients, which discusses peer-to-peer routing nuances.
Ensure that your firewall rules on the Linux host allow ICMP and TCP traffic to the specified subnets. Sometimes, local firewall configurations block traffic to newly added routes until explicitly permitted. Restarting the NetworkManager service after major routing changes can also help flush stale route caches.
Frequently Asked Questions
Why does my VPN still route all traffic despite disabling the default route?
Some VPN servers forcefully push a default route regardless of client settings. To counter this, you must explicitly set
ipv4.never-default yes in NetworkManager. This forces the system to ignore any default route advertised by the server, ensuring only your manually defined subnets use the tunnel.
Can I use OpenConnect with multiple VPN connections simultaneously?
Yes, but routing conflicts can occur if both connections attempt to claim the same subnet. Each connection must have unique, non-overlapping static routes configured. Avoid setting
never-default on both if you intend to use one as a fallback, as this can lead to unpredictable routing behavior.
How do I reset routing to default if my split-tunnel fails?
Simply delete the custom routes in the IPv4 settings and revert the method to "Automatic (VPN)". Reconnect the connection to restore the server-pushed routing table. This is useful for troubleshooting connectivity issues without modifying the underlying credentials.
Does split-tunneling affect DNS resolution for internal domains?
Split-tunneling primarily affects IP routing, not DNS. However, if your internal DNS servers are behind the VPN, you must also configure the DNS settings in the IPv4 tab to point to the internal DNS IPs. Otherwise, your system may query public DNS servers that cannot resolve internal hostnames.
Is it safe to leave the default route disabled permanently?
It is safe for most office scenarios where you want local internet access. However, if you travel to regions with restrictive firewalls or need to protect all traffic for privacy, keeping the default route enabled is safer. Evaluate your threat model before committing to a permanent split-tunnel configuration.