VPN Tracker says my local and remote networks conflict. How do I fix this problem?
By default, traffic to the remote network cannot be sent through the VPN tunnel if it is using the same network as the local network.
Resolving a Network Conflict using Traffic Control
If you are using VPN Tracker 8 you can use Traffic Control to have VPN Tracker attempt to send non-essential local network traffic over the VPN (Advanced > Traffic Control > Force traffic over the VPN if remote networks conflict with local networks).
Note that you will never be able to reach the following addresses over VPN: The IP address of your local router, your DHCP server, and your DNS server(s). If you need to reach those IPs over VPN, you will have to resolve the network conflict instead of using Traffic Control. The same applies for any IPs that you need to reach locally and over VPN.
Resolving a Network Conflict Manually
You have two basic options for resolving a conflict:
- Change the local network to use a different network address. In most situation, this will entail changing the LAN settings on the local router (including DHCP settings if DHCP is used), and changing the IPs used by devices on the LAN (or triggering a DHCP refresh, if DHCP is used).
- Change the remote network to use a different network address. With most setups, this entails changing the LAN on the VPN gateway (including DHCP settings if DHCP is used), and changing the IPs used by devices on the VPN gateway's LAN (or triggering a DHCP refresh, if DHCP is used). If the LAN is used in the VPN settings (such as for policies or firewall rules), these will need to be changed as well. Finally, change the remote network in VPN Tracker to match the new settings
If you decide to change the remote network, it makes sense to choose a private network that less commonly used. According to our informal statistics, conflicts are least likely using these networks:
- Subnets of 172.16.0.0/12
- Subnets of 192.168.0.0/16, excluding 192.168.0.0/24, 192.168.1.0/24 and 192.168.168.0/24
If these are not an option, use a subnet of 10.0.0.0/8, excluding 10.0.0.0/24, 10.0.1.0/24, 10.1.0.0/24, 10.1.1.0/24. However, since wireless network operators sometimes choose to use the entire 10.0.0.0/8 network, the former two options are preferred.
If you have a more sophisticated VPN gateway, in particular a SonicWALL, you may be able to set up an alternative remote network on the VPN gateway that is mapped 1:1 through Network Address Translation (NAT) onto the actual network. Users can then connect to this network instead if they have a conflict of networks. We have a guide available that describes this approach for SonicWALL devices.
If the conflict is caused by virtual network interfaces (e.g. Parallels, VMware), see here for more information.