How to Verify Full Traffic Routing Through OpenVPN: Testing VPN Leakage for Internal Resources


2 views

When your internal websites fail to work through the VPN while others function normally, this indicates potential routing leakage. Your traceroute showing traffic hitting 192.168.0.1 (local gateway) instead of 10.8.0.1 (VPN gateway) confirms traffic is bypassing the VPN tunnel.

Run these commands to verify routing:

# Check default route
ip route show | grep default

# View active network interfaces
ifconfig -a

# Test DNS leak
nslookup internal.yourdomain.com

# Comprehensive VPN check (Linux)
curl https://ipleak.net/json/

Your client config should include these critical directives:

redirect-gateway def1
dhcp-option DNS 10.8.0.1
route-nopull  # Only if you need to exclude specific routes

For Windows clients, use this PowerShell snippet to verify routes:

Get-NetRoute -DestinationPrefix "0.0.0.0/0" | 
Format-Table -AutoSize DestinationPrefix,NextHop,InterfaceAlias

Create a bash script to periodically check routing:

#!/bin/bash
VPN_GATEWAY="10.8.0.1"
DEFAULT_GW=$(ip route show | grep default | awk '{print $3}')

if [ "$DEFAULT_GW" != "$VPN_GATEWAY" ]; then
    echo "WARNING: Traffic leaking through $DEFAULT_GW"
    exit 1
else
    echo "VPN routing OK"
    exit 0
fi

If you need selective routing, modify your OpenVPN config:

# Route only specific networks through VPN
route 192.168.1.0 255.255.255.0
route 10.0.0.0 255.0.0.0

# Exclude corporate DNS
dhcp-option DNS 192.168.0.10

For thorough isolation testing on Linux:

# Create network namespace
ip netns add vpn_test

# Move OpenVPN interface to namespace
ip link set tun0 netns vpn_test

# Test connectivity within namespace
ip netns exec vpn_test curl http://internal.resource

When working with OpenVPN configurations, particularly in corporate environments where internal resources need to be accessed remotely, verifying full-tunnel routing is crucial. The scenario you described with gateway IPs (192.168.0.1 for local network vs 10.8.0.1 for VPN) clearly indicates a potential split-tunnel situation.

Your traceroute observation is indeed valid evidence of traffic leakage. When internal websites show routing through 192.168.0.1 instead of 10.8.0.1, this confirms traffic is bypassing the VPN tunnel. Here's what a typical leak might look like in traceroute output:

traceroute internal.company.com
 1  192.168.0.1 (192.168.0.1)  2.345 ms  2.456 ms  2.567 ms
 2  [local ISP gateway]  15.678 ms  16.789 ms  17.890 ms

1. Checking Routing Tables

Run this command to inspect your routing tables:

route -n
# Or for newer systems:
ip route show

Look for default routes (0.0.0.0) pointing to your VPN gateway (10.8.0.1 in your case). If you see multiple default routes or routes pointing to your local gateway (192.168.0.1), traffic may leak.

2. IP Address Verification

Use this Python script to compare your public IP with the VPN endpoint's IP:

import requests

def check_vpn_connection():
    vpn_ip = "YOUR_VPN_SERVER_IP"
    public_ip = requests.get('https://api.ipify.org').text
    
    print(f"Public IP: {public_ip}")
    print(f"VPN Server IP: {vpn_ip}")
    
    if public_ip == vpn_ip:
        print("All traffic appears to be routed through VPN")
    else:
        print("Warning: Traffic may be leaking outside VPN tunnel")

check_vpn_connection()

3. DNS Leak Testing

DNS queries often bypass VPNs unless specifically configured. Test with:

nslookup internal.resource.com
# Or for more detailed analysis:
dig +short internal.resource.com

To ensure all traffic routes through VPN, modify your OpenVPN client configuration:

# In your .ovpn file add:
redirect-gateway def1
dhcp-option DNS 10.8.0.1
block-outside-dns

For absolute certainty, capture traffic on both interfaces:

tcpdump -i tun0 -n -c 10   # VPN interface
tcpdump -i eth0 -n -c 10   # Physical interface

Compare the outputs - you should only see keepalive packets on eth0 if properly configured.

If you find traffic leaking despite proper configuration:

  • Check for conflicting network manager settings
  • Verify no local routes override VPN routes (especially for internal networks)
  • Ensure no 'route-nopull' or similar directives in client config
  • Test with different MTU sizes if experiencing intermittent issues