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.
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.
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:
Use ICMP ECHO for probes
Use TCP SYN for probes
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.
$ sudo traceroute -T -p 80 www.google.com
traceroute to www.google.com (188.8.131.52), 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 184.108.40.206 (220.127.116.11) 21.359 ms 35.414 ms 48.045 ms
4 rdc-72-230-153-79.wny.east.twcable.com (18.104.22.168) 48.064 ms 48.044 ms 54.523 ms
5 rdc-72-230-153-243.wny.east.twcable.com (22.214.171.124) 70.067 ms 70.013 ms 73.312 ms
6 be35.cr0.chi10.tbone.rr.com (126.96.36.199) 73.201 ms be45.cr0.chi10.tbone.rr.com (188.8.131.52) 62.289 ms be35.cr0.chi10.tbone.rr.com (184.108.40.206) 65.485 ms
7 ae0.pr1.chi10.tbone.rr.com (220.127.116.11) 62.056 ms 48.685 ms ae1.pr1.chi10.tbone.rr.com (18.104.22.168) 32.193 ms
8 * * *
9 22.214.171.124 (126.96.36.199) 42.624 ms 45.159 ms 42.777 ms
10 * * *
11 ord08s11-in-f17.1e100.net (188.8.131.52) 48.036 ms 42.543 ms 44.751 ms