Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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

share|improve this question

4 Answers 4

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.

share|improve this answer
    
Chris. Your dmz solution is fine however this does not resolve the remote site problem which is the crux of the issue. The core issue is you cannot connect an esx server to a vcenter server via VPN, unless it is site to site VPN which out of the question her. I am begining to regret mentioning a DMZ. The best I can think of involves a reverse ssh tunnel, iptables NAT rule and a netcap udp to tcp bridge. But I am unsure how to string it together. :). –  James Feb 15 '10 at 0:05
    
Indeed, I think you're stuck without doing something a bit fudgy. Maybe leaving the ESX host isolated and remoting to a management station in the remote network is the safest option. –  Chris Thorpe Feb 15 '10 at 1:46
    
Chris. Management is one thing bit the Cool vCenter features is what I want :) But I have to say it is a brain dead Client Server relationship. If I need to set up site to site VPNS for all of my oracle instances then I....I'm not sure but would be bad :) So I'm off to learn about netcap now... –  James Feb 15 '10 at 1:58
    
@James, I wouldn't call is a brain-dead setup. Your network setup, as described, is rather unique. I don't see too many DMZs being in remote locations that are completely disjoint from the trusted LAN. In fact, by definition that's not even really a DMZ. –  MDMarra Feb 15 '10 at 4:26
    
I think in one of my other post I said I regret mentioning DMZ as it is confusing the issue. But the fact you can't manage an ESX server via a VPN is pretty brain dead. I thought these sorts of protocols like active ftp that require a back connection died a death ages ago. Ah well I plan to build a Rube Goldberg machine of netcat, reverse ssh tunnels and iptables. J –  James Feb 15 '10 at 11:42

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).

share|improve this answer
    
Explain exactly what you mean as I don't thing you understand the question. –  James Feb 14 '10 at 16:19
    
He means punch a hole between your DMZ and vcenter network for port 902. This seems like the only sensible solution for the problem as you described it. Given you mentioned the networks being segregated entirely, a VPN seems like the next step. VCenter needs to be able to contact its hosts, or it can't manage them. If it can't manage them, there's no point having them in vCenter at all. –  Chris Thorpe Feb 14 '10 at 23:11

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.

share|improve this answer
    
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. –  James Feb 14 '10 at 16:32
    
Without looking at your networks I can't say if a VPN connection from Network 1 to Network 2 would actually solve your problem. In scenarios where UDP is blocked across WAN links in a large environment the standard recommendation is to set up a vCenter Server close enough to the ESX servers to avoid being blocked. Why does the vCenter server need to be on Network 2? If it was on Network 1 you could still access it from Network 2 after all. –  Helvick Feb 14 '10 at 22:23
    
Helvick, I Agree, however setting up a vCenter server closer to the location will eventually mean that I will have several vCenter servers each managing 1-2 server. This will be a complete pain and mean I will lose a lot of the functionality that makes vCenter so useful, for example sharing clones across servers etc. –  James Feb 14 '10 at 22:46

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? :) )

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.