Debugging Traceroute Failures: Why Am I Getting Asterisks (* * *) When Network Connectivity is Fine?


1 views

When you see a series of asterisks (* * *) in your traceroute output, it typically indicates that your ICMP packets reached that hop but either:

  1. The router didn't respond to ICMP requests
  2. The response was filtered by a firewall
  3. There was packet loss at that hop

Before diving deep, let's verify some basics:

# Check if basic connectivity works
ping -c 4 google.com

# Try with explicit ICMP (default)
traceroute -I google.com

# Alternative using UDP (traditional method)
traceroute -U google.com

# Try with different packet sizes
traceroute -m 30 -q 3 -w 2 -z 100 google.com

1. ICMP Filtering

Many network devices block ICMP for security reasons. Try alternative protocols:

# TCP-based traceroute (often bypasses filters)
sudo traceroute -T -p 80 google.com

# Or using mtr (combines ping+traceroute)
mtr --report google.com

2. Firewall Rules

Check your local firewall settings:

# For iptables users
sudo iptables -L -n -v | grep icmp

# Temporary allow ICMP (for testing)
sudo iptables -I INPUT -p icmp --icmp-type echo-request -j ACCEPT

3. Network Path Asymmetry

Some networks have different paths for requests and replies. Try:

# Increase wait time and number of queries
traceroute -w 5 -q 5 google.com

Packet Capture Analysis

Use tcpdump to see what's actually happening:

sudo tcpdump -i eth0 -n icmp or udp port 33434-33534

Alternative Tools

When traditional traceroute fails, consider:

# Using tracepath (kernel-based, often more reliable)
tracepath google.com

# Paris-traceroute (handles NAT and load balancers)
sudo apt install paris-traceroute
paris-traceroute google.com

In AWS EC2, you might encounter this due to security groups:

# AWS security group rule to allow ICMP
aws ec2 authorize-security-group-ingress \
    --group-id sg-12345678 \
    --protocol icmp \
    --port -1 \
    --cidr 0.0.0.0/0
  • Test multiple protocols (-I, -T, -U)
  • Verify both IPv4 and IPv6 paths
  • Check intermediate firewalls/NAT devices
  • Try from different network locations
  • Capture packets at both ends if possible

When your Linux system returns nothing but asterisks in traceroute output while maintaining normal network connectivity, several technical factors could be at play. Let's examine this common but puzzling scenario:

$ traceroute -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 ...

Modern networks often block traceroute traffic for security reasons. Try these alternative approaches:

# Try TCP traceroute
$ sudo traceroute -T -p 443 google.com

# Or use UDP with different ports (DNS port example)
$ traceroute -U -p 53 8.8.8.8

# ICMP traceroute (sometimes allowed when UDP is blocked)
$ traceroute -I google.com

Check these system settings that might affect traceroute:

# Check ICMP rate limiting
$ sysctl net.ipv4.icmp_ratelimit
$ sysctl net.ipv4.icmp_ratemask

# Verify reverse path filtering
$ sysctl net.ipv4.conf.all.rp_filter

Modern cloud environments often implement these behaviors:

  • Load balancers dropping traceroute packets
  • SDN architectures with hidden hops
  • Anycast routing causing inconsistent paths

When traceroute fails, consider these alternatives:

# mtr combines ping and traceroute functionality
$ mtr --report-wide google.com

# tcptraceroute for TCP-based path discovery
$ sudo tcptraceroute -p 443 google.com

# Paris-traceroute for NAT/firewall environments
$ paris-traceroute google.com

For deep troubleshooting, capture the traffic:

# Capture ICMP traffic
$ sudo tcpdump -i eth0 'icmp' -w trace.pcap

# Or filter UDP traceroute packets
$ sudo tcpdump -i eth0 'udp and port 33434-33534' -w udp_trace.pcap