Do Linux (4.15.0-130) and Windows (10) treat ICMP differently?

Question

While attempting to troubleshoot a Windows 10 machine with erratic network problems, I did a traceroute to a host and got somewhat different results from what I see on my Ubuntu 18.04 system with kernel 4.15.0-130. In order to eliminate hardware factors, wonky protocol stacks, driver issues and the like I then compared Windows 10 in a VirtualBox VM running Linux with what the host system gives me. VirtualBox has been set up with NAT, i.e. Windows 10 connects to the host which then handles the actual network I/O. So both sessions are using the same network adaptor and everything goes through the same protocol stack on the host. There is no VPN involved; the client machine is simply hanging off a WiFi/3G Internet router.

The host I'm tracerouting can be reached from Linux (using the Firefox webbrowser) but not from Windows 10 (either on the other Windows 10 machine using Firefox or in VirtualBox using Chrome).

Windows (running in Virtual Box on Linux) gives me:

>tracert -d www.brewforafrica.co.za

Tracing route to www.brewforafrica.co.za [41.203.18.81]
over a maximum of 30 hops:

  1    <1 ms     1 ms    <1 ms  10.0.2.2
  2     3 ms     3 ms     3 ms  192.168.0.1
  3    56 ms    23 ms    36 ms  10.113.42.52
  4    83 ms    31 ms    22 ms  10.251.60.253
  5     *        *        *     Request timed out.
  6    74 ms    34 ms    29 ms  10.251.60.233
  7    88 ms    39 ms    20 ms  10.251.60.234
  8     *      103 ms    39 ms  10.113.145.33
  9    25 ms    33 ms    24 ms  196.207.35.36
 10    82 ms    32 ms    43 ms  192.168.133.110
 11    54 ms    25 ms    42 ms  41.21.235.25
 12    69 ms    80 ms    62 ms  10.118.24.61
 13   103 ms    35 ms    35 ms  196.60.9.24
 14    46 ms    45 ms    53 ms  197.189.193.1
 15    95 ms    53 ms    35 ms  41.203.18.81

Trace complete.

(Note: 10.0.2.2 is the default gateway address provided by VitualBox; Linux handles all networking from there on and therefore this hop is not present in the traceroute below.) Repeating the same traceroute using Linux (on the same system running the Virtual Box session with the above Windows 10 in it) gives me:

$ traceroute -n www.brewforafrica.co.za

traceroute to www.brewforafrica.co.za (41.203.18.81), 30 hops max, 60 byte packets
 1  192.168.0.1  1.416 ms  1.580 ms  1.668 ms
 2  10.113.42.52  24.311 ms  25.119 ms  38.804 ms
 3  10.251.60.253  39.793 ms  39.875 ms  39.922 ms
 4  * * *
 5  10.251.60.233  40.122 ms  41.365 ms  51.445 ms
 6  10.251.60.234  51.910 ms  50.416 ms  50.508 ms
 7  10.113.145.33  50.836 ms  27.691 ms  27.251 ms
 8  196.207.35.36  31.254 ms  73.984 ms  63.871 ms
 9  192.168.133.110  73.479 ms  73.528 ms  62.612 ms
10  41.21.235.25  52.088 ms  61.699 ms  61.572 ms
11  10.118.24.61  62.102 ms  62.275 ms  61.833 ms
12  196.60.9.24  61.680 ms  51.679 ms  39.123 ms
13  197.189.193.1  40.032 ms  40.073 ms  43.791 ms
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
$ 

What causes this difference and is it in any way significant?

Answer 1

It's not the same traceroute. Linux traceroute actually sends UDP probes by default, instead of ICMP Echo as Windows would. Use sudo traceroute --icmp to get something closer to Windows. (Try out mtr while you're at it.)

If the final system has a firewall which quietly discards UDP packets on unknown ports¹, the lack of response means that the traceroute program will have no way of knowing where they went, and indeed no way of recognizing that the probes have finally reached the final destination and that there's no need to keep probing larger and larger TTLs.

---

¹ The same would happen with any kind of traceroute probe², but dropping UDP is just far more common than dropping ICMP Echo. (It doesn't even have to be a deliberate block – some operating systems just do it by default, ignoring UDP and even TCP, staying quiet when the standards would call for an ICMP Port Unreachable. They often call this "stealth mode" and claim that it's somehow a security feature.)

² There is no dedicated packet type for traceroute; the tools just send whatever is likely to produce a response from the final host without confusing any real services – this includes ICMP Echo, but also UDP packets on high ports, even TCP SYNs.