We have a remote ESX host in a co-lo for DR. As we were unable to implement a bridge between our network and the co-lo (ISP limitation), we have had to implement a solution via Watchguard firewalls that allows both networks to have the same IP range (to avoid re-config issues if we have to bring up a remote VMWare guest), but we have subnets between them and 1:1 NAT in place to translate the IP traffic.
So, our production network is 192.168.11.x. The remote co-lo network is also 192.168.11.x, but to connect to a device over there we connect to a 192.168.20.x address which NATs back to the 192.168.11.x address of the remote device. To connect back to our production network from the co-lo, we have to use a 192.168.19.x address which again NATs back to the 192.168.11.x address on our production network. It's messy, but it works.
The only issue is vCentre. It connects to the remote host fine but times out after a few minutes. Disconnecting and reconnecting works fine, again just for a few minutes before it drops off again. Connecting directly to the host via the VI client is fine, as is an http connection to the host.
This appears to be due to the fact that in connecting to the remote host via vCentre, the remote host is given the IP address of the vCentre that is initiating the connection, which in this case is 192.168.11.227. I suspect the remote host is looking for vCentre on that address, which it won't be able to contact as from that location the vCentre will be on 192.168.19.227.
So, somehow we need to tell the remote ESX host that the vCentre is on another subnet.
Does this sound correct? If so, what is the process to correct the problem?