ICMP Destination Unreachable and Packet Too Big PCAP Analysis: What the Network Is Telling You
How to analyze ICMP Destination Unreachable, Port Unreachable, Host Unreachable, Fragmentation Needed, Packet Too Big, policy filtering, and path MTU evidence in PCAP files.
A vague UDP timeout or stalled large transfer may have an explicit explanation in ICMP: Port Unreachable, Host Unreachable, Fragmentation Needed, Packet Too Big, or Time Exceeded. Decode the type/code, quoted original packet, source, MTU value, and timing to connect the control message to the failed flow instead of treating all Destination Unreachable messages alike. The PCAP preserves the network's reported reason; it does not guarantee the reporting router is the component that caused the original condition.
PCAP Surgery is useful because ICMP messages are small but important. They are easy to lose when trimming a capture. If you remove them, you may remove the network's explanation.
ICMP is error reporting
ICMP does not carry application data. It reports network-layer conditions. For troubleshooting, ICMP can reveal:
- Destination host unreachable.
- Destination network unreachable.
- Port unreachable.
- Communication administratively prohibited.
- Fragmentation needed.
- IPv6 packet too big.
- TTL exceeded.
- Redirects or routing behavior.
Each message should be interpreted with the original packet that triggered it.
Port unreachable
For UDP, port unreachable is common. If a host receives UDP for a closed port, it may reply:
ICMP Destination Unreachable: Port Unreachable
This can explain DNS, syslog, telemetry, QUIC, RTP, or custom UDP failures. The application might call it a timeout, but the network capture shows an explicit rejection.
If no ICMP response appears, the packet may have been dropped silently.
Host or network unreachable
Host/network unreachable messages suggest routing or reachability problems. They may come from an intermediate router, firewall, gateway, or local host.
Important questions:
- Who sent the ICMP message?
- Which original packet triggered it?
- Does it affect all destinations or one subnet?
- Does routing change during the capture?
- Is a VPN or tunnel involved?
The source of the ICMP message often identifies the device that knows about the problem.
Fragmentation needed and Packet Too Big
For IPv4 with Don't Fragment set, routers may send "Fragmentation Needed" when a packet exceeds path MTU. For IPv6, "Packet Too Big" is essential for Path MTU Discovery.
If these messages are present and the sender adapts, PMTUD works. If they are absent or blocked, large packets may vanish and the connection may stall.
This evidence is critical for VPN, tunnel, cloud overlay, and large TLS handshake problems.
Administratively prohibited
Some ICMP unreachable messages indicate policy filtering. That is different from a host being down. A firewall or router may explicitly say communication is prohibited.
If you see policy-related ICMP, the right team is often firewall/network policy, not application development.
Checklist
Use this process:
- Filter ICMP and ICMPv6.
- Identify message type and code.
- Identify who sent the ICMP message.
- Inspect the embedded original packet.
- Correlate ICMP timing with application failure.
- Preserve ICMP when trimming the capture.
- For Packet Too Big, inspect MTU value and whether sender adapts.
- For Port Unreachable, identify UDP service and port.
- For policy messages, identify firewall or gateway source.
- Compare with routing/VPN topology.
Final diagnosis
ICMP messages are not noise. They are network-layer evidence. Destination Unreachable, Port Unreachable, Fragmentation Needed, Packet Too Big, and policy messages can explain failures that applications report only as timeout or reset.
PCAP Surgery helps preserve these small but decisive packets so the final trace still contains the network's own explanation.
Decode the quoted original packet
ICMP errors include part of the packet that triggered them. Use the quoted IP header and transport fields to connect the message to a flow. The outer source identifies the reporting node; the embedded source/destination and ports identify the affected packet. NAT can make the quoted tuple differ across capture points.
| Field | Why it matters |
|---|---|
| Outer ICMP source | Node reporting the condition |
| Type and code | Specific unreachable/MTU policy |
| Quoted source/destination | Original traffic direction |
| Quoted protocol/ports | Application flow correlation |
| Reported MTU | Sender adaptation target where valid |
| Time from original packet | Connects error to retry/timeout |
Do not attribute the root cause solely to the ICMP sender. A gateway may report that a later route is unavailable, and a firewall may generate an administratively prohibited message using an interface address.
IPv4 Destination Unreachable cases
Common codes distinguish network, host, protocol, port, fragmentation-needed, and administratively prohibited outcomes. Display names vary by analyzer. Preserve the numeric type/code in the report so wording cannot erase the distinction.
Correlating Port Unreachable
For UDP, this often means the destination host received the datagram but no socket accepted the port. It may also be generated by a firewall. Correlate source address, TTL/MAC, host logs, and whether the response appears at a capture near the destination.
Fragmentation Needed
For IPv4 DF traffic, Type 3 Code 4 can carry the next-hop MTU. Confirm the quoted packet, reported value, sender adaptation, and repeated large-segment behavior. Continue with the MTU black-hole guide.
Correlating Administratively Prohibited
This is explicit policy feedback, not proof the host is down. Give firewall/network policy owners source device, rule/counter time, quoted flow, and direction.
IPv6 differences
IPv6 routers do not fragment transit packets. ICMPv6 Packet Too Big is essential to PMTUD. Neighbor Discovery also depends on ICMPv6. Broadly blocking ICMPv6 can break address resolution, routing, and large transfers while small tests appear healthy.
| ICMPv6 evidence | First interpretation |
|---|---|
| Destination Unreachable / no route | Reporting node lacks route/policy permits |
| Administratively prohibited | Explicit policy boundary |
| Address unreachable | Destination resolution/reachability lead |
| Port unreachable | UDP destination port rejection |
| Packet Too Big | Path MTU feedback with reported MTU |
| Time Exceeded | Hop-limit expiry or reassembly timeout |
Can an ICMP error itself be filtered?
Yes. Compare both sides of the firewall/tunnel. If Packet Too Big appears near the constraining router but not at the sender, PMTUD feedback is being lost within that span. Device counters and policy logs locate the exact owner.
Are ICMP rate limits relevant?
Routers and hosts may rate-limit errors. Absence during a high-rate test does not prove the condition did not occur. Use controlled low-rate probes and inspect counters. A single visible message can explain many later silent drops.
Application examples
For DNS/UDP, match query transaction and embedded UDP tuple. For QUIC, an ICMP Port Unreachable can cause rapid fallback or failure, but encrypted application state needs client logs. For traceroute, Time Exceeded is expected control behavior rather than an outage. For TLS, Packet Too Big may correspond to the larger certificate flight.
Never treat every ICMP as malicious or every unreachable as final. Some applications retry another address, resolver, or transport. Preserve the subsequent behavior to explain user impact.
Verify sender adaptation
After Packet Too Big or Fragmentation Needed, inspect whether the sender reduces packet size, changes MSS on a new TCP connection, or continues retransmitting the same large range. A feedback packet without adaptation can indicate endpoint PMTUD handling failure or invalid/untrusted feedback.
| After ICMP | Conclusion lead |
|---|---|
| Smaller packets resume successfully | PMTUD feedback worked |
| Same large packet repeats | Sender did not adapt or ICMP unmatched |
| New path/connection succeeds | Failover may mask original path issue |
| ICMP never reaches sender point | Feedback filtering/path asymmetry |
Actionable report and QA
Include outer ICMP source, numeric type/code, capture point, quoted original tuple, reported MTU, original-to-error delay, sender adaptation, retries, route/tunnel context, and matching device counters. State whether the reporting source is proven to be the enforcing device.
For regression, reproduce one valid control and the prior failing condition. Require the expected feedback, endpoint adaptation, application success, and absence of the former timeout. Test IPv4 and IPv6 separately because their fragmentation rules differ.
Retain original packet, ICMP error, adaptation/retry, and application outcome. Use capture scope help and the packet preparation workflow so trimming does not separate the network’s explanation from the packet it quotes.
Should ICMP be allowed everywhere?
Policy should permit the required types and codes according to network design and security review, with validation and rate controls where appropriate. “Block all ICMP” is not a safe generic recommendation, especially for IPv6 and PMTUD.
Validate that the ICMP message belongs to the incident
Busy captures contain control messages for unrelated flows. Match the quoted packet to the exact client, destination, protocol, ports, identifier, and time. For NAT or tunnels, map inner and outer identities. A Packet Too Big quoting another tenant or an old flow cannot explain the current timeout.
Check that the reported MTU is plausible for the interface and path. Invalid or spoofed ICMP can be ignored by hardened stacks. Endpoint logs and sender adaptation reveal whether the message was accepted. Do not recommend relaxing validation merely to make a synthetic test pass.
Can traceroute ICMP be mistaken for an outage?
Yes. Time Exceeded is expected when a probe deliberately expires its TTL/hop limit. Correlate the quoted probe and application. Normal traceroute responses do not indicate production packets exceeded hop limit.
Why can UDP applications report only timeout after Port Unreachable?
Socket APIs and application libraries handle asynchronous ICMP differently. Connected UDP may surface an immediate error, while unconnected or higher-level code may retry or report a timeout. The PCAP provides explicit network feedback even when UI copy does not.
What privacy does quoted payload expose?
ICMP includes part of the original packet and may reveal addresses, ports, identifiers, protocol headers, or initial payload bytes. Treat it as sensitive and include it in the PCAP privacy review.
Owner matrix
| Observed message | Primary next owner |
|---|---|
| Port Unreachable from destination | Service/listener owner |
| No route/host unreachable from gateway | Routing/platform owner |
| Administratively prohibited | Firewall/policy owner |
| Packet Too Big reaches sender, no adaptation | Endpoint network-stack owner |
| Packet Too Big blocked between points | Firewall/tunnel owner |
| Time Exceeded on ordinary traffic | Routing loop/hop-limit investigation |
A concise handoff says what the router reported and what the endpoint did next. This avoids turning a valuable control message into generic “network unreachable” wording.
Preserve at least one successful control flow across the same route. Compare packet size, address family, DF behavior, tunnel state, and endpoint adaptation. A small successful ping is not a useful control for a large encrypted transfer.
After policy changes, verify required ICMP reaches the endpoint and the application succeeds; do not judge success only by the disappearance of visible errors.
<!-- multilingual-related-reading:start -->Related guides
Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic:
<!-- multilingual-related-reading:end -->