Nmap Timing Templates: Picking -T for Real Networks

Nmap’s -T flag looks like a single dial running from paranoid to insane, but it is shorthand for five separate timing primitives: parallelism, inter-probe delay, RTT timeout bounds, retry count, and host timeout. Pick a template without knowing what it changes underneath, and you get scans that finish fast and report confidently wrong results, especially across a WAN link, a VPN tunnel, or anything sitting behind a firewall with rate limiting turned on. This is a breakdown of what each template actually sets, where the shorthand stops being good enough, and how to check whether a completed scan actually saw the target or just gave up on it politely.

What -T0 through -T5 actually change

The templates are not six independent speed settings. They are six preset combinations of the same underlying variables: how many probes run in parallel, how long nmap waits between them, how it bounds the round-trip-time timeout used to decide a probe was lost, how many times it retries a non-responsive probe, and how long it will wait on an unresponsive host before moving on.

Exact millisecond values shift slightly between nmap releases, so treat the table as the shape of the behavior, not a spec to cite verbatim. The pattern that matters: as you move from T0 to T5, nmap trades patience (how long it waits, how many times it asks again) for throughput. Below T3, scans get slower but converge on the same answer a full-retry scan would give. From T4 up, nmap starts assuming the network itself is reliable enough that a lost probe means the port is unresponsive, not that the packet got dropped somewhere in the path.

Why -T4 is the common default and where it starts dropping ports

T4 is the default recommendation in most nmap guides and CTF writeups because it is tuned for the case that dominates practice: a scanner sitting on the same LAN segment, or close to it, as the target, with sub-10ms latency and negligible loss. On that network, cutting retries from 10 to roughly 6 and capping the RTT ceiling near 1.25 seconds costs almost nothing in accuracy, because a real response almost never takes that long to arrive.

The assumption breaks the moment round-trip time or loss rises. Two concrete thresholds to watch for:

• Baseline RTT to the target above roughly 200ms, common on cross-region cloud links or scans routed over a slow VPN. T4’s tightened ceiling starts timing out probes that were simply still in flight, not lost.
• Path loss above roughly 1-2%, common on congested WAN links, wireless backhaul, or any hop doing active traffic shaping. With retries cut to 6, a lost probe followed by a lost retry is enough to flip a genuinely open port to filtered or closed in the final report.

The visible symptom is run-to-run inconsistency: scan the same host twice with -T4 across a lossy link and the reported open port count varies by a handful of ports between runs. On a stable LAN, two -T4 runs against the same host will almost always agree exactly. If they do not, that disagreement is diagnostic, not noise, and it means the template’s assumptions do not hold for that path.

Tuning the underlying primitives directly instead of using a template

Once a network stops matching the LAN assumption baked into T3-T5, the fix is not to pick a different letter, it is to set the underlying flags directly and stop relying on the template’s bundled defaults:

• –max-retries <n>: decouple retry count from timeout ceiling. A lossy but low-latency link often needs more retries with a short timeout, the opposite of what T2 gives you.
• –initial-rtt-timeout, –min-rtt-timeout, –max-rtt-timeout: set these from a measured baseline. If ICMP or a TCP handshake to the target averages 80ms, set initial-rtt-timeout around 250-300ms (roughly 3x baseline) and max-rtt-timeout around 1500-2000ms so real but slow responses are not discarded.
• –scan-delay / –max-scan-delay: use this to stay under a known firewall or IPS threshold rather than accepting whatever a template’s default happens to be.
• –min-rate / –max-rate: cap packets-per-second explicitly. This matters more than parallelism on links where the bottleneck is a stateful device, not bandwidth.
• –host-timeout: set explicitly on large ranges so a handful of dead hosts do not stall the whole job, independent of per-probe retry tuning.

A representative WAN-safe command for a full TCP port sweep against a target with measured 90ms RTT and occasional loss: nmap -sS -p- --max-retries 4 --initial-rtt-timeout 300ms --max-rtt-timeout 1800ms --max-scan-delay 20ms --max-rate 300 target. That is more verbose than -T3, but it is reproducible and documented, which matters when someone has to explain later why a scan took four hours or why it found nothing on a host that turned out to have twelve open ports. Environments that scan the same set of network classes repeatedly benefit from keeping a small set of named profiles like this rather than re-deriving flags each time; this is the kind of per-segment configuration that belongs in whatever tool handles scan scheduling and target grouping, so the right profile is attached to the right subnet automatically instead of depending on whoever kicks off the job that day.

Firewall and IPS behavior that silently turns fast scans into inaccurate scans

A stateful firewall or IPS does not usually announce that it started rate limiting you. It just changes behavior mid-scan, and nmap has no way to distinguish “this port is genuinely filtered” from “this device decided thirty seconds ago that my source IP looks like a scanner and is now dropping everything from it.” Both report as filtered.

Common triggers worth knowing before you pick a timing profile for a perimeter scan:

• SYN-flood protection on the edge device: many firewalls (ASA, Palo Alto, FortiGate) apply per-source connection-rate thresholds that were sized for flood mitigation, not for tolerating a legitimate full-range scan. Once tripped, new SYNs from that source get silently dropped or RST’d, sometimes for a cooldown period measured in minutes.
• ICMP rate limiting: Linux hosts default to limiting outbound ICMP error generation (kernel parameter net.ipv4.icmp_ratelimit, commonly 1000/sec, but network appliances in the path often enforce far lower limits). Host discovery pings and traceroute-style probes degrade quietly under this, producing false “host down” results.
• IDS/IPS rate-based signatures: Suricata and Snort ship rules that alert, and can be configured to block, on a threshold like N SYNs to distinct ports from one source within a short window. A -T4 or -T5 sweep of a /24 will cross that threshold in seconds on most default rulesets.

The practical effect: a scan that starts clean and degrades into a wall of filtered ports halfway through is not reporting a topology fact, it is reporting a rate-limiting event. Classifying that correctly, rather than recording “200 filtered ports” as if it described the actual firewall ruleset, is exactly the kind of ambiguity that a dedicated reachability analysis step is meant to resolve before the result feeds into anything downstream, since a filtered verdict caused by self-inflicted rate limiting should not be treated the same as a deliberate ACL.

Verifying accuracy: rescanning a sample at a slower rate to measure loss

The only reliable way to know whether a fast scan missed anything is to rescan a sample slowly and diff the results. The method:

1. Pick a representative sample: 5-10% of hosts in a large range, or one full subnet if the range is small enough to matter individually.
2. Rerun the same port list against that sample with a conservative profile: -T2 or hand-set flags with --max-retries 10 and no rate cap.
3. Diff the two port lists per host, using grepable output (-oG) piped through a simple comparison script or comm on sorted host:port pairs.
4. Set a decision threshold before you look at the numbers, not after: if the slow rescan finds more than roughly 2% additional open ports, or any port flips from closed to open rather than staying consistent, treat the fast profile as unreliable for that network class and drop the whole range to the slower one.

This is the same discipline that governs whether a fix should be marked resolved in a vulnerability workflow: a finding that does not reappear on a single fast pass is not confirmed closed, it has to be reconfirmed under conditions that isolate the variable that changed. Platforms that automate this phase, such as SITEY, re-run the specific check under a controlled profile before marking a finding closed, rather than trusting a single scan pass, which is the same reasoning applied to timing accuracy here: one result at one speed is a data point, not a verdict. That logic maps directly onto how a retest and closure step should be scoped for scan-derived findings specifically, since a port that only shows open under -T2 needs the same second look before it drives a ticket.

Template choices for internal LAN, WAN links, and filtered perimeters

A short decision list, in order of how much a scan operator actually needs to think about it:

• Internal LAN, switched, sub-5ms latency, no active IPS: T4 is fine for full port sweeps. T5 is acceptable for host-discovery-only passes but should not be trusted for a complete port list, since its cut-down retry budget starts costing accuracy even on fast networks once a switch or NIC drops the occasional frame.
• Site-to-site WAN or VPN, 20-150ms RTT, moderate loss: T3, or the hand-tuned flags from the tuning section above, with initial-rtt-timeout set from a measured baseline rather than left to the adaptive default.
• Cross-region cloud links, RTT above 150ms: custom flags only. Raise the RTT ceiling, lower max-parallelism to somewhere in the 20-50 range, and expect the scan to take meaningfully longer than the same range would on a LAN.
• Filtered perimeter with an IPS or WAF in front: T1 or T2, with scan-delay set explicitly under whatever rate threshold the device enforces, if that threshold is known. Split large ranges across time rather than compensating with more parallelism, and always follow with the sample rescan described above.

Products that orchestrate multiple scan engines, including SITEY across its 17 integrated scanners, generally keep a short library of named timing profiles like this mapped to network classes, rather than one global -T value applied everywhere, because a perimeter-safe profile that never touches an internal LAN wastes hours, and an aggressive LAN profile pointed at a filtered edge produces a report that looks complete and is not. The template is a starting point. The profile that actually matches a given network is something worth writing down once and reusing, not re-deriving from a hunch every time a scan window opens.

About SITEY

SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.