VPN Connectivity Fails Due to Overlapping IPv4 Subnet Between Local LAN and Remote Network

Indicators

• Cannot reach remote servers via IP address after connecting to VPN despite tunnel showing as established
• Traffic intended for the remote subnet is routed locally instead of through the VPN tunnel
• DNS resolution of remote hostnames succeeds but subsequent connections to those IPs fail
• Unable to access the public internet while VPN is connected (default route conflict)
• Remote hosts are unreachable by IP even though the VPN tunnel endpoint itself is pingable

Likely causes

• Local LAN subnet and remote VPN subnet share the same network address and prefix length (e.g., both are 192.168.1.0/24)
• OS routing table cannot distinguish between local and remote destinations on the same subnet, so local route wins
• No NAT translation configured on either VPN gateway to disambiguate the overlapping address space
• VPN client software has no built-in mechanism to detect or compensate for overlapping subnet scenarios
• Use of common RFC 1918 ranges (192.168.1.0/24, 10.0.0.0/24) increases probability of collision with remote office or client networks

Diagnostic steps

1. Capture the routing table before and after VPN connection: run 'route print' (Windows) or 'ip route show' (Linux/macOS). Confirm that the conflicting subnet route points to the local interface rather than the VPN tunnel adapter.
2. Identify the local LAN subnet precisely: run 'ipconfig /all' (Windows) or 'ip addr show' (Linux/macOS) to record the client's network address and prefix length.
3. Confirm the remote network subnet by reviewing the VPN server configuration — for OpenVPN, inspect 'push route' and 'route' directives in the server .conf file; for hardware appliances, review the VPN policy/crypto map.
4. Ping the VPN tunnel endpoint IP (the VPN gateway's inner tunnel address, not a remote LAN host) to verify basic tunnel connectivity is functional independent of the subnet conflict.
5. On the VPN gateway server, audit existing NAT rules: run 'iptables -t nat -L -n -v' (Linux/OpenVPN) or review NAT policies in the firewall/ASA configuration to confirm whether any overlap NAT is already in place.
6. If NAT proxy addresses are configured, test reachability using the NAT-mapped alias IP (e.g., ping 203.0.113.5 instead of 192.168.1.5) from the remote client to confirm NAT-based routing resolves the conflict end-to-end.

Resolution path

• Select two unique, non-conflicting proxy subnets to represent each side inside the VPN tunnel (e.g., 198.51.100.0/24 as the local office proxy, 203.0.113.0/24 as the remote office proxy). Use documentation ranges or organisation-specific allocations unlikely to appear on client networks.
• Configure static 1-to-1 NAT on the local VPN gateway: masquerade local 192.168.1.0/24 hosts as their corresponding 198.51.100.0/24 proxy addresses before packets enter the tunnel.
• Configure static 1-to-1 NAT on the remote VPN gateway: masquerade remote 192.168.1.0/24 hosts as their corresponding 203.0.113.0/24 proxy addresses before packets enter the tunnel.
• Add explicit routes on each VPN gateway directing traffic destined for the opposite proxy subnet through the VPN tunnel interface.
• Update internal DNS records or distribute host file entries so clients reference remote hosts by their NAT proxy addresses (e.g., 203.0.113.5) rather than their real conflicting IPs.
• For unidirectional traffic requirements, configure static NAT only on the receiving gateway; the initiating side may use dynamic masquerade NAT to simplify the configuration.
• For road warrior (roaming) clients where per-laptop local subnet changes are not possible, implement NAT on the client device and configure the VPN server to issue a dedicated NATed VPN profile for overlapping subnet scenarios.
• After applying NAT and routing changes, verify internet connectivity is preserved — confirm split tunnelling or correct default route handling to prevent the VPN tunnel from inadvertently capturing all traffic.

Prevention

• Adopt an IPAM policy that assigns unique, documented subnets to every office and VPN range before deployment, with a mandatory overlap-check step during VPN onboarding.
• Avoid commonly used private address ranges (192.168.0.0/24, 192.168.1.0/24, 10.0.0.0/24) for corporate infrastructure; use less-common portions of 172.16.0.0/12 or organisation-specific slices of 10.0.0.0/8 with large prefix lengths.
• Document all remote office and expected road warrior subnets and verify non-overlap against the corporate allocation table before provisioning any new VPN tunnel.
• Consider adopting IPv6 for internal networks to virtually eliminate IPv4 subnet collision risk across sites and with client environments.
• Implement VPN gateway health checks that alert if a newly connected site subnet is already present in the corporate routing table, catching conflicts before users report failures.

Tools

• OpenVPN (VPN server and client software)
• iptables (Linux NAT and packet filtering for overlap NAT rules)
• ip route / route print (routing table inspection pre- and post-VPN connection)
• ipconfig / ip addr (network interface and subnet inspection)
• ping / traceroute (tunnel endpoint and NAT alias reachability testing)
• Cisco ASA / PIX (hardware VPN platform with native overlap NAT support)
• IPAM tools (IP address management for subnet allocation governance)

References

• Cisco — Using NAT in Overlapping Networks
• Server Fault — Connecting to a remote server through a VPN when local network subnet conflicts