Ping works but not traceroute


#1

Hello,

Server is debian 7. ping works but not traceroute/mtr. Funky nat/filtering in the infra?

root@c1-10-1-11-59:~# ping -c 1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=47 time=6.43 ms

— 8.8.8.8 ping statistics —
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 6.436/6.436/6.436/0.000 ms

root@c1-10-1-11-59:~# mtr -rc 1 8.8.8.8
HOST: c1-10-1-11-59 Loss% Snt Last Avg Best Wrst StDev

root@c1-10-1-11-59:~# traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
[…]


#2

This thread is quite old, but I’ll reply anyway, it may help someone else looking for the same answer.

In short: you can use dublin-traceroute with the option --dsr instead, as the regular traceroute won’t work with Scaleway.

Why? I just bought a VPS on Scaleway yesterday, to work on some feature for Dublin Traceroute’s. Unexpectedly no traceroute went through. After some troubleshooting with tcpdump, I found that Scaleway does some sort of DSR NAT (or a cheaper non-rewriting NAT), so the packets destined to your machine do not go again through their NAT, but they come directly from the destination.
Traceroute expects a fragment of the original packet (IP header + 8 more bytes from the overlaying protocol) in the ICMP TTL-exceeded responses. Normally the NATs take care of this, and the fragment will contain the source IP of your machine. In the case of Scaleway, they contain the source IP of the NAT box (in my case 163.172.187.153, which belongs to Scaleway). The trick was to modify my tool (dublin-traceroute) to stop matching the source IP if called with --dsr. The relevant commit if you care about the details is here, https://github.com/insomniacslk/dublin-traceroute/commit/3716453b9e0eeb05df6d3d7b1929b70adb8518a0#diff-81be5e38ca03613565c49e95e415855eL71 .


[SOLVED] Apt-get update not working
Outgoing SMTP connection issues
#3

I’ll add something more. Someone may say that it’s enough to use traceroute -I <target> (ICMP traceroute) rather than UDP or TCP when you get all asterisks in your traceroute after a certain point. In this case it’s different, and ICMP or TCP won’t help. I’ll show below an ICMP traceroute and a TCP traceroute from my Scaleway VPS, and at the end another made with Dublin Traceroute with --dsr.

ICMP traceoute:

# traceroute -I 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  10.2.172.10 (10.2.172.10)  0.505 ms  0.547 ms  0.547 ms
 2  * * *
 3  10.1.105.128 (10.1.105.128)  0.692 ms  0.864 ms  0.909 ms
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  google-public-dns-a.google.com (8.8.8.8)  6.037 ms  6.045 ms  5.739 ms

TCP traceroute

# tcptraceroute 8.8.8.8
Selected device eth0, address 10.2.172.11, port 55986 for outgoing packets
Tracing the path to 8.8.8.8 on TCP port 80 (http), 30 hops max
 1  10.2.172.10  0.331 ms  0.310 ms  0.208 ms
 2  * * *
 3  10.1.105.128  0.522 ms  0.539 ms  0.453 ms
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

Dublin Traceroute

# dublin-traceroute 8.8.8.8 -n1 --dsr
Starting dublin-traceroute
Traceroute from 0.0.0.0:12345 to 8.8.8.8:33434~33434 (probing 1 path, max TTL is 30)
== Flow ID 33434 ==
1    10.2.172.10 (10.2.172.10), IP ID: 44992 RTT 7375.614 ms  ICMP (type=11, code=0) 'TTL expired in transit', NAT ID: 0
2    *
3    10.1.105.128 (10.1.105.128), IP ID: 42400 RTT 4294645.972 ms  ICMP (type=11, code=0) 'TTL expired in transit', NAT ID: 0
4    *
5    212.47.225.188 (188-225-47-212.int.cloud.online.net), IP ID: 42398 RTT 783959.549 ms  ICMP (type=11, code=0) 'TTL expired in transit', NAT ID: 22215 (NAT detected)
6    195.154.1.38 (195.154.1.38), IP ID: 18315 RTT 783959.357 ms  ICMP (type=11, code=0) 'TTL expired in transit', NAT ID: 22215
7    72.14.218.182 (72.14.218.182), IP ID: 0 RTT 783959.102 ms  ICMP (type=11, code=0) 'TTL expired in transit', NAT ID: 22215
8    72.14.239.145 (72.14.239.145), IP ID: 0 RTT 783959.21 ms  ICMP (type=11, code=0) 'TTL expired in transit', NAT ID: 22215
9    216.239.46.207 (216.239.46.207), IP ID: 16712 RTT 783958.958 ms  ICMP (type=11, code=0) 'TTL expired in transit', MPLS(label=524896, experimental=4, bottom_of_stack=1, ttl=1), NAT ID: 22215
10    216.239.50.159 (216.239.50.159), IP ID: 40789 RTT 783958.878 ms  ICMP (type=11, code=0) 'TTL expired in transit', MPLS(label=474167, experimental=4, bottom_of_stack=1, ttl=1), NAT ID: 22215
11    209.85.243.65 (209.85.243.65), IP ID: 0 RTT 783958.815 ms  ICMP (type=11, code=0) 'TTL expired in transit', NAT ID: 22215
12    *
Saved JSON file to trace.json .
You can convert it to DOT by running python -m dublintraceroute plot trace.json


#4

I have actually renamed the --dsr option to --broken-nat, as this is definitely not DSR, but just a badly broken NAT (e.g. they may have disabled the payload fixup in their network devices)


#5

Good news, Scaleway updated their NAT so it’s fixed now! See https://github.com/insomniacslk/dublin-traceroute/issues/28


#6

Wow, just 3 years later? Amazingly fast. Not.