Packet Tracing in Nmap

Learn how to use Nmap --packet-trace to inspect sent and received packets, interpret ICMP and TCP responses, understand Nsock and DNS activity, and troubleshoot scan results.

Nmap normally ends with a concise report: whether a host appears up, which ports have particular states, and an estimate of response latency. The --packet-trace option adds the evidence behind that report by displaying packet activity and related diagnostic events.

Use packet tracing only against systems and networks you own or are authorized to assess. Trace output can expose internal addresses, resolver activity, ports, timing, and packet metadata. Protect or redact it before sharing.

What Nmap Packet Tracing Shows

Packet tracing exposes the network packets Nmap transmits and the responses it observes. It is useful when you need to understand why a host was classified as up or down, why a port received a particular state, or why a scan appears to receive no replies.

Packet tracing is different from the normal scan report:

• Trace output: Low-level evidence such as protocols, addresses, ports, flags, header values, and timing.
• Final report: Nmap's concise interpretation, such as a host being up or a TCP port being closed.

The trace is Nmap's local view of transmitted and received traffic. It is not guaranteed to contain every network event. Packets can be dropped before reaching the target, on the return path, or by the local operating system.

Enabling Packet Tracing

Add --packet-trace to an Nmap command. It can be combined with host discovery, port scanning, version detection, and other scan modes.

nmap -sn --packet-trace 192.0.2.25

Tracing can produce substantially more terminal output than a normal scan. Begin with one authorized host and a small set of ports. Expanding the target range too early makes it harder to associate each reply with the probe that caused it.

Basic Host-Discovery Example

The -sn option performs host discovery without performing a port scan. This command checks one example private lab address and displays the probes and responses:

nmap -sn --packet-trace 192.0.2.25

Depending on privileges, operating system, target address, and Nmap's discovery rules, the trace may show several probe types. Examples include ICMP Echo Requests, ICMP Timestamp Requests, and TCP-based probes. Using multiple probe types improves the chance of receiving a useful response when one protocol is filtered.

Look for:

1. Probe lines marked SENT.
2. Matching response lines marked RCVD.
3. The final host-status and latency line.

Reading SENT and RCVD Records

SENT identifies a packet transmitted by the scanning system. RCVD identifies a packet received by the scanning system. A useful first step is to pair each received packet with the preceding probe by checking the protocol, addresses, ports, and timing.

Interpreting ICMP Probe Output

ICMP, the Internet Control Message Protocol, carries network-control and reachability messages. An ICMP Echo Request is the familiar ping request. An ICMP Timestamp Request is another ICMP message that Nmap may use during discovery.

ICMP messages contain a type and code. The type identifies the broad message category, while the code supplies a more specific reason or variant. You do not need to memorize every value to use a trace: first identify whether the message is a request, a valid reply, or an error.

A valid ICMP reply supports the conclusion that the host is reachable and therefore can support an up determination. However, no ICMP reply alone does not prove that the host is down. Firewalls, endpoint settings, routing problems, and filtering can suppress ICMP while the host remains online.

Interpreting TCP Probe Output

TCP probes contain a source port and destination port. The destination port is normally the port being tested; the source port identifies the temporary endpoint chosen by Nmap. Always confirm both addresses and ports before attributing a response to a probe.

• SYN: Requests or begins a TCP connection attempt.
• ACK: Acknowledges TCP data or connection state.
• RST: Resets or rejects a TCP connection attempt.

For a narrow TCP trace, use a small port list:

nmap -p 80,443 --packet-trace 192.0.2.25

A response with SYN and ACK semantics commonly indicates that the target accepted the initial connection attempt, which supports an open classification when the scan method expects that exchange. A TCP RST can indicate that the host is reachable but rejected the probe because the port is closed. An intermediary can also generate an active rejection, so a reset is evidence of a response, not proof of a particular service.

Trace output may also show TCP sequence numbers, window size, and options such as MSS. A sequence number tracks TCP data and connection state. The window size is the receive capacity advertised in a packet. MSS, or Maximum Segment Size, indicates the largest TCP payload a peer can accept in one segment. These values are useful metadata, but deep TCP implementation analysis is usually unnecessary for basic scan troubleshooting.

Understanding IP-Header Fields

Several IP-header fields provide useful clues:

• TTL: Time To Live is reduced by each routing hop. Comparing TTL values can help identify changes in routing or suggest that responses use different operating-system defaults.
• IP ID: The IPv4 identification field is used during packet processing and may help compare related packets.
• Packet length: The size reported for the packet can help distinguish message types and identify unexpected changes.

TTL, IP ID, length, and similar fields are diagnostic clues, not definitive evidence of an operating system or network topology. Network devices can rewrite fields, operating systems can customize defaults, and different paths can produce different observations.

Nsock Diagnostic Messages

Nsock is Nmap's event-driven networking library. Nsock diagnostic lines describe asynchronous socket and event activity, not necessarily a packet captured on the wire.

Common event-related activity includes:

• Creating or closing a socket.
• Starting a UDP connection attempt.
• Requesting a read or write.
• Running a callback when an operation completes.
• Deleting an event from the event queue.

UDP socket activity is often associated with supporting work such as DNS lookups or reverse DNS resolution. Keep these records separate from packet records when analyzing a target response.

DNS-Related Activity in Trace Output

Nmap may contact a configured DNS resolver while preparing or reporting scan information. A reverse DNS lookup maps an IP address to a hostname, commonly through the IPv4 in-addr.arpa naming system. This can cause UDP and Nsock lines to appear even when the target scan itself is minimal.

Resolver traffic is distinct from traffic sent to the scan target. Check the destination address: the target address belongs to the system being assessed, while the resolver address belongs to the DNS service handling the lookup.

If DNS activity obscures the question you are investigating, adjust name-resolution behavior separately. For example, Nmap's -n option disables DNS resolution, while -R requests DNS resolution. Choose the setting that matches the diagnostic goal rather than treating resolver events as target responses.

Relating Trace Details to the Final Scan Result

The final report is the high-level conclusion; the trace supplies supporting context. To connect them, compare:

1. Target address: Confirm that the response came from the intended host.
2. Protocol and probe: Identify whether the evidence was ICMP, TCP, or another protocol.
3. Response timing: Relate elapsed time to the reported latency.
4. Response behavior: Interpret a valid ICMP reply, TCP reset, SYN/ACK-style response, error, or lack of response.
5. Classification: Check how that behavior supports the reported host or port state.

For example, an ICMP reply can support an up-host result, while a TCP reset on port 80 can support a closed-port result. No visible reply may reflect filtering or packet loss rather than a definitive down or closed state.

Common Trace Observations

Practical Troubleshooting Workflow

1. Start narrowly. Select one authorized target and, for a port scan, only the ports relevant to the question.
2. Run without tracing. Record the normal summary so you know the high-level result.
3. Run the same scan with --packet-trace. Compare the summary with the low-level evidence.
4. Map probes to responses. Match addresses, ports, protocol, flags, and timing.
5. Check local network details. Verify the chosen interface, local source address, route, and target address when packets are sent but no responses appear.
6. Classify the behavior. Distinguish no response, TCP reset, ICMP error, DNS activity, and delayed responses.
7. Corroborate important conclusions. Use controlled lab testing or an independent packet-capture tool such as tcpdump or Wireshark when appropriate.

When Packets Are Sent but No Target Response Appears

Possible causes include an offline target, a firewall that drops probes, an incorrect route or interface, an incorrect source address, or blocked host-discovery methods. Confirm the target address and local routing first. Then try a narrowly scoped, authorized alternative probe type and compare results from the same network segment when possible.

When a TCP RST Appears

Confirm that the source and destination addresses and ports match the sent probe. Compare behavior across a small set of authorized ports. A reset shows active rejection or response behavior; it does not identify the service running on a port.

When DNS Traffic Is Unexpected

Identify the resolver address and DNS port, then separate resolver communication from target communication. If name resolution is irrelevant, adjust Nmap's resolution behavior so that supporting DNS events do not obscure the target trace.

When the Trace Is Too Large

Reduce the scan to one host, a minimal port list, and only the features needed for the question. Keep the relevant lines and annotate which response belongs to each probe. This is more reliable than trying to interpret a large multi-target trace at once.

Authorization and Operational Considerations

Key Exam Notes

• --packet-trace displays packet send and receive activity and related low-level diagnostics.
• -sn performs host discovery without a port scan.
• SENT means Nmap transmitted a packet; RCVD means Nmap observed a received packet.
• ICMP replies can support an up determination, but no ICMP reply does not prove a host is down.
• A TCP RST commonly indicates rejection, often from a closed port, but an intermediary may also send it.
• Nsock lines describe asynchronous application-level socket events and must not be confused with packet records.
• DNS and reverse DNS activity can appear even during a minimal target scan.
• TTL, IP ID, sequence numbers, window size, and MSS are clues rather than definitive operating-system or topology evidence.
• The final scan report is the conclusion; packet tracing provides the evidence and troubleshooting context.

For a related reference, see Packet Trace.