ICMP guide: ping, traceroute, and network diagnostics

ICMP rides alongside IP to report network conditions. A host, router, or firewall can send ICMP messages when a destination is unreachable, a packet expires in transit, fragmentation is needed, or a diagnostic echo request needs a reply.

The most familiar ICMP workflow is ping. A client sends an echo request, and the target replies with an echo reply. The round-trip time gives a quick signal about reachability and latency, but it does not prove that an application port such as 443 or 22 is open.

ICMP does not use TCP or UDP port numbers. It uses message types and codes. That is why an ICMP guide should not be treated like a normal open-port article: you are deciding whether to allow specific ICMP messages, not whether a daemon is listening on a numbered port.

A port checker tests TCP or UDP service reachability. Ping tests ICMP reachability. Both are useful, but they answer different questions. A server can block ping while HTTPS works, or respond to ping while every application port is closed.

Ping checks whether a target responds to ICMP echo and how long the round trip takes. It is useful for quick reachability checks, monitoring probes, and latency baselines.

Traceroute maps the path by sending packets with increasing TTL values and reading ICMP time exceeded messages from routers along the way. Some platforms use UDP or TCP probes for traceroute, but ICMP messages are still central to how many path diagnostics report intermediate hops.

Allow ICMP when monitoring systems, load balancers, network teams, or operations staff need reachability and latency signals. For internal networks, allowing controlled ICMP often improves troubleshooting and reduces blind spots.

For public systems, many teams allow limited echo replies from trusted monitoring sources and allow essential error messages such as fragmentation-needed or destination-unreachable behavior. The exact policy should match your network edge, DDoS posture, and observability needs.

Before blocking or allowing ICMP, decide which messages you are controlling. Echo request, echo reply, time exceeded, destination unreachable, and packet-too-big behavior have different operational impact.

Avoid a blanket block unless you understand the tradeoff. Blocking all ICMP can break path MTU discovery, hide useful routing errors, make monitoring less accurate, and force teams to debug with weaker signals.

On Windows, Windows Defender Firewall has predefined ICMP echo rules that can be enabled for selected profiles and source addresses. Scope rules to trusted networks where possible instead of enabling broad public ping responses by default.

On Linux, nftables, iptables, firewalld, and cloud security groups can allow or limit ICMP by type. Many distributions also expose kernel sysctl settings for echo behavior, but firewall policy is usually the clearer control point.

On cloud platforms, security groups often treat ICMP separately from TCP and UDP. Check both inbound and outbound policies, and remember that load balancers, CDN edges, and provider DDoS controls may handle ICMP differently from instance firewalls.

Use ping to test echo request and reply. Use traceroute or tracert to inspect the path and identify where packets stop, keeping in mind that some routers intentionally suppress ICMP responses or rate limit them.

If ping fails but an application works, ICMP may be blocked while TCP or UDP is allowed. If ping works but the application fails, the target is reachable at the network layer but the specific service port, firewall rule, listener, or application may be broken.

If ping times out, the target may be down, a route may be missing, ICMP echo may be blocked, or an intermediate firewall may be dropping the message. Timeouts do not automatically prove the host is offline.

If traceroute stops at a hop, that hop may be filtering TTL-expired responses or rate limiting diagnostics. If large transfers fail while small requests work, check path MTU discovery and whether packet-too-big messages are blocked.

Allow ICMP deliberately rather than reflexively blocking everything. Rate limit echo traffic, scope public responses where appropriate, and preserve important error messages needed for stable networking.

Monitor unusual ICMP volume, spoofed sources, and flood patterns at the edge. For sensitive networks, combine ICMP policy with segmentation and trusted monitoring rather than relying on ping visibility as a security boundary.