When establishing a VPN connection between networks using identical private IP ranges (like 192.0.2.0/24), routing ambiguity occurs. The system can't determine whether traffic for 192.0.2.15 should remain local or traverse the VPN tunnel.
Modern operating systems prioritize local routes over VPN routes by default. A typical routing table might show:
Destination Gateway Genmask Flags Metric Ref Use Iface 192.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.0.2.0 10.8.0.1 255.255.255.0 UG 0 0 0 tun0
The more specific local route (metric 0) always wins, making remote resources inaccessible.
On the OpenVPN server, implement these configuration changes:
# Force different subnet for VPN clients server 10.8.0.0 255.255.255.0 # Add route for remote conflicting subnet route 192.0.2.0 255.255.255.0 # Push NAT rule to clients push "route-nopull" push "route 192.0.2.0 255.255.255.0 vpn_gateway" push "redirect-gateway def1 bypass-dhcp"
For temporary fixes when server changes aren't possible:
# Windows PowerShell (run as admin): Add-VpnConnectionRoute -ConnectionName "YourVPN" -DestinationPrefix 192.0.2.0/24 # Linux: ip route add 192.0.2.0/24 via 10.8.0.1 dev tun0
For permanent solutions:
- Rebase one network to non-conflicting RFC 1918 range (10.0.0.0/8 recommended)
- Implement NAT on VPN server for overlapping subnets
- Use DNS names instead of IP addresses where possible
For complex environments, implement policy routing:
# Linux example marking VPN traffic iptables -t mangle -A OUTPUT -d 192.0.2.0/24 -j MARK --set-mark 1 ip rule add fwmark 1 table vpn ip route add default via 10.8.0.1 dev tun0 table vpn
When establishing VPN connections, subnet conflicts occur when both the local network and remote network use identical private IP ranges (e.g., 192.0.2.0/24). This creates routing ambiguities where the system can't distinguish whether traffic should stay local or traverse the VPN tunnel.
The conflict manifests in two critical ways:
- Local network resources become inaccessible during VPN sessions
- Remote resources appear unreachable despite proper VPN connectivity
Packet routing becomes ambiguous because the same subnet exists in two different network spaces.
Solution 1: Network Address Translation (NAT)
On the OpenVPN server, implement NAT to translate the remote subnet to a non-conflicting range:
# OpenVPN server configuration server 10.8.0.0 255.255.255.0 push "route 192.0.2.0 255.255.255.0" route 192.0.2.0 255.255.255.0 # NAT translation rule iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -d 192.0.2.0/24 -j SNAT --to-source 10.8.0.1
Solution 2: Client-Side Route Override
Configure client-specific routes with higher metrics:
# Linux client solution sudo ip route add 192.0.2.0/24 via 10.8.0.1 metric 50 # Windows equivalent (PowerShell): Add-NetRoute -InterfaceAlias "OpenVPN" -DestinationPrefix 192.0.2.0/24 -NextHop 10.8.0.1 -RouteMetric 50
For large deployments, consider these architectural approaches:
# Using VRF on Linux routers ip route add table 100 192.0.2.0/24 via 10.8.0.1 ip rule add fwmark 100 table 100 iptables -t mangle -A OUTPUT -d 192.0.2.0/24 -j MARK --set-mark 100
Essential diagnostic commands:
# Check active routes ip route show table all # Trace route with specific interface traceroute -i tun0 192.0.2.5 # Test connectivity with source interface binding curl --interface tun0 http://192.0.2.10