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:

• 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.
• An address restriction excludes the host. A credential scoped to specific addresses or ranges is never tried against a host outside that scope.
• 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.
• Authentication is not succeeding. A credential that works elsewhere can still fail on this host or this port. The scan log records the attempt.
• 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.
• 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.

This is usually a reachability problem. Discovery itself returns quickly, and the engine then spends time attempting to connect to ports it cannot reach, with each attempt timing out before it moves on.

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:

[10.4.90.12:5432] Port was found open during pre-port discovery but failed during liveness probing. This may be caused by a host-level firewall or similar network restriction blocking external access to the port.

This per-port detail comes from the scan target monitor, which is on by default; if it has been disabled, the log names only the affected host. Test one of the ports from the engine host, then allow the engine through to the ports you intend to scan.

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 three consequences for the host:

• No service is identified on a port the engine cannot reach, so nothing behind it is assessed.
• Each attempt has to time out before the engine moves on, so the host takes longer to scan than it otherwise would.
• The engine reads repeated connection failures as a sign that the host itself has stopped responding. It can therefore stop examining the host early, report a finding saying the host scan was terminated because of excessive connection errors, and return that host’s results as incomplete.

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, the engine then attempts it, and those attempts are what cost you the time and the finding. The finding describes the engine’s experience of the host, not the health of the host. The scan log names a host-level firewall or similar network restriction as a possible cause.

On a host where pre-port discovery finds ports the engine cannot reach, you can end up with less information about that host than a network port scan would have given you and wait longer for it. 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.

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.

Pre-port discovery is most valuable when the engine has broad network reachability to the hosts it scans, and the challenge is scan accuracy or speed rather than network segmentation. On heavily segmented networks, where the engine is intentionally limited to a handful of ports per host, a network port scan may still be the better fit.