Connectivity issues when subnet on VPN client collides with existing network configuration

Issue

While using the VPN client, there are cases where connectivity to the device or to other hosts may fail when the subnet used for the VPN interface collide with other existing interfaces with the same subnet as the one behind the Belden Horizon platform, either the ICX35-HWC or the PLX35-NB2.  (IE: the same IP addressing as the VPN client.)

For example, say your home network, is configured with a subnet of 192.168.0.x/24 and the LAN side of the Module is also 192.168.0.x/24.  You may be able to connect the VPN client successfully (which will assign you the IP address you set in Belden Horizon, lets say 192.168.0.251/24), but accessing resources such as a PLC downstream of the VPN client will not be possible.

There are a number of reasons for this, but simply put; don't connect to the VPN using a topology like the one mentioned above.  Your host machine will likely try to forward traffic to the local gateway, (firewall, Cable Modem, etc.) which won't know where to send it.  Further, ARP requests will not resolve, or potentially the host may not even forward the traffic as it now has conflicting routes - the same subnet on two interfaces.  Access to local resources like a printer, or remote media storage devices may also fail as long as the VPN is connected.

Connections open before the VPN is connected may continue to exist as Windows often caches routes, and ARP information to speed up connectivity, however any new socket opened after the VPN session is started will fail to function correctly.  Not even the local Web GUI will be accessible over the VPN if you have conflicting routes.

Resolution

To make this work correctly, configure your home network to be 192.168.1.x/24, leaving the LAN side of the Belden Horizon Gateway to be 192.168.0.x/24.  This will avoid any route conflicts, and send all of the proper traffic to the local and remote network gateways for proper routing.

If you cannot change the entire addressing scheme on either end, consider setting up a smaller subnet of IP addresses that can be used only for remote access.  Contact our Technical Support department for more information.