cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

vCenter Discovery not finding vCenter - ICMP Blocked

dbeckner
By Level 10 Champion
Level 10 Champion

If ICMP is blocked, but ports 80 and 443 are open. Should the discovery tool still discover vCenters as long as port 443 is open or will it not find anything since ICMP is blocked?

(1) Solution

Hi @dbeckner ,

If the ICMP is blocked the vCenter by default will be not discovered. A work around that I find is the following:

When you create the rule for vCenter inventory, disable the network scan and microsoft computer browser services and leave only the use previously discovered devices 

Manually create in all discovered devices the vCenter, with all required information, like ip, host name, dns, etc , then go to advanced and manually check the check box for this device is a virtualization host or management server, select the option that it fit's you the best, like VmWare vCenter Server, check the port on which the device will communicate.

Save all this

Go back to Discovery and inventory rules, and create a target and rule for this vCenter, or other that you have.

Also don't forger to assign the subnet where the vCenter is to the beacon from where you will do the inventory.

 

 

View solution in original post

(6) Replies

Hi @dbeckner ,

If the ICMP is blocked the vCenter by default will be not discovered. A work around that I find is the following:

When you create the rule for vCenter inventory, disable the network scan and microsoft computer browser services and leave only the use previously discovered devices 

Manually create in all discovered devices the vCenter, with all required information, like ip, host name, dns, etc , then go to advanced and manually check the check box for this device is a virtualization host or management server, select the option that it fit's you the best, like VmWare vCenter Server, check the port on which the device will communicate.

Save all this

Go back to Discovery and inventory rules, and create a target and rule for this vCenter, or other that you have.

Also don't forger to assign the subnet where the vCenter is to the beacon from where you will do the inventory.

 

 

Thanks @adrian_ritz1 I'll give this a try. We have an interesting situation where the test environment is hosted by a vCenter in a completely inaccessible environment. We created a firewall rule to allow the traffic over 443 but will likely not be able to get ICMP approved. I added the subnet for the vCenter to the beacon and the service account into the password vault on the beacon. Hoping this works!

Hi,

I had the same situation with some vCenter, port 443 is open but ICMP is disabled, and this is how I solved the issue. also I had some vCenter on non standard ports, like 8443 🙂

 

In addition to the helpful comments already provided - it is also possible to disable the ping-sweep functionality of MGSIPscan on a beacon server:

https://docs.flexera.com/fnms/EN/WebHelp/index.html#reference/FIB-Registry.html

See 'DefaultPingSweepOptions' - making the changes described in the above article would amend the behaviour from an ICMP ping-sweep to a TCP SYN/ACK scan. Please note that this will slow down the port scanning process.

HTH,

Joseph

If my response answered your question satisfactorily, please click "ACCEPT AS SOLUTION" to heighten visibility for future customers!

Hi,

Solution provided by @jjensen  also work, but I think a good approach is to create a separate target with the impacted vCenter with port closed, create a separate rule for inventory with ping disabled. I this way you have 2 rules, one standard for the vCenter that don't have the port closed, and one for vCenters that have the port closed. If you disable the pingsweep on beacon side, all vCenters will be impacted by this rule. 

@adrian_ritz1 @jjensen Thank you both for your input on this. While both options would have worked the first solution of manually creating the discovered device worked great and we did not have to compromise any performance. Thank you!