Learn Advanced VPN Techniques: Split Tunneling & More

Prerequisites

This article focuses on client-side configuration and assumes you have a working OpenVPN server. Before you begin, ensure the following:

• Administrative access on client machines (root or Administrator) to modify routes, firewall rules, and install packages.
• OpenVPN 2.5+ recommended for client and server compatibility with the examples shown.
• Lab OS examples use Ubuntu 20.04 LTS for server/client CLI steps; commands may vary on other distributions.
• Familiarity with basic IP routing and packet filtering (iptables/nftables) concepts.
• Time synchronization (chrony or ntp) configured on clients and servers when using TOTP-based MFA.

What is Split Tunneling?

Split tunneling routes some internet traffic through a VPN while allowing other traffic to use the local network or ISP directly. This is useful when users need secure access to corporate resources while retaining low-latency access to local devices (printers, NAS) or high-bandwidth services (video streaming).

• Secure access to specific applications
• Reduced VPN bandwidth consumption
• Direct access to local devices
• Improved speeds for non-sensitive traffic

Example command (OpenVPN client):

sudo openvpn --config yourconfig.ovpn --route-nopull --route 192.168.1.0 255.255.255.0

Replace the example subnet with the target network you intend to route via the VPN (for example, 10.10.0.0/16 for corporate resources). The --route-nopull flag prevents the server from pushing a default route; the subsequent --route line adds only the subnet you want to reach via the VPN.

Benefits of Using Split Tunneling

Split tunneling gives you performance and flexibility when correctly configured: it reduces VPN load, lowers latency for local resources, and allows selective protection for sensitive traffic.

• Improved internet speed for non-sensitive tasks
• Maintained access to local network resources
• Reduced VPN load and bandwidth costs
• Flexible access to both secure and public networks

To add a local route for split tunneling on Windows (example):

Run this command in an elevated Command Prompt (as Administrator):

route add 192.168.1.0 mask 255.255.255.0 10.8.0.1

In the example above, 10.8.0.1 is the VPN gateway IP. Replace it with your VPN gateway (for example, <VPN_GATEWAY_IP>) or the appropriate local gateway for that route. If the command fails, re-open the Command Prompt as Administrator and verify with route print.

On Linux, use the ip route variant shown later in the setup section for greater control and per-source routing.

How to Set Up Split Tunneling

Configuring Split Tunneling — OpenVPN Client Examples

This section provides concrete, copy-paste-ready client configurations and scripts for OpenVPN 2.5+ (client-side). Test these in a controlled lab before deploying to production.

1) Minimal client .ovpn using route-nopull

Create a client config file (client-split.ovpn):

client
dev tun
proto udp
remote vpn.example.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
cipher AES-256-CBC
auth SHA256
verb 3

# Prevent server from setting default route
route-nopull
# Route only the corporate subnet through the VPN
route 10.10.0.0 255.255.0.0

# Credentials
auth-user-pass /etc/openvpn/creds.txt

Behavior: the client will not accept server-pushed default routes. Only traffic destined to 10.10.0.0/16 will go via the VPN; all other traffic uses the local gateway.

2) Up/Down scripts for automatic routing (Linux)

Use up/down scripts to add or remove routes on connection and to implement a kill-switch.

Create /etc/openvpn/client-up.sh (ensure executable):

#!/bin/bash
# client-up.sh - called by OpenVPN on up
# Add route for corporate subnet
ip route add 10.10.0.0/16 via "$route_vpn_gateway" dev "$dev"
# Optional: enforce DNS via VPN by pushing resolv.conf changes or using systemd-resolved

Create /etc/openvpn/client-down.sh:

#!/bin/bash
# client-down.sh - called by OpenVPN on down
ip route del 10.10.0.0/16 via "$route_vpn_gateway" dev "$dev"

Reference these in the .ovpn:

script-security 2
up /etc/openvpn/client-up.sh
down /etc/openvpn/client-down.sh

3) Kill-switch example (iptables) — Linux

To prevent leaks if the VPN goes down, block outbound traffic except through the tunnel or the local management IPs.

# Allow loopback and existing connections
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow traffic to VPN server (replace with your VPN server's IP)
iptables -A OUTPUT -d 203.0.113.10 -p udp --dport 1194 -j ACCEPT

# Allow traffic through the tun interface
iptables -A OUTPUT -o tun0 -j ACCEPT

# Drop everything else
iptables -A OUTPUT -j DROP

This pattern ensures that when the tunnel is down, non-VPN traffic is blocked (prevents data leakage). Adjust the rules to allow management/monitoring endpoints as needed and make sure to persist rules across reboots (iptables-save/iptables-restore or use nftables where preferred).

4) Linux routing alternative (ip rule/ip route)

For advanced routing, use policy routing to send only certain source addresses via VPN. This is useful in these scenarios:

• Per-container routing: send traffic from a container/subnet through the VPN while leaving host traffic untouched.
• Multi-homed hosts: when a host has multiple NICs and only a specific source IP should use the tunnel.
• Multiple local subnets: when different local subnets require distinct routing policies to the same VPN gateway.

Example steps (run after the TUN interface is up, e.g., from the OpenVPN up script):

# Create a routing table in /etc/iproute2/rt_tables (e.g., add '200 vpn')
ip rule add from 192.168.50.0/24 table vpn
ip route add default via 10.8.0.1 dev tun0 table vpn

Notes and troubleshooting:

• Replace 192.168.50.0/24 with the exact source IP or source subnet you need routed via the VPN (for a single host use /32).
• Ensure 10.8.0.1 is your VPN gateway (replace with <VPN_GATEWAY_IP>); the gateway is typically the peer IP assigned on the tunnel.
• Persist rules across reboots by adding them to your distro's network scripts, systemd-networkd, or via the OpenVPN up/down scripts.
• If traffic does not route as expected, check ip rule show, ip route show table vpn, and clear the routing cache with ip route flush cache. Verify rp_filter settings (reverse path filtering) — strict rp_filter may drop asymmetric traffic.

Other Advanced VPN Techniques to Explore

MFA Integration (OpenVPN + PAM + Google Authenticator)

Adding an MFA factor on the VPN authentication flow increases account security. The example below uses PAM with libpam-google-authenticator and the OpenVPN PAM plugin (OpenVPN 2.5+).

Install on Ubuntu 20.04+:

sudo apt-get update
sudo apt-get install -y openvpn easy-rsa libpam-google-authenticator

Enable PAM authentication in the OpenVPN server.conf:

# /etc/openvpn/server.conf
plugin /usr/lib/openvpn/openvpn-plugin-auth-pam.so login
# Or: auth-user-pass-verify /etc/openvpn/authenticate.sh via-file

Create a PAM service file /etc/pam.d/openvpn to require TOTP (libpam-google-authenticator):

# /etc/pam.d/openvpn
auth required pam_google_authenticator.so nullok
auth include common-auth
account include common-account
session include common-session
password include common-password

Per-user setup: each user runs google-authenticator once to generate their TOTP secret and QR code. Document provisioning and backup codes securely during onboarding.

Troubleshooting tips: check /var/log/auth.log and OpenVPN logs for PAM failures, ensure time sync (chrony/systemd-timesyncd) across clients/servers for TOTP validity, and confirm PAM module paths on your distribution (locations can vary).

Integrating VPN Traffic with Firewalls and IDS (Suricata)

To inspect VPN traffic for intrusions, run an IDS like Suricata on the tunnel interface (tun0) or mirror traffic to an inspection interface. Example uses Suricata 6.x and nftables for basic filtering/logging.

Basic nftables filter and logging for tun0:

# Create table and basic chain
nft add table inet vpn
nft 'add chain inet vpn input { type filter hook input priority 0; policy drop; }'
# Allow established
nft add rule inet vpn input iif "tun0" ct state established,related accept
# Log remaining traffic for analysis
nft add rule inet vpn input iif "tun0" log prefix "VPN-IN: " counter
# Drop everything else coming into tun0
nft add rule inet vpn input iif "tun0" drop

# Apply to system (example only) - adapt to your policy

Run Suricata on the tunnel (Suricata 6.x):

# Start Suricata to inspect traffic on tun0 (run as root or with appropriate capabilities)
suricata -c /etc/suricata/suricata.yaml -i tun0 --pidfile /var/run/suricata.pid

Security insights: tune Suricata's rule sets to avoid noisy alerts; forward alerts to your SIEM (syslog/Elasticsearch) and create alerting rules for lateral movement, credential stuffing, or data exfil patterns. Consider using NFLOG or a dedicated capture interface for high-throughput environments rather than pcap-based capture to avoid packet loss.

Practical Considerations

• Time sync is critical for MFA — ensure NTP/chrony is configured on both client and server.
• When inspecting encrypted tunnel traffic, focus on metadata and logs (connection patterns) or use TLS inspection at endpoints with proper consent and compliance.
• Automate provisioning of MFA secrets and VPN client configs via configuration management (Ansible, Terraform) to reduce human error.

Best Practices for Using VPNs

Choose geographically close servers to reduce latency, enforce strong ciphers (AES-256-GCM preferred), and keep OpenVPN and supporting packages updated. Use monitoring to track server load and connection metrics.

• Choose geographically closer servers
• Regularly update your VPN software (OpenVPN 2.5+ recommended)
• Monitor performance metrics and server load
• Educate users on safe VPN practices and MFA use

Implementing Advanced VPN Features

This section covers features that go beyond split tunneling: Multi-Hop VPN, Kill Switch behavior, DNS leak protection, and obfuscation. These features are useful for threat-sensitive workflows and regulatory compliance.

• Multi-Hop VPN: chain two servers to add an extra layer of routing/anonymity (trade-off: increased latency).
• Kill Switch: enforce iptables/nftables rules that block all non-VPN traffic if the tunnel drops.
• DNS leak protection: ensure your client or system resolver routes DNS through the VPN (or use a secure DNS over HTTPS/TLS provider).
• Obfuscation: use XOR patching or obfsproxy when facing restrictive networks (check provider/compatibility).

To connect using OpenVPN with simple authenticated connection (example):

openvpn --config /etc/openvpn/client/client.conf --auth-user-pass /etc/openvpn/creds.txt

Combine that with the kill-switch iptables or nftables example earlier to ensure no unencrypted traffic leaks on disconnect.

Common Pitfalls and Troubleshooting

Common issues include misconfigured routes, DNS leaks, and forgetting to enable kill-switch or MFA policies. Logs are the most direct source of truth when troubleshooting.

• Check server load and choose less crowded options
• Ensure proper DNS settings are configured to avoid leaks
• Regularly verify Kill Switch functionality in staging
• Update VPN client and server software regularly

Connectivity test examples:

# Ping the VPN server
ping <vpn-server-address>

# Check routing table on Linux
ip route show

# View OpenVPN logs (path may vary)
sudo cat /var/log/openvpn.log

Isolate the problem using connectivity checks (ping/traceroute), review OpenVPN logs and system authentication logs (/var/log/auth.log), and verify firewall rules. For MFA problems, check time synchronization and PAM logs. Use ip rule show and ip route show table <table> to verify policy routing, and flush route cache after changes with ip route flush cache.

• Run basic connectivity tests
• Consult VPN and PAM logs for errors
• Redirect to backup servers if needed
• Check for software updates and patches