traceroute and ping from school network

Question

I have a server in my school. If I do a traceroute command for some host within our school network, I am able to reach the host. So for example,

traceroute hostname.xxx.edu

traceroute to hostname.xxx.edu (xxx.xxx.xx.xx), 30 hops max, 40 byte packets
 1  reserved-xxx-2.xxx.edu (xxx.xxx.xxx.x)  0.858 ms  0.924 ms  0.980 ms
 2  hostname.xxx.edu (xxx.xxx.xx.xx)  0.446 ms !X  0.438 ms !X  0.423 ms !X

Similarly, ping hostname.xxx.edu also works successfully.

However, if I try,

traceroute to www.google.com (64.233.160.99), 30 hops max, 40 byte packets
 1  reserved-xxx-2.xxx.edu (xxx.xxx.xxx.x)  34.605 ms  34.658 ms  34.711 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  *

So, when I tried ping www.google.com, it failed as expected.

QUESTIONS

So as per my understanding, the firewall of my school network is blocking my server from contacting the outside world. Is this correct?

However, if I do command like curl www.google.com I get the perfect output. In fact, I had extracted so much information from websites using my shell script in this server. How did the shell script work if the firewall is blocking the outside world from accessing my server?

Answer 1

Yes it's entirely possible that your firewall is blocking the traceroute from being successful. To understand why this is failing it's best to consult the traceroute man page.

excerpt

This program attempts to trace the route an IP packet would follow to some internet host by launching probe packets with a small ttl (time to live) then listening for an ICMP "time exceeded" reply from a gateway.

We start our probes with a ttl of one and increase by one until we get an ICMP "port unreachable" (or TCP reset), which means we got to the "host", or hit a max (which defaults to 30 hops).

Three probes (by default) are sent at each ttl setting and a line is printed showing the ttl, address of the gateway and round trip time of each probe. The address can be followed by additional information when requested. If the probe answers come from different gateways, the address of each responding system will be printed. If there is no response within a 5.0 seconds (default), an "*" (asterisk) is printed for that probe.

So the asterisks you're seeing are servers that you're packets are being routed through whom are timing out (5.0+ seconds) and so traceroute defaults to printing the *.

The other thing that will tank traceroute from working, is when a server/router along the way is configured to not reply to ICMP (aka. ping) packets. Without replying to pings, `traceroute's trick of inducing each server by incrementing the TTL (Time To Live) for each packet that it sends to the actual destination, will fail.

NOTE: There's even a warning about this in the traceroute man page.

excerpt

In the modern network environment the traditional traceroute methods can not be always applicable, because of widespread use of firewalls. Such firewalls filter the "unlikely" UDP ports, or even ICMP echoes. To solve this, some additional tracerouting methods are implemented (including tcp), see LIST OF AVAILABLE METHODS below. Such methods try to use particular protocol and source/destination port, in order to bypass firewalls (to be seen by firewalls just as a start of allowed type of a network session).

So depending on how you configure traceroute it may be using ICMP, UDP, or even TCP packets to elicit a response from the various systems that are handing the routing of your packets from point A to point B.

Again consulting the traceroute man page take note of these 3 options:

   -I, --icmp
          Use ICMP ECHO for probes

   -T, --tcp
          Use TCP SYN for probes

   -U, --udp
          Use UDP to particular destination port for tracerouting (instead 
          of increasing the port per each probe). Default port is 53 (dns).

There are of course more, see the LIST OF AVAILABLE METHODS for the full list.

So what about curl?

As is often the case with border firewalls such as at a business or university, only traffic targeting ports 80 (HTTP) and 443 (HTTPS) are allowed to egress. It's entirely likely that the ICMP ECHO_REQUEST packets are being dropped by the universities firewall, which would explain why you're getting the asterisks once you start hitting servers outside the universities' network.

With the egressing of packets over port 80 you can take advantage of this and tell traceroute to use TCP over a particular port, 80 in this case, to get what you want.

Example

$ sudo traceroute -T -p 80 www.google.com
traceroute to www.google.com (173.194.46.81), 30 hops max, 60 byte packets
 1  byers.bubba.net (192.168.1.6)  3.265 ms  3.236 ms  3.213 ms
 2  * * *
 3  24.93.10.17 (24.93.10.17)  21.359 ms  35.414 ms  48.045 ms
 4  rdc-72-230-153-79.wny.east.twcable.com (72.230.153.79)  48.064 ms  48.044 ms  54.523 ms
 5  rdc-72-230-153-243.wny.east.twcable.com (72.230.153.243)  70.067 ms  70.013 ms  73.312 ms
 6  be35.cr0.chi10.tbone.rr.com (107.14.19.104)  73.201 ms be45.cr0.chi10.tbone.rr.com (107.14.19.106)  62.289 ms be35.cr0.chi10.tbone.rr.com (107.14.19.104)  65.485 ms
 7  ae0.pr1.chi10.tbone.rr.com (107.14.17.192)  62.056 ms  48.685 ms ae1.pr1.chi10.tbone.rr.com (107.14.17.194)  32.193 ms
 8  * * *
 9  209.85.254.130 (209.85.254.130)  42.624 ms  45.159 ms  42.777 ms
10  * * *
11  ord08s11-in-f17.1e100.net (173.194.46.81)  48.036 ms  42.543 ms  44.751 ms

Answer 2

So as per my understanding, the firewall of my school network is blocking my server from contacting the outside world. Is this correct?

No, I guess it can block almost all traffic but allow at least TCP port 80. traceroute in Linux default use UDP, ping use ICMP, so as your output, it seems that those traffic have been blocked by the firewall.

How did the shell script work if the firewall is blocking the outside world from accessing my server?

As above, when you can get result from curl www.gooogle.com, I am sure that the firewall allows at least TCP port 80 and UDP port 53(for DNS work). You can do a simple check, for asserting this, by using traceroute but using TCP:

traceroute -T -p 80 www.google.com

Here is my result:

$ sudo traceroute -T -p 80 www.google.com
[sudo] password for cuonglm: 
traceroute to www.google.com (74.125.128.103), 30 hops max, 60 byte packets
 1  172.16.50.253 (172.16.50.253)  0.133 ms  0.133 ms *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  XXX.XXX (Y.Y.Y.Y)  13.954 ms XXX.XXX (Y.Y.Y.Y)  14.198 ms X.X.X.X (123.29.10.110)  14.140 ms
 9  unknown.telstraglobal.net (134.159.208.165)  85.353 ms  85.349 ms  85.338 ms
10  i-0-2-0-3.hkth-core01.bi.telstraglobal.net (202.84.153.234)  85.780 ms  85.765 ms  85.748 ms
11  i-0-0-0-3.hkth12.bi.telstraglobal.net (202.84.153.182)  85.723 ms i-0-0-0-1.hkth12.bi.telstraglobal.net (202.84.153.150)  86.731 ms i-0-0-0-2.hkth12.bi.telstraglobal.net (202.84.153.178)  85.305 ms
12  72.14.221.126 (72.14.221.126)  51.635 ms  51.535 ms  51.177 ms
13  209.85.241.58 (209.85.241.58)  51.137 ms  51.372 ms  51.086 ms
14  209.85.253.71 (209.85.253.71)  51.601 ms 209.85.253.69 (209.85.253.69)  52.172 ms  51.888 ms
15  * * *
16  hg-in-f103.1e100.net (74.125.128.103)  51.639 ms  52.632 ms  51.670 ms

A lesson to learn

When making rules for firewall (or similar security devices), the golden rule is "Deny all, allow specifics"

Answer 3

Your school firewall is probably blocking most traffic outbound on ports other than TCP/80 which is the default IP port for web traffic.

In particular ping and (most of the time) traceroute send the ICMP ECHO_REQUEST packet and many companies and schools block all ICMP traffic through their firewalls as it can be used to find out information of the network devices behind the firewall.