DougLubeyLouisiana
IS-IT--Management
Description: We have few people complaining that they could not get to our websites but could get to any other websites on the internet. Upon investigating, we realized that the trace route was being broken at the our router(To note: we have a firewall in between the router and the webserver).
Yes, the majority of our business and clients never reported problems, business was as usual, webhits and web transactions were as usual.
BACKGROUND investigation: I could do a tracert from my computer and many other computers around the country, not really a problem. But I found a website ( which had two implementations of tracert. One of the implemations worked and the other one did not(similar to the client problems). I also ran into some implementations on other websites which (tracert.com) produced similar results(some worked /some did not) but another problem I noticed cropped up; tracert return * *Icmp checksum is wrong as some nodes (This did not really have anything to do with my problem, but though I would mention it).
But since these clients were having the tracert (using windows xp client) broken at the firewall (both the router and firewall have public IP addresses). We decided to start troubleshooting with the tracert problem. As it turns out the trace route implementation can use a variety of protocols (reference: linux/unix and windows uses different styles). So at the firewall level (CISCO ASA 5505) which also performs the NAT (network address translations for the websites in IIS 6.0 / windows 2003 R2), I applied two more rules to those ip address on the outside route.
I allowed Outside traffic to:
outside
TCP>traceroute is now implemented (allowed through)
UDP>ports 33434 – 33534 are now implemented (allowed through)
ALL seem to be fixed????
Now: all the implementations from all websites and clients could tracert all the way to the websites.
AND GO FIGURE : The 2 internet explorer 6.x clients which were having problems performing ping, tracert and actually getting to the url via a browser could now do all 3.
NOTICE:
I Still do not really know why implementing UDP ports 33434 – 33534 corrected the problem for those clients, but it did. They can now get to all of our websites..
If anyone could provide the reasoning behind this solution, please do.
Thanks,
Doug Lubey of Louisiana
SEARCH ENGINE REFERENCE:
udp tracert could not get to our website
what does udp have to do with trace route
what does udp have to do with someone getting to our websites
clients could not get to our websites
some clients could not ping our website or get to it
would a virus protection software or spyware protection have something to do with a client using a combination of UDP and TCP http port 80 to get to our website.
Clients could not get to our website until we enabled some udp ports
tracert would *** out
tracert would stop working once it got to our firewall with * * *
tracrt website
* * * request timed out.
maximum of 30 hops
Yes, the majority of our business and clients never reported problems, business was as usual, webhits and web transactions were as usual.
BACKGROUND investigation: I could do a tracert from my computer and many other computers around the country, not really a problem. But I found a website ( which had two implementations of tracert. One of the implemations worked and the other one did not(similar to the client problems). I also ran into some implementations on other websites which (tracert.com) produced similar results(some worked /some did not) but another problem I noticed cropped up; tracert return * *Icmp checksum is wrong as some nodes (This did not really have anything to do with my problem, but though I would mention it).
But since these clients were having the tracert (using windows xp client) broken at the firewall (both the router and firewall have public IP addresses). We decided to start troubleshooting with the tracert problem. As it turns out the trace route implementation can use a variety of protocols (reference: linux/unix and windows uses different styles). So at the firewall level (CISCO ASA 5505) which also performs the NAT (network address translations for the websites in IIS 6.0 / windows 2003 R2), I applied two more rules to those ip address on the outside route.
I allowed Outside traffic to:
outside
TCP>traceroute is now implemented (allowed through)
UDP>ports 33434 – 33534 are now implemented (allowed through)
ALL seem to be fixed????
Now: all the implementations from all websites and clients could tracert all the way to the websites.
AND GO FIGURE : The 2 internet explorer 6.x clients which were having problems performing ping, tracert and actually getting to the url via a browser could now do all 3.
NOTICE:
I Still do not really know why implementing UDP ports 33434 – 33534 corrected the problem for those clients, but it did. They can now get to all of our websites..
If anyone could provide the reasoning behind this solution, please do.
Thanks,
Doug Lubey of Louisiana
SEARCH ENGINE REFERENCE:
udp tracert could not get to our website
what does udp have to do with trace route
what does udp have to do with someone getting to our websites
clients could not get to our websites
some clients could not ping our website or get to it
would a virus protection software or spyware protection have something to do with a client using a combination of UDP and TCP http port 80 to get to our website.
Clients could not get to our website until we enabled some udp ports
tracert would *** out
tracert would stop working once it got to our firewall with * * *
tracrt website
* * * request timed out.
maximum of 30 hops