To route an OpenVPN connection on a secondary interface, you must bind the client to that specific network device using the
dev directive and enforce policy-based routing via your operating system’s kernel. This ensures traffic destined for the VPN tunnel exits through the correct physical or virtual adapter, preventing conflicts with the primary default gateway.
Understanding Interface Binding
The most common mistake is assuming OpenVPN automatically detects the correct outbound interface. By default, it uses the system’s default route, which often points to the primary internet connection. To force the connection through a secondary interface, such as a dedicated management LAN or a backup WAN link, you need to explicitly define the network device in the configuration file.
OpenVPN provides the
dev option for this purpose. While
dev tun creates a virtual point-to-point layer 3 interface, you can also specify a physical interface if your setup requires it, though
tun is standard. However, binding the virtual tunnel does not automatically route all traffic through it. You must combine this with OS-level routing rules to ensure packets are sent out of the correct port.
Configuring the Client Connection
Start by editing your OpenVPN client configuration file. Add the following directives to ensure the tunnel attaches to the correct virtual interface and binds to the local IP address associated with your secondary network segment.
client
dev tun
proto udp
remote vpn-server.example.com 1194
resolv-retry infinite
nobind
user nobody
group nogroup
# Bind to the secondary interface's subnet
local 192.168.20.50
route 10.8.0.0 255.255.255.0
The
local directive here is critical. It tells OpenVPN to bind the UDP socket to the IP address of your secondary interface (e.g.,
192.168.20.50) rather than letting the kernel choose the source IP. If you omit this, the VPN may attempt to connect using your primary public IP, causing failures if the server expects traffic from the secondary subnet.
For more details on reaching specific IPs on the client network side, refer to our guide on
OpenVPN: How to reach a specific ip on client network side?.
Implementing Policy-Based Routing
Binding the socket is only half the solution. Even if the tunnel is up, your operating system might still send return traffic through the primary interface due to symmetric routing expectations. To fix this, you need to create a separate routing table for the VPN traffic.
On Linux systems, this involves creating a new routing table entry in
/etc/iproute2/rt_tables. Add a line like
100 vpn-table to assign ID 100 to your custom table. Next, add routes to this table that direct traffic through the VPN tunnel interface.
# Example command to add a route to the VPN table
ip route add 10.8.0.0/24 dev tun0 table vpn-table
ip rule add from 10.8.0.0/24 lookup vpn-table
This setup ensures that any traffic originating from the VPN subnet (
10.8.0.0/24) uses the custom table. The
ip rule command matches packets based on their source IP and directs them to the specified table. This prevents the "asymmetric routing" issue where packets go out one way and come back another, which often results in dropped connections.
If you are dealing with complex scenarios involving WAN traffic over tunnels, see our article on
Routing WAN Traffic over OpenVPN Server IPsec Tunnel on Debian Server.
Verifying the Setup
After applying these changes, verify that the routing is working correctly. Use the
ip route get command to test how the system resolves a destination IP.
ip route get 8.8.8.8 src 10.8.0.10
This command simulates a packet originating from the VPN client IP. The output should show the next hop pointing to your VPN gateway and the source IP as the VPN address. If it shows your primary gateway, the policy-based routing rule was not applied correctly.
You can also check the active connections with
ss -tuln | grep openvpn to confirm the process is bound to the secondary interface’s IP address. Ensure that firewall rules on the secondary interface allow UDP traffic on port 1194. Blocked ports are a frequent cause of silent failures where the config looks correct but no data flows.
Troubleshooting Common Issues
If the connection fails, first check the logs for binding errors. Messages indicating "Address already in use" suggest another process has claimed the secondary IP. Restarting the OpenVPN service after modifying routing tables is often necessary to refresh the kernel state.
Another common pitfall is DNS leakage. Since the VPN route is isolated, standard DNS queries might still go through the primary resolver. Configure your client to use DNS servers accessible via the VPN tunnel, or update your resolv.conf to prioritize the VPN interface. For issues related to accessing resources behind the VPN server, consult our guide on
Routing Traffic Coming to OpenVPN Access Server to the VPN Not Working.
Frequently Asked Questions
Can I use multiple OpenVPN clients on different interfaces?
Yes, you can run multiple instances of OpenVPN, each with its own configuration file specifying a different
local IP and
dev name. Each instance will create a separate virtual interface (e.g., tun1, tun2) and require distinct routing tables to prevent overlap.
Why does my ping work but web browsing fail?
This usually indicates a DNS resolution issue or MTU mismatch. Ensure your DNS settings are pushed by the server or configured locally within the VPN context. Additionally, reduce the MTU size on the client config using
mtu 1400 to accommodate overhead from encryption headers.
Does this method work on Windows?
Windows handles routing differently than Linux. Instead of
ip route, you typically rely on the OpenVPN GUI’s built-in routing options or PowerShell commands to add static routes. The principle of separating routing tables remains similar, but the implementation tools differ significantly.
What if the secondary interface loses connectivity?
If the physical link drops, the VPN connection will naturally fail because the underlying socket cannot transmit. Implement health checks or scripts to monitor the interface status and disconnect the VPN gracefully, allowing other applications to revert to the primary route without hanging.
Is it safe to route all traffic through the secondary interface?
No, this can lead to asymmetric routing loops if not carefully managed. Only route traffic specifically intended for the VPN network or trusted internal subnets. Leaving the default gateway unchanged ensures general internet traffic continues to flow normally through the primary ISP link.