Enable credentialed pre-port discovery

Pre-port discovery reports the ports a host is listening on, and the scan engine then connects to each one in turn. A port the engine cannot reach costs you both scan time and coverage, so test reachability before you enable the option rather than after.

Log in to the scan engine host and try the connection yourself with a representative sample rather than every port (one or two of the service ports you expect on each network segment you plan to scan this way):

# Linux or macOS
nc -vz <host> <port>
 
# Windows PowerShell
Test-NetConnection -ComputerName <host> -Port <port>

Pre-port discovery applies to a host only when at least one in-scope credential matches it. Three things determine the matching process:

• Address restrictions - A credential scoped to specific addresses or ranges is never tried against a host outside that scope.
• Credential scope - A site-scoped credential applies only to its own site, and a shared credential has to be enabled for the site being scanned.
• Host type - SSH credentials drive pre-port discovery on Linux, macOS, and other Unix-like hosts. A Windows host needs a Scan Assistant or Windows credentials.

The default ports are TCP 22 for SSH and TCP 21047 for the Scan Assistant. If the service listens somewhere else, set that port on the credential’s port restriction. A credential’s port restriction is a single port, so there is no range to get wrong.

A credential left on the default while the service listens elsewhere fails to authenticate and falls back to a network port scan. For example, an SSH credential restricted to port 2222 is tried on 2222 but not on 22.

Pre-port discovery has to choose a port before it can authenticate, and it chooses one per credential:

• By default it uses the standard port for the method: TCP 21047 for the Scan Assistant, TCP 22 for SSH.
• A credential restricted to a single port is tried on that port instead. This is how you cover a service on a non-standard port.
• Credentials with different port restrictions are each tried in turn. If you have one Scan Assistant credential on the default port and another restricted to a custom port, the engine attempts each until one authenticates.

Your scan template’s port settings under Service Discovery tell the engine which ports to probe over the network. This includes the port range you have chosen and any additional or excluded ports. A host that pre-port discovery has already asked directly is not probed that way, so those settings do not limit its results.

• Results can include ports outside your configured range. Pre-port discovery reports what the host is listening on, and all of it is kept.
• An excluded port is still reported on that host. If you rely on an exclusion to keep a port out of your results, pre-port discovery does not apply it.
• Hosts that fall back to a network port scan are unaffected. They honor the template exactly as before.

If you need a host’s results confined to a specific set of ports, scan it with a template that has pre-port discovery turned off.

“Reported open” and “reachable” are not equivalent. Pre-port discovery reads the list of listening ports from the host itself, and from the host’s own perspective those ports genuinely are open. What the host cannot know is whether a firewall, security group, or other network control sits between it and your scan engine. Ports that a host exposes only to itself, and never to other machines, are excluded from the results.

A network port scan could never detect this because it reports a port as open only if the engine could actually reach it. Pre-port discovery deliberately trades that outside-in view for the host’s authoritative inside-out view.

It is therefore entirely possible for pre-port discovery to report a port as open that your scan engine cannot connect to. Consider a host listening on a database port across all interfaces, while a firewall permits that port only from your application servers and not from the scan engine’s subnet. Pre-port discovery reports the port as open because from the host’s point of view it is.

To learn more about reachability, see the FAQ.

Work through these in order. The first accounts for most cases:

1. SSH is not listening on port 22. With no port restriction on the credential, pre-port discovery tries only the standard port. If sshd listens on 2222, set the credential’s port restriction to 2222. The same applies to a Scan Assistant on anything other than TCP 21047.
2. An address restriction excludes the host. A credential scoped to specific addresses or ranges is never tried against a host outside that scope.
3. The credential is not in scope for the scan. A site-scoped credential applies only to its own site, and a shared credential has to be enabled for the site being scanned.
4. Authentication is not succeeding. A credential that works elsewhere can still fail on this host or this port. The scan log records the attempt.
5. The scan is not using the template you edited. Confirm that the site or scan runs the template you changed, and that you edited a custom template. Built-in templates cannot be modified.
6. The host is not Unix-like. SSH credentials drive pre-port discovery only on Linux, macOS, and other Unix-like hosts. A Windows host needs a Scan Assistant or Windows credentials.

In each of these cases, the host falls back to a normal network port scan. The result therefore looks the same as it did before you enabled the option, rather than appearing as an error.

Pre-port discovery found ports on the host that the scan engine cannot reach. The engine skips those ports and continues assessing the host’s reachable services, so the host is still scanned. What you lose is coverage of the unreachable ports themselves and some scan time, because the engine tries each unreachable port before moving on. The scan log names a host-level firewall or similar network restriction as the likely cause.

To find the unreachable ports, turn on Enhanced Logging in the scan template and rescan. The scan log then names each one with its host and port. See Use the scan log for the exact lines to look for.

To fix it, adjust your firewall or security-group rules so the engine can reach those services on the host. For hosts that are intentionally segmented off, use a template with pre-port discovery turned off instead.

There are two common reasons:

• A device in front of the host, such as a load balancer, address translation rule, or port forward, may have been answering on ports the host itself is not listening on.
• A network port scan saw those ports, and the host does not report them.

Ports bound only to loopback are also excluded because no other machine can reach them. If you need to know what answers at an address from the outside, scan it with a template that has pre-port discovery turned off.

Discovery and service identification are separate steps. Pre-port discovery asks the host which ports are listening, and service identification then connects to each port from the engine.

A discovered port with no service identified can mean the engine could not reach it, so test that port from the engine host.

Pre-port discovery keeps what the host reports it is listening on, so a port range and excluded ports do not narrow the results for a host it has asked directly. For more information, see Understand credentialed pre-port discovery.

This is expected. Pre-port discovery reports what the host is listening on, and a network control between the engine and the host does not change what the host is listening on.

Decide which view you want for that host: leave pre-port discovery on and allow the engine through, or scan the host with a template that has the option turned off.

Direct Windows discovery needs more of the network path open than a basic connection does. After an initial handshake, the session continues on a dynamically negotiated port, so make sure your firewall permits that negotiated range between the engine and the host and not only the initial port.

Deploying a Scan Assistant avoids this entirely because it uses a single, predictable port.

Pre-port discovery replaces the network port scan step only. Service identification, vulnerability checks, and policy evaluation run afterwards exactly as they do today, using the same credentials.

Pre-port discovery does not change how weak ciphers, expired certificates, or default credentials are found. Pre-port discovery produces the list of ports, and everything that examines those ports is unchanged. The engine still identifies the service on each one, analyzes TLS configuration and certificates, and runs default-credential checks.

When the engine can reach a port that a network port scan would have missed, the same checks run against the port.

The one change worth making is on hosts where SSH or Scan Assistant runs on a non-standard port: set that port on the credential’s restriction. See Restrict credentials for details.

TCP 21047 for the Scan Assistant, TCP 22 for SSH or the port set on the credential’s restriction, and TCP 135 plus a dynamically negotiated port for a direct Windows connection. If the engine cannot reach the relevant one, the host falls back to a network port scan.

Credentials are tried in priority order (Scan Assistant, SSH, then a direct Windows connection), and the first to authenticate is used. Others are not attempted.

Any attempt that fails does not prevent the others from being tried.

Enabling pre-port discovery does not change anything on hosts without credentials. Hosts without credentials and hosts where authentication fails are scanned exactly as before. That is why turning the option on costs you nothing on those hosts and why the fallback is not reported as an error.

After discovery, the scan engine moves on to examine each open port, which works by connecting to the port from the engine. When the engine tries to reach a port that a firewall is blocking, the connection times out.

This has two consequences for the host:

• No service is identified on a port the engine cannot reach, so nothing running behind that port is checked.
• Each unreachable port has to time out before the engine moves on, so the host takes longer to scan than it otherwise would.

The engine does not stop scanning a host just because some of its pre-discovered ports are unreachable. It records the unreachable ports, logs a warning that names a host-level firewall or similar network restriction as the likely cause, and continues assessing the host’s reachable services.

A port the engine cannot reach is one a network port scan would never have reported as open, so nothing would have tried to connect to it. Pre-port discovery reports it, and the engine then spends time attempting it. What this costs you is the coverage of that one port and the time spent trying, not the whole host. The discovery itself was accurate. What you see is the mismatch between what the host is listening on and what your network path allows the engine to reach.

A host that has no matching credential falls back to a network port scan. That host is not pre-discovered, so repeated connection failures can still stop its scan early.

In each case, the host is reporting its listening ports correctly, and something in the path prevents the engine from connecting. A firewall rule is the most familiar example, but it is not the only kind of control that can sit between the scan engine and a host. Any of the following can stop the engine reaching a port that the host is listening on:

• On the host itself. A local firewall can drop the connection even when the network path is open, and a service bound to an interface or address other than the one you are scanning does not answer there.
• In the network. Cloud security groups, network access control lists, VLANs and microsegmentation policy, and intrusion prevention or rate limiting can all allow a port from some networks and not others.
• In front of the host. Address translation, a port forward, or a load balancer means the engine is talking to something other than the host that reported the port.

If you are unsure whether the engine can reach a given port, test it from the engine host. To learn more about testing reachability, see Before you begin.

To decide whether pre-port discovery is the correct choice for a site, see Pre-port discovery limitations and best uses.