VMware ESXi and vSphere Cluster Management

Nmap Timing Templates and Scan Speed Options

Learn how Nmap timing templates from -T0 to -T5 affect scan speed, retries, reliability, and port-state results in authorized environments.

Nmap is a network discovery and security-auditing tool. Its scan duration and result quality depend not only on the target, but also on how quickly probes are sent and how long Nmap waits for replies. Timing templates provide simple, predefined controls for this behavior.

Use these options only against systems and networks that you are authorized to assess. A fast scan is useful only when its results are reliable enough for the assessment.

Why Nmap timing matters

Port scanning duration is affected by several conditions:

Latency: the delay between sending a probe and receiving a response.
Packet loss: probes or replies that fail to reach the other endpoint.
Target responsiveness: how quickly the host and its services process scan traffic.
Rate limiting: deliberate slowing or dropping of traffic by a host, firewall, intrusion-prevention system, or network device.
Retransmissions: repeat probes sent when an expected response does not arrive in time.
Port range: scanning more ports or more hosts generally requires more work.

Nmap timing controls determine how aggressively it sends probes and how it responds to missing replies. More aggressive timing generally reduces waiting and may reduce the time spent on retransmissions. However, shorter waits or fewer effective retries can cause delayed responses to be missed.

Timing template syntax

A timing template is a predefined Nmap timing profile selected with the -T option. The general form is:

nmap -T<0-5> <target>

For example:

nmap -T3 192.168.5.102

The numeric templates range from -T0 through -T5. -T3, called normal, is Nmap's default timing template when no timing template is specified.

Nmap timing templates at a glance

Template value	Template name	Relative speed	Typical authorized use case	Reliability and operational considerations
`-T0`	Paranoid	Slowest	Highly sensitive, fragile, or operationally restricted systems where a very cautious pace is required.	Minimizes scan pace but can take a very long time. It is not a guarantee that traffic will be undetected or harmless.
`-T1`	Sneaky	Very slow	Low-impact testing where the assessment window permits a cautious scan.	Usually more tolerant of slow paths than fast templates, but still depends on target and network behavior.
`-T2`	Polite	Slow	Unstable, busy, high-latency, or operationally sensitive authorized environments.	Often a useful lower-impact comparison with the default. Expect a longer runtime in many conditions.
`-T3`	Normal	Moderate; default	Baseline discovery and assessment on ordinary authorized networks.	Good starting point because it provides a familiar reference for later comparisons.
`-T4`	Aggressive	Fast	Reliable, stable authorized networks with a defined time window and sufficient capacity.	Can finish sooner, but delayed or dropped replies may affect completeness. Validate important findings.
`-T5`	Insane	Fastest	Controlled lab comparisons or exceptionally reliable authorized environments where speed has priority.	Most likely to sacrifice completeness under latency, loss, filtering, congestion, or rate limiting. Use cautiously.

These labels describe relative behavior, not guaranteed scan times. The same template can finish quickly on one network and slowly on another because Nmap adapts to observed conditions and may wait for or retry missing responses.

Choosing a timing level

Choose a template using four main criteria:

Network stability: stable, low-loss networks can usually tolerate more aggressive timing than congested or unreliable paths.
Target sensitivity: fragile devices, production systems, and operationally important services may justify a slower pace.
Assessment time window: a short approved window may require faster timing, but only if the resulting confidence is acceptable.
Risk of missed results: if completeness matters more than speed, prefer the default or a slower template and validate unusual results.

Start with -T3 for a baseline. Use -T2 or slower when the environment is unstable, high-latency, or operationally sensitive. Consider -T4 only when authorization and network conditions support it. Reserve -T5 for tightly controlled comparisons or conditions where its risks are understood.

Speed versus accuracy and completeness

When Nmap does not receive a response, it may wait and send a retransmission. Aggressive timing can reduce waiting periods and the amount of time spent retrying. That can improve completion time, but it also increases the chance that a delayed response will arrive too late to influence the result.

A port can therefore appear filtered when the real cause is a dropped or late response. A service can also fail to be identified if the packets needed for that conclusion are lost. This does not mean every filtered result is a timing error: firewalls and access-control devices commonly produce filtered states.

Two scans of the same host can report different counts of open, closed, and filtered ports when their timing differs. The target may not have changed. Instead, one scan may have received replies that the other scan missed, or one may have retried probes more successfully.

An open port has evidence that a service is accepting connections.
A closed port is reachable, but Nmap received evidence that no service is listening.
A filtered port cannot be determined confidently because filtering or missing responses prevents a definitive conclusion.

Lab comparison: slow and fast scans

Use a known, authorized lab host to compare a slower template with a very aggressive one. Record the elapsed time, port-state totals, and warnings for every run.

1. Establish the default baseline

nmap -T3 192.168.5.102

Record the scan completion line, elapsed time, and the number of open, closed, and filtered ports. This is the comparison point for the other scans.

2. Run a slower scan

nmap -T2 192.168.5.102

In many environments this takes longer than the baseline. Compare its port-state totals with the -T3 run rather than assuming that the slower run must always find more ports.

3. Run an aggressive comparison

nmap -T5 192.168.5.102

Compare the elapsed time with the -T2 run. Look for retransmission-related warnings and differences in the reported states. If the fast scan reports fewer ports or materially different states, treat that as a reason to validate the result, not as evidence that the target changed.

Command	Elapsed time	Open ports reported	Closed ports reported	Filtered ports reported	Warnings observed	Interpretation
Baseline/default scan: `-T3`	Record from completion line	Record output	Record output	Record output	Record any warning	Reference result for comparison.
Slower scan: `-T2`	Record from completion line	Record output	Record output	Record output	Record any warning	Compare for completeness and operational impact.
Fast scan: `-T5`	Record from completion line	Record output	Record output	Record output	Check especially for retransmission-cap warnings	Faster does not necessarily mean more complete; validate differences.

Reading timing-related output

Scan completion and elapsed time

The scan completion line indicates that Nmap finished the requested scan and includes the elapsed duration. Use that duration to compare runs only when the target, port scope, scan technique, and surrounding network conditions are comparable.

Port-state summaries

Summaries such as a number of closed or filtered ports describe the states Nmap reported for the scanned scope. A larger filtered count can indicate firewall behavior, but it can also result from missing replies caused by loss, congestion, or an overly aggressive timing choice.

Retransmission-cap warnings

Nmap may report that it stopped retrying a port after reaching its retransmission cap. A retransmission cap is the limit at which Nmap gives up repeating a probe. This warning means Nmap did not obtain enough responses within its retry policy; it does not by itself prove that the port is closed.

Possible causes include filtering, congestion, rate limiting, an inconsistent target, packet loss, or timing that is too aggressive for the path. Record the warning with the finding and qualify conclusions that depend on the affected port.

Packet tracing for diagnosis

--packet-trace displays packet send and receive activity. It can help show whether Nmap is receiving delayed replies, retransmitting probes, seeing filtering behavior, or receiving no response at all.

nmap -T4 --packet-trace -p 80,443 192.168.5.102

Keep packet tracing selective. Use a small, authorized target and a narrow port set because the output is verbose. Compare the trace with the timing choice:

Repeated probes can indicate missing or late responses.
A response arriving after a delay can explain why a faster run differed from a slower run.
Consistent silence may be compatible with filtering, but packet tracing alone cannot identify every device or policy causing it.
Different behavior between timing templates can reveal the effect of wait periods and retransmissions.

Common timing-related symptoms

Observed symptom	Likely contributing factors	How to verify	Safer corrective action
The aggressive scan is much faster but reports fewer ports.	Packet loss, high latency, rate limiting, shorter waits, or fewer effective retries.	Repeat with `-T3` or `-T2`; narrow the inconsistent port set; use `--packet-trace` selectively.	Reduce timing aggressiveness and validate important ports.
Nmap says it is giving up on a port after reaching the retransmission cap.	Inconsistent target responses, filtering, congestion, rate limiting, or an overly aggressive template.	Rerun the affected ports more slowly and inspect packet behavior in the authorized environment.	Use a slower template, check reachability, and document the warning.
Many ports are shown as filtered.	Firewall or access-control filtering, late responses, or packet loss.	Compare a slower template and trace a small port set.	Do not equate filtered with closed or open; gather additional evidence.
The scan takes much longer than expected.	A slow template, large port range, many hosts, high latency, packet loss, or retries.	Confirm the target and port scope, then review the completion time and warnings.	Use `-T3` as a baseline and increase speed only when authorization and result quality permit.

Reliable timing workflow

Confirm scope and authorization. Identify the approved hosts, ports, scan window, and operational limits.
Run a baseline with -T3. Save the command and output, including elapsed time and warnings.
Assess conditions. Consider latency, loss, target sensitivity, firewall behavior, and rate limiting.
Slow down when needed. Use -T2 or a slower template for unstable, high-latency, or sensitive systems.
Use faster settings deliberately. Choose -T4, or in a controlled lab comparison -T5, only when the network and time constraints support the risk.
Repeat material differences. Narrow the scan to inconsistent ports and rerun with a less aggressive template.
Diagnose selectively. Use --packet-trace on a small scope when packet loss, filtering, or retries need investigation.
Document the decision. Record the timing template, scan scope, elapsed time, warnings, and any qualifications attached to the findings.

Exam-relevant notes

-T0 is paranoid, -T1 is sneaky, -T2 is polite, -T3 is normal and the default, -T4 is aggressive, and -T5 is insane.
Higher template numbers generally mean faster and more aggressive timing, not guaranteed accuracy.
Latency, packet loss, target responsiveness, rate limiting, retries, and port range all affect scan duration.
A retransmission-cap warning means Nmap stopped retrying; it does not prove that the port is closed.
--packet-trace is a diagnostic option for viewing sent and received packets and should be used on a narrow authorized scope.
If timing changes produce materially different results, validate them instead of assuming either scan is definitive.

For a practical starting point, use Nmap timing options with -T3, compare cautiously with slower or faster templates, and interpret missing responses as uncertainty that may require follow-up.