VMware Cloud Community
VMAT
Contributor
Contributor

vCenter with firewall between hosts resolves host to firewall address

Hi,

I'm having a problem with vCenter storing the firewall IP address instead of the actual host IP address for all hosts behind the firewall. All DNS resolution is working and routes are fine. There is no NATing between the networks though they are on different subnets. All normal communications is fine, the only issue is with hot cloning which fails with cannot connect to host.

I managed to track it down to the IP_ADDRESS entry in the VPX_HOST table of the VC database. I have seen the posts about editing the vpxa.cfg file but the issue is not with the serverip addres but the hostip address. I have also manually changed the IP addres in the table but it keeps changing back to the firewall IP. Any help would be great to find out how / why this happens.

0 Kudos
2 Replies
VMAT
Contributor
Contributor

Hi,

Thought I would answer my own question for reference.

Issue is that some VC operations use a UDP broadcast to find the host (one of these being the binding of an IP to a hostname in VC). In my instace where the firewall was in between the VC and hosts the firewall would reply to the UDP with its address rather than the host.

For most operations DNS works without issue to resolve so all is good but for some reason certain operatins such as the hot clone use this look up table which as described above will fail due to having the wrong IP address.

Lesson learned, be careful about what you test when you implement a firewall between VC and host as not all operations behave in the same manner.

0 Kudos
josby
Contributor
Contributor

Thanks very much for finding this.  I ran into this when the vCenter Host Agent Pre-Upgrade Checker telling me "Connection Error."  The error in its log was:

System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond [router IP]:443

I noticed that it was trying to connect to my router's IP rather than the IP of the ESX host and thought that was very odd.  I searched the database for the router IP and found it there in the table you mentioned.  It seemed strange since this vCenter setup has been working for years, so your explanation of how it got there really helped.  
I was able to manually correct the IP's in the database and then re-run the Pre-Upgrade Checker and it succeeded (though it seems vCenter changes those IP entries to the wrong ones on a regular basis, because they've all gone back to the router IP's again now).
0 Kudos