VMware ESXi and vSphere Cluster Management

UDP Scanning with Nmap

Learn how Nmap UDP scans work, how to interpret open, closed, filtered, and open|filtered states, and how to scope, improve, troubleshoot, and report authorized UDP assessments.

UDP scanning discovers services that use the User Datagram Protocol (UDP), such as DNS, DHCP, NTP, NetBIOS Name Service, and SNMP. These services may be absent from a TCP-focused assessment, so UDP discovery is an important part of an authorized network review.

Why UDP Scanning Matters

TCP services are often assessed first because TCP provides a connection-oriented model and usually produces clear responses during scanning. However, many essential infrastructure services use UDP. Examples include DNS name resolution, DHCP address assignment, NTP time synchronization, NetBIOS name service, and SNMP monitoring.

A host that appears to expose no TCP services may still provide useful or sensitive functionality over UDP. UDP scanning can therefore reveal services that affect authentication, name resolution, device management, time synchronization, or network configuration.

UDP Protocol Characteristics

UDP, or User Datagram Protocol, is a connectionless transport protocol. Unlike TCP, UDP does not establish a session with a TCP-style handshake before application data is sent. A sender transmits a datagram without first negotiating a connection.

This simplicity makes UDP useful for applications that value low overhead or can handle lost and reordered messages themselves. It also makes port scanning less definitive. A TCP scanner can often infer state from handshake responses, while a UDP scanner may receive no response from either an open service or a filtered port.

UDP scans are often slower than comparable TCP scans. When a probe receives no response, Nmap may need to wait for a timeout and retransmit before deciding how to classify the port. Firewalls, packet loss, ICMP rate limiting, and target-side behavior can increase this delay.

Starting a UDP Scan with Nmap

Nmap's UDP scanning mode is enabled with -sU. The general form is:

nmap -sU <target>

For example, this scans the default UDP port selection on an authorized host:

nmap -sU 192.0.2.10

Raw packet scanning may require elevated privileges, depending on the operating system, local security policy, and Nmap installation. If Nmap reports permission or packet-generation errors, use an approved scanning host and the authorized privileges required by that system.

How Nmap Evaluates UDP Ports

Nmap sends UDP probes to the selected target ports. The exact probe can vary according to the port and detection logic. Nmap then evaluates UDP replies, ICMP errors, and the absence of responses.

• Valid UDP response: A service-specific reply generally provides evidence that the port is open.
• ICMP Port Unreachable: An ICMP Port Unreachable response commonly indicates that the UDP port is closed. The usual case is ICMP type 3, code 3, meaning destination port unreachable.
• No response: Nmap frequently reports open|filtered. The port may be open but silent for the probe, or a firewall may be silently dropping the packet.
• Other ICMP unreachable responses: Network or host filtering indications can result in a filtered classification.

Because many UDP applications do not reply to arbitrary datagrams, a lack of response is not proof that no service exists. Likewise, a port number alone does not prove which application is running.

UDP Port-State Interpretation

The pipe character in open|filtered is significant: it represents uncertainty between two possible states. Treating every such result as an exposed service can produce inaccurate findings.

Reading UDP Scan Output

A typical Nmap report begins with host availability information. The host status indicates whether Nmap considers the target reachable, and the latency line estimates the response delay observed during discovery or scanning. These values describe the path and target responsiveness; they do not prove that a particular UDP service is available.

The detailed port table normally includes:

• PORT: The port number and transport protocol, such as 53/udp.
• STATE: Nmap's interpretation, such as open, closed, filtered, or open|filtered.
• SERVICE: A likely service name based on the port database or detection results.

Representative entries might look like this:

PORT    STATE         SERVICE
53/udp  open          domain
123/udp open|filtered ntp
161/udp open          snmp
137/udp closed        netbios-ns

In this example, DNS and SNMP produced evidence of reachable services. NTP is ambiguous: it could be open but not responding to the probe, or filtered. NetBIOS Name Service is reported closed because the target indicated that the UDP port was unreachable.

Nmap may summarize ports that are not shown individually, for example:

Not shown: 997 open|filtered udp ports

This summary does not mean that 997 services were confirmed open. It means Nmap could not distinguish those ports from filtered ports. An unknown service label similarly means that Nmap lacks a reliable mapping or detection result; it does not mean that the port is harmless.

Choosing Scan Scope

Nmap's default UDP port selection does not cover every UDP port. Begin with a targeted list when the assessment has a known objective, then expand coverage when authorization, time, and operational constraints permit.

Selected UDP ports

nmap -sU -p 53,67,68,123,137,161,162 192.0.2.10

This approach is useful for checking common infrastructure services. Correlate the result with the asset's role and business context before drawing conclusions.

A defined UDP range

nmap -sU -p 1-1024 192.0.2.10

A range provides broader coverage but can take substantially longer than an equivalent TCP scan because of UDP timeouts and retransmissions.

All UDP ports

nmap -sU -p- 192.0.2.10

The -p- option requests all 65,535 UDP ports. Use it only when the scope, scan window, and target capacity allow it. A staged plan—common ports first, followed by wider coverage—usually provides useful results sooner and reduces unnecessary operational impact.

Improving Service Identification

Port numbers are conventions, not proof. A service may use a nonstandard port, and a registered port may be used by a different application. Nmap's service detection sends additional probes intended to identify the application and, where possible, its version.

nmap -sU -sV -p 53,123,161 192.0.2.10

Service detection can improve confidence, but it adds traffic and time. Use it after discovery or alongside a targeted UDP scan when the additional probing is justified. Important findings should also be validated with authorized, service-specific checks and contextual evidence such as asset inventory, configuration review, and service-owner confirmation.

Performance and Reliability

UDP results are affected by more than the target port state. Rate limits, packet loss, firewalls, intrusion detection or prevention systems, ICMP rate limiting, network segmentation, and target-side access-control lists can all change the observed result.

ICMP rate limiting is the throttling of ICMP error messages. If a device limits how many errors it sends, Nmap may receive fewer closed-port indications and may need more time to reach a conclusion.

Aggressive timing can increase packet loss or trigger network controls, producing results that are faster but less reliable. Prefer cautious timing appropriate to the approved scan window and network sensitivity. Do not assume that a fast scan is an accurate scan.

• Start with likely UDP ports or a small range.
• Allow sufficient time for no-response probes and retransmissions.
• Rescan ambiguous, high-value ports rather than treating one result as definitive.
• Compare results from an approved network vantage point when segmentation or ACLs may affect visibility.
• Record the source location because local host firewalls, routing, and network position can change the result.

Saving and Reporting Results

Save scan artifacts so that findings can be repeated, compared, and reviewed later. The -oA option writes three related files using the supplied base name: normal output with a .nmap suffix, XML output with a .xml suffix, and grepable-compatible output with a .gnmap suffix.

nmap -sU -p 53,123,161 -oA udp-assessment 192.0.2.10

For each assessment, record the target scope, authorization reference, date and time, command options, source location, relevant network conditions, and how ambiguous states were interpreted. Preserve the original output separately from any edited report.

Practical Workflow

1. Confirm written authorization, target scope, scan window, and permitted rate.
2. Run a targeted scan of services relevant to the host's role.
3. Review host availability, latency, port states, service labels, and omitted-port summaries.
4. Use -sV selectively where service identification matters.
5. Rescan important open|filtered ports and validate them with approved service-specific checks.
6. Expand to a range or all UDP ports only when broader coverage is required and operationally acceptable.
7. Save output and document both confirmed evidence and unresolved uncertainty.

Troubleshooting Common Results

Most or all ports are open|filtered

UDP services may not respond to Nmap's probes, a firewall may silently drop packets, or network filtering may prevent useful ICMP responses from returning. Treat the result as ambiguous, rescan a limited set of important ports, use authorized service detection or protocol-specific validation, and review firewall policy if administrative access is available.

The scan is much slower than a TCP scan

No-response probes require timeout handling, ICMP responses may be rate-limited, or the selected range may be too broad. Start with likely ports, allow a realistic scan window, and avoid excessively aggressive timing that could increase packet loss and reduce accuracy.

A known UDP service is not reported as open

The service may restrict clients by source address or network segment, a firewall may block probes or replies, the application may require a protocol-specific request, or it may use a nonstandard port. Confirm the scanning vantage point, scan the expected port explicitly, use -sV where suitable, and review the target configuration if authorized.

Nmap reports an unknown UDP service

The port may be nonstandard, Nmap may lack a confident behavioral mapping, or a custom application may be present. Do not infer the application solely from the port number. Use service detection and approved validation, then correlate the finding with inventory and service-owner documentation.

Nmap cannot send the required packets

The operating system may require elevated permissions for raw packet operations, or local endpoint security may restrict packet generation or capture. Run Nmap with the required authorized privileges, verify local policy and installation permissions, or use an approved scanning host.

Exam-Relevant Notes

• -sU is Nmap's UDP scan option.
• UDP is connectionless and has no TCP-style handshake.
• ICMP Port Unreachable commonly indicates a closed UDP port.
• A valid UDP response supports an open classification.
• No response commonly produces open|filtered, which is not proof that the port is open.
• UDP scans are often slower because of timeouts, retransmissions, and ICMP rate limiting.
• -sV adds service and version probing but also adds traffic and time.
• Default UDP coverage is limited; use -p for selected ports, a range, or -p- for all ports.
• Always interpret results in the context of firewalls, segmentation, ACLs, and the scan vantage point.

For related study, review UDP scanning with Nmap alongside TCP scanning, service detection, firewall behavior, and network service enumeration.