aimvicit
asked on
Problems with remote ESX host disconnecting from vCentre
Hi all,
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?
Many thanks,
David.
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?
Many thanks,
David.
We have this type of situation with some of our customer and the solution may be easier than doing the 1:1 NAT. I would put the ESX hosts at the DR onto a different subnet (management) and setup a VPN WG site to site VPN. The VMs can be on a vswitch with the same IP info as at the source and can be managed from VC. This will avoid any IP conflict issues.
My $.02
My $.02
ASKER
Thanks for the comments. I should have mentioned that we will be using vReplicator to backup the production guests to the DR site. If we had the the co-lo ESX host on another subnet and the guests on the same subnet as production by using a vswitch, how would we fail over to the guests from the production network? That would fail, wouldn't it?
The reason for the 1:1 NAT was as a temporary measure as Watchguard are releasing firmware that will set up a bridge via the firewalls. Bridging is the recommended network setup for vReplicator. Would love to get it working as is, as we have invested quite a bit of time and effort getting the network working correctly. It's just vCentre that seems to have an issue.
Any thoughts?
Thanks again.
The reason for the 1:1 NAT was as a temporary measure as Watchguard are releasing firmware that will set up a bridge via the firewalls. Bridging is the recommended network setup for vReplicator. Would love to get it working as is, as we have invested quite a bit of time and effort getting the network working correctly. It's just vCentre that seems to have an issue.
Any thoughts?
Thanks again.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Hi all, sorry for the delay, we're going to wait for the Watchguard updated that supports bridging. Vizioncore recommend this and we feel that anything else will be a work-around and not ideal for DR recovery.
Thanks for all the help.
Thanks for all the help.
I understand the DR host is located at co-lo site, but you can still have your own private internet connection rite?