Ping works but tracert times out.

Hi,

Are you running ping and tracert from a Windows based machine?

Thanks all,
I am using window machines.
The ISP recomended using tracert because I am having trouble with smtp going out of our mail server.  Maybe tracert will not reveal any useful information, but I would like to know why the icmp works for ping but not for tracert.  

ICMP works for ping because it is only asking Google.com for a responce and google responds (this is also why your last hop in the tracert is working).  The hops are not working because the other hops (routers) may be configured not to responde to pings.

If you are having a problem with SMTP you may want to post another question with details on that problem.

eb

I have no idea if pathping works differently but you might want to try that tool also.

pathping google.com

Thanks for the info ebjers.

OK....
What I'm really trying to do is determine if the network performance problems are within our building or are the result of our ISP.  The ISP says everything is great on their end, but I've heard this before.  We have been having some apparent DNS issues and slow WAN times reported by the people in the office.  I have seen these pages loading very slowly myself on different work stations.  We have also had some smtp problems that may or may not be related.  I even suspected some sort of DoS, but I am no security expert.
Pathping yielded the following-not sure how to interperet.

C:\>pathping www.google.com

Tracing route to www.l.google.com [72.14.203.104]
over a maximum of 30 hops:
  0 admin.example.COM [10.110.10.25]
  1  ...
Computing statistics for 25 seconds...
            Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                           admin.example[10.110.10.25]
                              100/ 100 =100%   |
  1  ---     100/ 100 =100%     0/ 100 =  0%  admin.example.COM [0.0.0.0]

Maybe I'm going about this wrong. Is there a tool that can automatically ping or test in some manner the LAN and WAN for performance to localize problems?
Thanks Laura

rsivanandan
thanks for the help-as I already said, it's a T1 connection using a cisco 2524 and a PIX 506
GinEric
The firewall is not on windows it's a PIX 506 and the issue is on all workstation regardless of OS
Thanks

Configure the PIX and the router to respond to ping on the internal interface only (DO NOT ENABLE THIS ON THE EXTERNAL INTERFACE)
Create a rule on your PIX that will allow PING traffic to flow from the inside of your network out (DO NOT ALLOW INBOUND PINGS)

Also ethereal is great but I have found packitizer from network chemistry http://www.networkchemistry.com/products/packetyzer.php is easier to use and understand the results.  Also free like ethereal.

eb

Oh ok. What you can do is as I mentioned, just check out the data transfered which will give you an estimation of how traffic is going. 'Show int' will do the job. Post it here as well for us to take a look at it.

Cheers,
Rajesh

is pix  blocking? try bypassing pix letus know

regards
asim

What I said was that the router is not granting tracert execute privileges; it doesn't matter how it does this, what matters is that this firewall, pix or not, is blocking the tracert command.

tracert is not ping; therefore, just because ping works it does not mean that tracert will.

My tracert, by the Ethereal capture I just did, was sent out on ICMP and used port 1692 receive each query response from the DNS name server that is our main name server upstream.  Suppose the pix has this port turned off, then no response is the basic reply.  For each hop, TTL is increased by one, and what is expected is a timeout at each router along the way, mapping all the routers, basically all tracert does.  But not if ICMP or the query port 1692 at the source, the tracert sender, aimed at port 53 on its name server, up stream or not, is blocked; then you would get simply the timeouts and no report of who and why [the routers, time to live exceeded at each hop].

And no reply is stealth mode, or, the path does not exist, or, the path is broken.  Which is how every firewall fakes its stealth.

I believe your pix is not configured for tracert.  Barring that, that is to say, if it is configured properly, then Windows builtin firewall software and specific stealh permissions on ICMP, ping, and the handful of about ten control signals for DNS and routing, is blocking the command, even if on every single machine or on a single frontend server with the pix ahead of it, or not.

It's a simple tristate buffer scheme, on-off-indeterminant ::  enabled-disabled-stealthed

Port 1692 {a well known port}:
sstsys-lm       1692/tcp    sstsys-lm
sstsys-lm       1692/udp    sstsys-lm

[I can't believe people like info-techs-com posted everyone's email in their list of ports, but hey, who says you need a brain to be an infotech]  check IANA though, they do it properly, in text form.

[to prove just how useless google, dogpile, and all the others are, try a search using the basic scientific and educational method "definition sstsys-lm" or "sstsys-lm is defined as" or "sstsys-lm is an acronym that means" and you'll realise that this generation has no rules for definitions nor for the millions of acronyms; it just assumes everyone knows them; Bzzzzzzzz!  Wrong!

I had to do a define on wikipedia to figure out what this port was supposed to be, and, it turns out to be:

sstsys-lm - "Small Computer System Interface on Stream Protocl using Link Manager."

http://en.wikipedia.org/w/index.php?title=Sstsys-lm&action=submit

I have no idea whether or not that makes sense with your problem because the world has gotten absolutely ignorant on writing and how to use acronyms, the ebonics of the educated.

Ok sorry everyone
My question was perhaps vague or poorly constructed.  I did not ask if being unable to do tracert was "the problem".  I wanted to know why tracert did not work, but ping did.  I perhaps mistakenly thought that since they both use icmp they would be handled similarly by the PIX.
YES IT WAS THE PIX preventing the tracert!  This is not a surprise i am sure to most who answered.  I replaced the PIX with a linksys and was able to do tracert.
I am still wondering however why two things that use the same protocol are being treated differently.  I am new to PIX-very new and i am trying to get a handle on this ?#%z@*!! black box.   yeeeesh!
Anyway I'll try to sift through the barrage of responses and dole out points fairly-that's a monumental task in all by itself.
If any on can tell me exactly which part of the pix configuration is treating these icmp utilities differently, I would be appreciative-besides that it's probably academic.
Thank you all-Laura

Lukeca,
To my understanding tracert is a series of pings with a limited lifespan.  Even though the pix did not respond, wouldn't the next device down the path respond?

A tracert is basicaly a series of pings to each hop in a sequence to get to the end.  It appears that all hops in the chain to google from your system do not respond to pings (or one of them has an exceptionaly long delay) try tracert -w (milliseconds to wait) to give it more time to respond.  The fact that Google responded indicates that all firewalls and routers bettwen you and them pass tracert, even though they may not resopnd them self.

eb

Some "not true" 's:

"Your PIX is your gateway, so that is the first device the packet hits, because the PIX does not respond to pings, the tracert never makes it past the first device."  tracert pings everthing along the way, you said so yourself.  It does this by reading the the time to lives and limits the hops as well.  So, the first one goes out to one hop only, gets the gateway, increments the hops, and discovers if the next is the destination by the resolver.  If not, the process continues until it finds the queried name or IP, and if it hits a firewall, with no return, most tracert commands will state either firewall detected or go to the maximum 30 hops and end.

I gave the answer above; tracert is not ping, it uses a different port, sometimes a set of ports, one for ICMP, one for ping, and one for tracert or discover.

The pix probably did not have the proper port enabled, which is what a firewall does by default, stealths them, as in "no response."  The pix doesn't respond to pings only if configured that way.  Cisco has lots of examples of how to configure their software and routers, check their site.

Laura, the best I can say is browse Cisco because they have so many configurations it's unlikely anyone will know all of them off the top of their head.

Do you know how to interrogate the pix to ask it which ports are blocked, open, stealthed?

P.S.:  do the same for this "We are using a T1 that goes to a cisco 2524 router," which we all seem to have overlooked.

Cisco software on that one.

Thanks GinEric,
No I do not yet now how to interrogate the pix for open ports or even understand fixups, but I intend to learn-trial by fire.  Ebers said “The fact that Google responded indicates that all firewalls and routers between you and them pass tracert, even though they may not respond them self.", but I agree that something is not quite right with that logic since when I replace the PIX with the linksys, I do get several tracert responses from devices along the path.  It seems that the routers are responding, but for some reason the PIX is dropping the packets.  It is definitely the PIX preventing tracert responses and GinEric is probably right that it has to do with port assignments since they both use icmp.  I am able to telnet into the router and PIX, and I did have to reset the password on both devices by tftp so that's a start, but when I look at the Cisco's website data available it's daunting to say the least.  I did a show config on both devices, and now have some small insight into what they are doing.  I had to reconfigure the router from scratch however when I screwed up resetting the password, so besides the inside and outside IP, most everything else on the router 2524 is default settings.  I am waiting on some Cisco router books, because sorting through the Cisco website is tough.  I now have a book on ios in a nutshell, but which ios commands apply to which version is still unclear.  I can't even figure out if that 2524 can do NAT!  It's a simple question, but can not find the answer.  I do know that our smtp outgoing from the mail server seems to be getting dropped, but incoming mail is fine.  I think it has to do with the fixups, but what do I know???  We are also having intermittent page can't be displayed type issues, but the DNS seems ok.  All help is appreciated and thank you to all who are putting there 2 cents, since this discussion has been helpful.  I'm also looking in to the software recommended by Ebjers and GinEric.

GinEric,

  ejbers has it right. ICMP doesn't use any *PORTS*. Only those protocols who maintains a session needs ports and ICMP doesn't fit in there. It only uses 'type' and 'code', every tcp/ip stack knows this and that is why it works.

Two things.

1. Ping packet doesn't leave firewall, that is not correct. By default all the packets going out from in through PIX firewall is allowed (May it be icmp or tcp). So what the tracert output basically means is that all the networking devices across the path to google definitely understands the request but they are 'configured' not to reply back but then it allows it to go through. Otherwise, he wouldn't have gotten a reply back from google.

2. Again, there is NO port involved in ICMP. It doesn't use it. So as for the author there is nothing to worry about, almost everybody has the same scenario. Look at my tracert sample;

C:\Documents and Settings\Rajesh T Sivanandan>tracert www.google.com

Tracing route to www.l.google.com [66.102.9.147]
over a maximum of 30 hops:

  1     1 ms     2 ms     1 ms  192.168.0.1
  2    19 ms     2 ms     2 ms  202.142.67.1
  3     4 ms     3 ms     3 ms  202.142.94.1
  4    14 ms     3 ms     4 ms  202.142.88.1.zeeaccess.com [202.142.88.1]
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7     *        *        *     Request timed out.
  8     *        *        *     Request timed out.
  9     *        *        *     Request timed out.
 10     *        *        *     Request timed out.
 11     *        *        *     Request timed out.
 12     *        *        *     Request timed out.
 13     *        *        *     Request timed out.
 14     *        *        *     Request timed out.
 15     *        *        *     Request timed out.
 16     *        *        *     Request timed out.
 17     *        *        *     Request timed out.
 18     *        *        *     Request timed out.
 19     *        *        *     Request timed out.
 20     *        *        *     Request timed out.
 21     *        *        *     Request timed out.
 22     *        *        *     Request timed out.
 23     *        *        *     Request timed out.
 24     *        *        *     Request timed out.
 25     *        *        *     Request timed out.
 26     *        *        *     Request timed out.
 27     *        *        *     Request timed out.
 28     *        *        *     Request timed out.
 29     *        *        *     Request timed out.
 30     *        *        *     Request timed out.

Look at it, I don't get a reply back at all! Does it mean I can't reach google ? wrong, I can. This is because my firewall doesn't entertain any kind of ICMP reply messages because I configured it so.



Also some when you replace the firewall with router, you said you get some replies, can you post that? There are different types of ICMP replies which can be blocked or allowed. But by default echo-req going out through the firewall is enabled and for that request, the reply will come to you.

if you want to allow everything on icmp just do this => icmp permit any any

Sorry rsivanandan ,
I can not post the results of the tracert while using the linksys instead of the PIX because I am not at the office, and I do not precisely recall all responses, but there were at lease ten devices reporting back.  But rsivanandan, I am not pushing the issue because I am "worried"-I am just trying to gain some deeper understanding of why similar seeming protocols are handled differently.  You have to admit that there are some inconsistencies in explanations to the question posed.  My goal is not to permit all icmp to come into my firewall, but to understand why Google’s response comes back through my firewall, but no other router's responses make it through.

rsivanandan,
If it helps I am using a windows machine to do the tracert.

rsivanandan,
Also I did not use any switches just tracert www.google.com

rsivanandan,
You mentioned checking bandwidth.  What is the best way to accomplish this?  I have already tried dslreports, but how do I know what this circuit does under a real load?  It doesn't seem as though simple ping doctor type tools are adequate.
Any ideas?
laura

Laura,

  If you want to learn more about the behaviour, I suggest reading some good 'generic' tcp/ip books.

Like regarding the bandwidth, I already mentioned I believe. Go to the router to which the T1 is connected and take the output of 'show interface' and post it here.

Cheers,
Rajesh

 

Rajesh,
i will post as soon as i have access to their network, probably a day or two- thank you

Rajesh,
Thanks for the suggestion if I find the reason why the Pix blocks the tracert icmp but not the ping I will try to post so that you can learn the reason also.
Thank you

One other thing I found:  Start | Control Panel | Windows Firewall | Advanced

each and every Settings button, has a place for allowing all the basic DNS commands, from Allow Incoming Echo Request to Allow Outgoing Packet Too Big

I just turned them all on, thinking "what's the point in stealthing DNS???" before this, however, numerous things such as ping and tracert did not work even thought the Windows Firewall is turned off here.

It seemed to pre-empt other firewalls from working even when Windwos Firewall was turned off.

Oh, boy, do I know Cisco documentation is daunting!  Probably some dumb setting in the pix too, like one of the stealth settings, as shown in Windows Firewall above; you may have to set it to enable on both Server and Pix.

I got my tcp/ip books from Author Vent Cerf, who seems to have authored and be in charge of most routing for tcp/ip, probably a really good start.

Good luck Laura

I'll check it out GinEric.  I'm in cisco pix boot camp hell because I'm under  the gun.  I'm going to try turning off some of the fixups for testing.  I believe that most of the people in here are right in that the tracert issue is not the problem, but it's still a mystery to me how the pix decides what to do and when.  I understand that icmp is connectionless and as to why the pix allows some icmp and not others is wierd.  I am questioning whether the firewall is even functioning correctly.  Our general seemingly unrelated network problems started about two weeks ago, with quite a few page can't be displayed issues that seem like dns, and now no smtp going to the internet.  Mail comes to the server and gets distributed to all the local computers and mail can be sent from inside to inside address, and inside ping times are good.  Also tracert works fine from one local computer to another.  When I replaced the pix with a linksys, I was hoping to get some insight into the problems, but the linksys performed worst than the pix even though I had the mail/web server in a dmz.  I had outside connectivity with the linksys router, but very slow.  I did end up resetting the cisco router in an attempt to reset the password about a week ago and now problems are worse.  i'm not sure if i've configured it correctly.  The only things that I configured are the inside ip address, outside ip address and where to route packets not within our LAN.  Anyway-I'll keep at it.

The solution was adding conduits to the firewall.
http://www.cisco.com/warp/public/110/pixtrace.html
and I issued the following comands to solve the problem:
conduit permit icmp host 99.99.99.99 any unreachable
conduit permit icmp host 99.99.99.99 any time-exceeded
conduit permit icmp host 99.99.99.99 any echo-reply
rsivanandan, I thougt you might like to know the reason, if it ever comes up again.

Hello friend,

 This is not new. If you check out the post Date: 06/11/2006 01:09AM PDT, I had mentioned it there. You aren't getting the root of the answer, but we've tried our best.

By the way, 'Conduit's are outdated and is removed from 7.0, so move onto access-lists.

Cheers,
Rajesh

lizardqueen007 I love it, the fact that you gave the cause and that you found it.  And the ensuing problems you had, resetting the password for the other router and stuff, is exactly why we replaced the entire frontend here with a U.S. Robotics Switch, an 8 port that just grabs whatever IP Address we give the computer cabled to it, and allowed ourselves the luxury of troubleshooting one server [or firewall, router, etc..] at a time, all the while keeping all other computers and servers online and working.

It had been suggested we buy some $2,500.00 Cisco router; I wasn't ready for that nightmare of putting all the eggs [servers and connections] in one basket, so I did some long research and finally bought the $47.00 8 Port Switch and now any router or firewall can do whateve it wants and it ain't gonna bring this network to a halt!

I figured it was the pix, and its configuration, only because tracert does use differnet ports and it was most likely that these ports were stealthed by default, either in the pix or in the Operating System, which in your case seems to be Windows.

I also dumped the ISP as Start of Authority for the various domains here and asked a friend what he would charge to be my registry name servers [another problem was I couldn't change the ISP's name server records] and it worked out nicely.  I changed the records myself, at our Registrar, then created the DNS records at DollarDNS.net and instantly the domains came up without a problem, even the various mail servers.  I could then ping and tracert them and all was well.  Well, after fixing a Windows problem with the required nVidia drivers.  The routers now can do their job and do it alone.  The firewalls can now do their job.  And everybody is independent of everybody else, which means, no single device can block the entire network from now on.

That Cisco has some pretty specific programming, even stateful packet inspection [just another headache in actuality, and will pretty much guarantee that some packets will get lost, be lost, or be blocked, even ones you don't want this done to].

I think you got to the root of the problem; pix was blocking packets by default.  By adding conduits, you turned it into a switch, even if they are "derecated."

What's an access-list, except "turn the firewall into a pass through switch."

Six of one, half a dozen of the other; anyway, thanks for the info Laura.