Advanced Tracerouting

A common misunderstanding of traceroute is that it fully relies on ping. “If I block ping at my firewall, no one can use traceroute to reveal my internal routing path”. Unfortunately, this is not true. If traceroute is used with TCP SYN packets on permitted TCP/UDP ports, all intermediary firewalls will handle the IP packets with TTL = 0 corresponding to the RFCs and will reply with an ICMP time exceeded packet to the source.

In this post, I am listing an example that uses traceroute with TCP port 25 (SMTP) to traverse a firewall. A sample pcap file can be downloaded while some Wireshark screenshots show a few details.

Traceroute is not Ping

The basis to understand is that traceroute is NOT ping though it is commonly sent via ICMP echo requests. The core of traceroute is that routers are decrementing the hop count (TTL) in the IP header which is independent of the upper layer protocol! By using traceroute, it starts with a TTL of 1 and increments it after every packet. The IP packets that are used for traceroute can either transport ICMP echo requests or any other (!) protocol such as UDP or TCP. In the latter case, TCP SYN packets on a specific destination port, e.g., 80 for HTTP, are sent.

The answers of middle routers that traverse back to the host are ICMP time exceeded messages. (Wikipedia: Traceroute, Time to Live (Hop Limit), ICMP Time Exceeded.)

Traversing Firewalls

Consider a firewall that resides between the Internet and a DMZ. In the DMZ, a web server listens on port 80 and the firewall permits that port. No other services are allowed through the firewall. That is: Ping is denied and therefore a traceroute with ICMP echo requests is denied, too. BUT: Since TCP on port 80 must be allowed in order to use the web server, a traceroute with TCP SYN on port 80 will succeed. (Though there might be situations in which an administrator blocks the handling of time exceeded packets explicitly.) That is: You have an option to reveal the internal routing path though ping was denied.


I am using a Linux computer with the  traceroute command. Without any options, it uses some UDP high ports. “-I” forces it to use ICMP echo-request packets. “-T” uses TCP SYN packets that can be set to a specific port with “-p “. The same can be used for UDP “-U“.

Here is an example in which I issued three different traceroutes to my mail server:

  1. plain traceroute: no final response since dynamic UDP ports are not allowed
  2. traceroute with ICMP: ditto
  3. traceroute on TCP port 25 (smtp): reveals all hops :)

Of course, the same is true for IPv6:

pcap and Wireshark

This is the pcap file that consists of a sample run via IPv6 and TCP Port 25:

Otherwise here are two Wireshark screenshots that give an idea how TCP SYN packets to port 25 while incrementing the hop limit look alike:

Featured image: “Spuren von Tiefschnee-Geniessern” by Isabelle Pagano is licensed under CC BY-NC 2.0.

4 thoughts on “Advanced Tracerouting

  1. Hi, I am trying to use the cmd line to gain an understand of the physical hardware that the tracert requests are running through. Does tracert in Windows offer any further options in which a networks topologies could be layed out, beyond the simple, time-out length and IP address?

    1. Hey Andrew. Huh, that’s probably hard. With Linux you can use the -A option to have the AS numbers displayed.

      If you want to find out more information about the hardware you can run a port scan with OS detection such as Nmap is doing it:
      Don’t know if there are other, more reliable, techniques to do that. I suppose not.


Leave a Reply

Your email address will not be published. Required fields are marked *