VMware Cloud Community
codyadmin
Contributor
Contributor
Jump to solution

VMWare vCenter using internal IP for console connections

I have a vCenter server with an internal IP of: 10.1.1.131 (Example) and the external IP is 8.8.8.8 (Example). I have configured NAT on my cisco ASA firewall to NAT on the inside as well. My computer sits on 10.2.1.0/24 and I can access vCenter from 8.8.8.8, when I try to open a console with VMWare Remote Console (VMRC) I get an error:

Failed to connect to 10.1.1.131:443: Invalid or expired session ticket.

I need it to try to connect on 8.8.8.8:443 as that is the only one that will work from my subnet. I also don't want an answer of "just move to the same subnet" because I am trying to get this to work externally.

Tags (1)
0 Kudos
1 Solution

Accepted Solutions
codyadmin
Contributor
Contributor
Jump to solution

This issue was so long ago, I forgot about it until you replied.

I DID fix it, below is how:

First, some technical details:

So I had a vCenter instance that was vcenter.domain.local and two hosts svr1.domain.local and svr2.domain.local. So what ends up happening is when you add the host to vcenter and you open a console, it actually uses the FQDN for the KMS connection AND SSL verification.

To get it working you have to split your DNS zones. So on the inside you would see:

vcenter.domain.local --> 10.1.1.2

svr1.domain.local --> 10.1.1.3

svr2.domain.local --> 10.1.1.4

and on the outside:

vcenter.domain.local --> 8.8.8.8

svr1.domain.local --> 8.8.8.9

svr2.domain.local --> 8.8.8.10

So when you use the vcenter on the outside, it will be correct, same on inside. vCenter is not NAT-aware and it breaks if you attempt to do it.

When you add your host, you can not add it by its IP because if it is 1) a NAT'd external IP, it connects fine the first time, then fails or 2) internal IP, which is then useless if you try to make it external.

If you guys need help setting this up, let me know

View solution in original post

0 Kudos
4 Replies
Dreamcatcher699
Contributor
Contributor
Jump to solution

I've got a similar task. Have you found a solution of the problem?

0 Kudos
TimmyTArris
Contributor
Contributor
Jump to solution

We fixed this by adding our local DNS server as the preferred DNS to our IPV4 TCP settings.  We also had IPV6 enabled on the Windows host system and that was disabled as well.

0 Kudos
jcrevi
Contributor
Contributor
Jump to solution

I had this issue because my DNS server had two entries for the vcenter server name, and the DNS response was for an IP that wasn't accessible from most networks (it was isolated for security). So I deleted the unneeded entry from DNS and configured the isolated network connection to not register the IP in DNS.

0 Kudos
codyadmin
Contributor
Contributor
Jump to solution

This issue was so long ago, I forgot about it until you replied.

I DID fix it, below is how:

First, some technical details:

So I had a vCenter instance that was vcenter.domain.local and two hosts svr1.domain.local and svr2.domain.local. So what ends up happening is when you add the host to vcenter and you open a console, it actually uses the FQDN for the KMS connection AND SSL verification.

To get it working you have to split your DNS zones. So on the inside you would see:

vcenter.domain.local --> 10.1.1.2

svr1.domain.local --> 10.1.1.3

svr2.domain.local --> 10.1.1.4

and on the outside:

vcenter.domain.local --> 8.8.8.8

svr1.domain.local --> 8.8.8.9

svr2.domain.local --> 8.8.8.10

So when you use the vcenter on the outside, it will be correct, same on inside. vCenter is not NAT-aware and it breaks if you attempt to do it.

When you add your host, you can not add it by its IP because if it is 1) a NAT'd external IP, it connects fine the first time, then fails or 2) internal IP, which is then useless if you try to make it external.

If you guys need help setting this up, let me know

0 Kudos