So I have build a vSphere 6 lab (vanilla install) my old 5.5 lab is still externally accessible on port 9443. I port forward 9443 to the IP of the new lab 192.168.0.145 and it pops up fine with the certificate I accept and then I get "page cannot be displayed" grrr! Am I forgetting something obvious on this build? One thing I did notice was the the working addres on the new lab includes the actual server name when it trys to redirect I am wondering if that is screwing things up a little. For example its trying to go to...
https://SRVvCenter1.lab.homeip.net:9443 (whihc fails)
Where as if I port forward 9443 back to the old operational 5.5 VC to goes to...
https://lab.homeip.net:9443 (which works fine)
The two VC's are on different hosts but connected to the same switch, is in DNS internally and resolves by name internally, any idea's? I have had this problem before from memory with the vCSA and had to do some tweaks via SSH.
Does anyone have any idea's or pointers as to where I am going wrong? Just wanted to have a tinker with the lab whilst I am at work.
id suggest this is because the internal FQDN you used to install vcenter isnt the same as the external facing address you are trying to connect to.
a simple way to check this would be to add a line into the machine you are using to connect to vcenter externally from so:
internalFQDN externalIPaddress
confirm pinging internalFQDN reslolves the external IP address correctly on the machine, then connect to https://internalFQDN:9443
and see if that works.
Rich
Internally either IP or name seems to work mate, I can for example get to...
https://srv2012R2VC6.mydomain.homeip.net:9443
or ...
Both work same as they do with the old 5.5 lab, but externally its no banana. When the vCenter redirects after the certificate I need it to somehow drop the servername just like it does with the old 5.5 lab then I think I might have a chance. I have edited tried to edit the actual vCenter adress in the advanced settings to only https://mydomain.homeip.net but that didn't seem to work Will try the internal FQDN on the machine next as you suggested
i think the issue is there is some form of a redirect in the page coding that points back to the internal FQDN used at install, so you get a page cannot be displayed as obviosuly the internal FQDN doesnt resolve externally. this is where the changing of the test machines host file come in.
I ve seen it before internally when a fqdn wouldn't resolve but the hostname would, you could get to the page and get the cert warning then it would fail. hence the idea for the test above.
Let me know what results you get with the test.
R
Are you suggesting amending the host file on my externally facing machine outside the network so https://myserver.homeip.net:9443 resolves to https://homeip.net:9443 instead Richard? I tried changing the address in the advanced vCenter settings and removed the prefix server name unfortunately that didn't work
Do you know what the redirect mechanism is? Is it the certificate that redirects the address? If only I could amend the address (dropping the server name prefix) I think I could resolve it. During an install it will only allow your FQDN or an IP address but when I tried the IP that also didn't work externally.
Might look into this little hack later... (see if it works with v6)
http://www.davidklee.net/2014/09/30/vmware-vcenter-web-client-ip-redirect-solution/
Sorry just seen this.
Yes, make the change on that you are using to connect externally, so your laptop out side your home network.
I don't know what the mechanism is, but you can see it happen if you do https://myserver for example, you ll see that the page will redirect to https://myserver.homeip.net.
So as an example.
Https://vcenter01.myinternalfdqn.com works correctly inside and that was the FQDN used when installing vcenter.
then
Change the host file on the machine outside so that vcenter01.myinternalfqdn.com resolves to your home external ip address. Basically mapping the internal name of the server to an external IP address, so when it tries to redirect it will still resolve correctly.
If this works you can be sure that its down to the DNS redirect.
R
Yes looks like that would work, you d have to play around with the configuration a bit.
You can confirm that this is the issue with the host file method, but other than testing it I wouldn't know exactly what you d want to change in the proxy file.
R
Unfortunately the hack is a no-go I have found the file in a differing directory but everything seems non-applicable