Scanner didn’t find any open ports

Things are not always what they seem - The host may have open ports, even if the scanner does not see it that way. Expanding the search or whitelisting our scanner IPs might solve the problem.

Written by Robert Tanase

Updated 1 year ago

If your port scan result returns "Found 0 open ports" or the network vulnerability scan coverage information section warns you that "No open ports" were found and you suspect that this is incorrect, there are a few steps you can take to ensure that you get the expected results.

First of all, make sure that the host is alive by enabling the option “Check if the host is alive before scanning”. If the scan does not finish with the result “Host is down”, but there were no open ports discovered, the next step is to check the scan settings and see what port range/list was used.

On the other hand, if you get the message “Host is down”, there is no use in further scanning for open ports. However, the check alive mechanism is not 100% foolproof and if you expect that the host is alive, what you can do is run the scan with the check alive option disabled. This way, the scanner will no longer try to determine if the host is alive, but just start scanning for open ports.

If you are in any situation from above, and the “No open ports” finding is still shown, we suggest trying to scan with a wider input port range.

For example, if you are only scanning for the Top 100 ports, you might want to pick a larger list of common ports, or just use the full range of ports: 1-65535.

Something is blocking the connection to the target?

If the same result shows, then the target indeed does not have any open ports, or the host is behind a firewall that cannot permit our scanner to detect the port status.

There could also be cases when the result returns ports behind a tcpwrapped service. When the port scan labels something tcpwrapped, it means that the behavior of the port is consistent with one that is protected by a tcpwrapper (which is a host-based network access control program on Unix and Linux - read more here).
This means that a full TCP handshake was completed, but the remote host closed the connection without receiving any data. Basically, a valid tcpwrapped response indicates a real network service is available, but you are not on the list of hosts allowed to talk with it.

If all ports on a host come back as filtered, there's either nothing there, or there's a firewall configured to drop all traffic directed to it.

If you are certain that ports should be opened but the result might show no open ports, filtered ports, or are returning as tcpwrapped, you should whitelist our scanner IPs and try scanning again.

If you want to learn more about how the check-alive mechanism offered by the Pentest-Tools.com platform works, you can read the following article:

How do we determine if a host is alive?

Did this answer your question?