Network conflicts between VPN internal networks and local subnets are more common than you might think. I learned this the hard way when my OpenVPN setup using 192.168.27.0/24 suddenly stopped working at a hotel that coincidentally used the same subnet for their floor 27 WiFi.

The RFC 1918 private address spaces (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) are often:

• Overused in small networks (192.168.0.0/24, 192.168.1.0/24)
• Common in hospitality networks (hotels, airports)
• Frequently collide with corporate networks

After my hotel experience, I switched to 172.16.0.0/12 space with these considerations:

# OpenVPN server.conf example
server 172.31.254.0 255.255.255.0
push "route 172.31.254.0 255.255.255.0"

Key advantages of this approach:

• Less commonly used in public WiFi networks
• Larger address space to choose from
• Still RFC 1918 compliant

OpenVPN Configuration

For OpenVPN, you can implement these protective measures:

# Prevent route conflicts
route-noexec
client-config-dir ccd

Then in your client configuration directory (ccd):

# ccd/client1
iroute 172.31.254.0 255.255.255.0
push "route 172.31.254.0 255.255.255.0"

IPsec Implementation

For IPsec VPNs, you can use these strongSwan configuration examples:

# /etc/ipsec.conf
conn myvpn
    leftsubnet=172.31.253.0/24
    rightsubnet=172.31.253.0/24
    auto=add

NAT Over VPN

When conflicts are unavoidable, consider NAT:

# OpenVPN NAT example
push "route 10.254.254.0 255.255.255.0"
iptables -t nat -A POSTROUTING -s 10.254.254.0/24 -j SNAT --to-source 172.31.254.1

DNS-Based Solutions

Combine with split DNS to prevent resolution conflicts:

# dnsmasq configuration
server=/internal.example.com/172.31.254.1

Implement conflict detection in your VPN client scripts:

#!/bin/bash
# Check for conflicting routes
if ip route show | grep -q "192.168.27.0/24"; then
    echo "Network conflict detected!"
    exit 1
fi

For larger deployments:

• Document your VPN addressing standards
• Use IPAM tools to track allocations
• Consider unique local addressing (ULA) for IPv6

---

Every sysadmin who's deployed VPN solutions has faced this nightmare scenario: You carefully configure your VPN to use 192.168.27.0/24, only to discover a hotel or client site uses the exact same subnet. Suddenly, your remote workers can't access internal resources because of IP address collisions.

After years of troubleshooting these issues, I've standardized on 172.16.0.0/12 (172.16.0.0 - 172.31.255.255) for all VPN deployments. Here's why:

• Rarely used in public WiFi networks (unlike the overused 192.168/16)
• Provides 4096 /24 subnets to choose from
• Not commonly used in SOHO router defaults

For OpenVPN, here's a sample server configuration that uses an obscure subnet:

server 172.30.121.0 255.255.255.0
push "route 172.30.121.0 255.255.255.0"
push "dhcp-option DNS 172.30.121.1"

For IPsec (strongSwan) configurations:

conn corporate-vpn
    leftsubnet=172.22.8.0/24
    rightsubnet=172.22.8.0/24
    auto=add
    keyexchange=ikev2
    ike=aes256-sha1-modp2048

When you can't control the remote network environment, consider these strategies:

# Use NAT on the VPN server (OpenVPN example)
client-config-dir /etc/openvpn/ccd
route 192.168.0.0 255.255.0.0

# In CCD file for specific client:
ifconfig-push 172.30.121.2 172.30.121.1
iroute 192.168.27.0 255.255.255.0

Before finalizing your VPN subnet choice:

1. Scan the remote network (when possible) using:

nmap -sn 192.168.0.0/16

2. Check for common cloud VPN ranges (like 100.64.0.0/10 for AWS)
3. Test connectivity from multiple public networks (coffee shops, hotels, airports)

For large deployments, consider:

• Using unique /16 allocations per department
• Implementing DNS-based service discovery
• Deploying IPv6 VPN tunnels where possible

The key is to document your chosen ranges and maintain consistency across all VPN deployments. I maintain a master spreadsheet tracking all internal subnets to prevent future conflicts.