Understanding the Protocol Difference
The core of this issue lies in how ping and traceroute operate differently at the network layer. The ping command uses Internet Control Message Protocol (ICMP) type 8 (Echo Request) and type 0 (Echo Reply). Most firewalls allow these packets through to verify basic reachability and latency.
In contrast, traditional Linux traceroute uses User Datagram Protocol (UDP) by default. It sends UDP packets with incrementally increasing Time-To-Live (TTL) values. When a router receives a packet with a TTL of 1, it decrements it to 0, discards the packet, and sends back an ICMP type 11 (Time Exceeded) message. If your firewall or the remote network blocks incoming UDP traffic or outgoing ICMP error messages, the traceroute will appear to hang or fail entirely, even though ping works perfectly.
Checking Firewall Rules on the Local Machine
Before assuming the remote server is the problem, you must verify that your local Linux system is not dropping the necessary packets. Use iptables -L -n -v to inspect your current filter rules. Look for chains named INPUT, OUTPUT, and FORWARD.
If you see rules explicitly rejecting or dropping UDP traffic, this is likely the culprit. For example, a rule like -A INPUT -p udp -j DROP would block the traceroute probes. Similarly, if you have strict egress filtering, ensure that ICMP type 11 messages are allowed to leave your interface so that upstream routers can communicate their status back to you. You can temporarily disable the firewall using systemctl stop iptables or ufw disable to test if connectivity improves. If traceroute works after disabling the firewall, you need to adjust your rules to permit UDP ports above 32768 and ICMP errors.
Testing with TCP Traceroute
A reliable workaround for UDP-blocking environments is to use TCP-based traceroute utilities. On many Linux distributions, the mtr tool or tracepath may handle this differently, but specifically, you can use traceroute with the -T flag to force TCP mode. Alternatively, the tcptraceroute utility is designed specifically for this scenario.
sudo tcptraceroute -p 80 target_host.com
This command sends SYN packets to port 80 instead of UDP packets. Since most web servers accept TCP connections on port 80, and firewalls often allow established TCP sessions, this method bypasses the UDP restrictions that were causing your original failure. If this succeeds, you confirm that the issue is strictly related to UDP packet filtering rather than general routing problems.
Investigating Remote Server Restrictions
Sometimes, the problem is not on your end but on the destination server or intermediate hops. Many cloud providers and enterprise networks drop ICMP time-exceeded messages to prevent topology discovery and potential DDoS attacks. If you suspect this, check the related guide on Troubleshooting Dropping Packets in iptables: tcpdump Analysis and Solutions to understand how packet loss manifests in logs.
You can use tcpdump on your local machine to capture packets during the traceroute attempt:
sudo tcpdump -i eth0 icmp
If you send the probe but never see the ICMP type 11 responses in the capture, the packets are being dropped somewhere in the path. In such cases, there is no configuration change you can make locally to fix it; you must rely on alternative tools like ping or TCP-based tracers to estimate hop counts.
Configuring Persistent Firewall Exceptions
If you determine that your local firewall is indeed blocking the traffic, you should add specific exceptions rather than leaving the firewall open. For systems using iptables, you might add a rule to accept UDP traffic on high ports:
sudo iptables -A OUTPUT -p udp --sport 32768:65535 -j ACCEPT
Ensure you also accept incoming ICMP type 11 messages:
sudo iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
Remember to save these rules appropriately for your distribution, whether using netfilter-persistent or firewalld. Always test changes carefully to avoid locking yourself out of remote administration interfaces.
Frequently Asked Questions
Why does ping work but traceroute hangs?
Ping uses ICMP Echo Requests which are commonly allowed by firewalls, while traceroute uses UDP packets that are frequently blocked. Additionally, traceroute relies on receiving ICMP Time Exceeded messages from intermediate routers, which may also be filtered out.
How can I run traceroute without root privileges?
Standard traceroute requires root access to create raw sockets. However, you can use tracepath, which does not require special permissions and uses ICMP Echo Requests with increasing TTLs, similar to ping but with hop counting.
Is tcptraceroute safer than standard traceroute?
TCP-based traceroute is often more effective in modern networks because TCP traffic is less likely to be dropped by stateful firewalls compared to UDP. It mimics actual web traffic, making it harder for intrusion detection systems to flag as malicious scanning activity.
Can AWS or Azure block traceroute?
Yes, many cloud providers restrict ICMP and UDP traffic between instances for security reasons. If you are testing connectivity between cloud VMs, check the security group rules to ensure UDP and ICMP types are permitted in both inbound and outbound directions.
What does a 'Request Timed Out' mean in traceroute?
This indicates that the probe packet reached a hop, but no response was received within the timeout period. This could mean the router is configured to ignore ICMP errors, or the return path is asymmetric and blocked by a firewall on the way back.