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.

Thank you so much for looking at my. I am trying to open up ports 443 and 80 for access to the vCenter server by a disaster recovering software. The disaster recovery site is located in the different state and we have vpn tunnel between two sites with ports 443 & 80 open. The disaster recovery site is an esx host 5.0.

I ran nmap ping to check on ports 443 & 80 to esx host:

Port 443

Starting Nmap 6.40 ( http://nmap.org ) at 2013-10-10 11:26 Central Daylight Time Nmap scan report for xxx.xxx.xx.xx Host is up (0.0079s latency). PORT STATE SERVICE 443/tcp open https

Nmap done: 1 IP address (1 host up) scanned in 24.41 seconds

Port 80

Starting Nmap 6.40 ( http://nmap.org ) at 2013-10-10 11:27 Central Daylight Time Nmap scan report for xxx.xxx.xx.xx Host is up (0.0098s latency). PORT STATE SERVICE 80/tcp open http

Nmap done: 1 IP address (1 host up) scanned in 13.52 seconds

Now, when I do the same thing for vCenter, I get this:

Port 443

Starting Nmap 6.40 ( http://nmap.org ) at 2013-10-10 11:12 Central Daylight Time Nmap scan report for xxx.xxx.xx.xx Host is up (0.0078s latency). PORT STATE SERVICE 443/tcp closed https

Nmap done: 1 IP address (1 host up) scanned in 7.11 seconds

Port 80

Starting Nmap 6.40 ( http://nmap.org ) at 2013-10-10 11:13 Central Daylight Time Nmap scan report for xxx.xxx.xx.xx Host is up (0.0079s latency). PORT STATE SERVICE 80/tcp closed http

Nmap done: 1 IP address (1 host up) scanned in 6.38 seconds

I also attempted to run esxcfg-firewall --openPort ,tcp|udp,in|out, to open up the ports, but I don't believe this command applies to esx 5.0.

I know I might be missing some important info, so please, please, ask follow ups.

Thank you!!!

share|improve this question
    
Is vCenter running on Windows, or are you using the Appliance? –  1.618 Oct 10 '13 at 16:57
    
Yes, it's running on Windows with Windows firewall turned off –  George Oct 10 '13 at 16:58
    
What device are you doing nmap from? –  CIA Oct 10 '13 at 17:11
    
@CIA One of the helpers from data recovery site, but it looks the same on the source site –  George Oct 10 '13 at 17:12
    
Just to confirm; You ran nmap from a computer at the recovery site to both destinations to get the results above? I read Chopper3's answer below and he is correct; 80 and 443 are used by the vCenter server's website(s). Even so, they should report open. 902 is generally reserved for communicating with other applications, like backup software (e.g. BackupExec). Try: nc –z <vcenter ip> <port range> from an ESX shell to see what's open. For reference: (blogs.vmware.com/tp/files/… –  CIA Oct 11 '13 at 2:13
show 3 more comments

2 Answers

Erm....this is an odd one.

What are you trying to achieve and why? Are you aware that vCenter itself uses both 80 and 443? you know that vCenter talks to its hosts via 902/903 right?

Have you seen THIS?

share|improve this answer
    
It's a requirement for our disaster recovery software (Double Take) to use vCenter to gain access to esx host. I have already had a conversation with Double Take about it and I was able to get to host directly (using Double Take) to write to, but we don't want to use root (and password for that matter), so it makes it either to use vCenter and manage it that way too. Does it kind of make sense? –  George Oct 10 '13 at 17:27
add comment
up vote 0 down vote accepted

Okay, after finally getting someone knowledgeable from VMWare support, she took a look at the vCenter in question and found out that one of the VM related services wasn't running, that's why I was unable to nmap ping it.

See this screenshot:

screenshot

I kind of figured it was something stupid on my end. Thank you everyone for all your help!!!

share|improve this answer
add comment

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.