You may be familiar with the standard old traceroute that relies on ICMP echo request and echo reply packets to identify the path to a target and verify the target reachability. If so... how many times have you not reached the target because they filter ICMP echo replies?
An example of this would be when you try to traceroute to http://www.microsoft.com/. You'll see right after you hit the msn.net domain routers you are left in the dust. It really isn't that unusual to block ICMP echo requests at servers - no one should be pinging them anyway, right?
An example of this would be when you try to traceroute to http://www.microsoft.com/. You'll see right after you hit the msn.net domain routers you are left in the dust. It really isn't that unusual to block ICMP echo requests at servers - no one should be pinging them anyway, right?
Using TCP Traceroute
Using NetScanTools Pro, I typically use TCP traceroutes. In the Traceroute tool, click the Setup button and choose TCP (WinPcap). You can define the starting hop, timeout in miliseconds, and retries at this point, but I go directly down to the TCP Trace Specific area.
Using NetScanTools Pro, I typically use TCP traceroutes. In the Traceroute tool, click the Setup button and choose TCP (WinPcap). You can define the starting hop, timeout in miliseconds, and retries at this point, but I go directly down to the TCP Trace Specific area.
Here's how the TCP Traceroute works - NetScanTools sends out a series of TCP SYN (handshake) packets to the target. It increments the Time-to-Live (TTL) value in the IP header (just as an ICMP traceroute does) to locate routers along the path who respond with ICMP Time to Live Exceeded in Transit messages. When the hop count is high enough to allow the TCP SYN to make it to the target, that target MUST respond - hey those are the rules of TCP. The target must respond with either a TCP SYN/ACK (indicating the target port is open) or a RST (reset, indicating the target port is closed). In this case, we don't really care if the target port is open or closed - we're just trying to get the roundtrip time using traceroute.
Firewalled/Blocked Targets
Now we know the specs for TCP say the target must respond... but what if it doesn't? What could have happened. Well... either your TCP SYN packet never made it there or the TCP SYN/ACK or RST never made it back. Make sure you run your TCP traceroute a few times to ensure sporadic packet loss isn't to blame. Most likely it is likely a firewall or some other blocking device that in your way. You couldn't find the roundtrip time, but you did find a protected host.
FYI - NetScanTools Pro 2-for-1 Price
As you may know, NetScanTools is on my 'must have' list of tools for IT professionals. The new version (updated today) is available at www.netscantools.com. There is also a 2-for-1 sale online through June 15, 2009.
Learn More
In the upcoming "Trace Back to a Suspect Host" course (June 4) I'll demonstrate each form of traceroute along with numerous other invasive/non-invasive techniques for testing connectivity, paths, identities and relationships of targets. Register online at www.chappellseminars.com/sem-traceback.html.
Laura
