I have two ESX 3.5 servers in a DMZ. I can access these servers on any port from my LAN via a VPN. Servers in the DMZ are unable to initiate connections back to the LAN, for obvious reasons. I have a vCenter server on my LAN and can initially connect to the ESX servers fine. However, the ESX servers then try to send a heartbeat back to the vCenter server on UDP/902 - obviously this will not get back to the vCenter server, which then marks the ESX servers as not responding and disconnects.
There are two broad solutions I can think of:
1) Try to tell vCenter to ignore not getting heartbeats. The best I can do here is delay the disconnect by 3 mins.
2) Try some clever network solution. However, again I am at loss.
Note: The vCenter server is on a LAN, and cannot be given a public IP, so firewall rules back will not work. Also, I cannot setup a VPN from the DMZ to the LAN.
**I am adding the following, explanation that I added to the comments
OK, maybe this is the bit that I not explaining well. The DMZ is on a remote site, an entirely independent network (network 1). The vCenter server is on our office LAN (network 2). Network 2 can connect to any machine on any port on network 1. But network 1 is not allowed to initiate a connection to network 2. Any traffic destined to network 2 from network 1 gets dropped by the firewall as it is traffic to a non-routable address. The only solution I can think of is setting up a VPN from network 1 to network 2, but this is not acceptable.
So any clever folk out there any ideas?
J
James, why not configure the ESX hosts at the remote location so that their guests are in a DMZ, but the ESX service console etc are in a back-zone subnet that you can establish a VPN with? That way, your hosts are isolated from web connectivity (a good thing) but your guests can continue to operate front-facing.
As for the remote site problem... you really need a site-to-site VPN link going on here, between your internal LAN and the remote (non-DMZ if possible) subnet.
Your firewall will not allow a port forward from a specific IP (the ESX servers) to a specific internal IP (vCenter)? Most firewalls I've seen (other than home-grade) will do this. Or will accmoplish the same thing by doing the port forwarding then setting an ACL (or the like) to only allow that traffic under certain conditions (being from the ESX servers).
Also if this is a "DMZ" then it should be possible to have internal (but firewalled by the inner firewall) addresses for the service console ports (and VMKernel etc) and only have the externally connected uplinks connected to the external firewall (for VM NIC's with public IPs). It should be safe to then open up the relevant port for the UDP 902 traffic to the ESX Service console.
Even in an internal only environment your Service Console uplink NICs should be separated from production VM port uplinks, in a scenario like this that "should" really becomes a "must".
I'm assuming that you have multiple NICs on the ESX servers and have a DMZ rather than a situation with ESX servers sitting outside a single firewall. If that is the case then Chris S's answer should be possible.
Ok I have a solution that works, its a little brittle but works none the less. It requires you to use a host on the local lan as a "proxy"
on esx server (remote lan) IP: 10.XX.XX.XX
1) /sbin/iptables -t nat -I OUTPUT -p udp -s 10.XX.XX.XX --dport 902 -j DNAT --to 127.0.0.1
this re-routes the udp to the vCenter back to the loopback interface.
2) nc -u -l -p 902 | nc 127.0.0.1 1002
This converts the udp to tcp and sends it to the localhost on port 1002
On esx-proxy (local lan)
Set up you outbound ssh tunnels
ssh -Nf -g -L 902:localhost:902 -L 903:localhost:903 -L 443:localhost:443 10.XX.XX.XX
set up a reverse tunnel to capture the udp you have converted to tcp
ssh -Nf -R 1002:127.0.0.1:1002 10.XX.XX.XX
now convert the tcp on port 1002 back to udp
nc -l -p 1002 | nc -u 10.YY.YY.YY 902
Where 10.YY.YY.YY is the vCenter server.
On the vCenter server (local lan)
connect to the proxy as if you are connecting to the real host.
And this ladies and gentlemen allows you to connect to a esx server on a remote lan, using an ssh tunnel
Also I have extended instruction that allows you to connect to many remote esx servers using the same proxy.
J
(Can I give myself 50 points? :) )