1

My goal is to check weather the destination port (MySQL 3306) is able to connect.

First, I tried with telnet but it showed No route to host

$ telnet dest.com 3306
Trying <dest_ip>...
telnet: Unable to connect to remote host: No route to host

However, it can be connected with port 80.

$ telnet dest.com 80
Trying <dest_ip>...
Connected to dest.com.
Escape character is '^]'.

So, I tried with normal traceroute and the destination is not reachable.

$ traceroute dest.com
traceroute to dest.com (<dest_ip>), 30 hops max, 60 byte packets
1 172.16.101.1 (172.16.101.1) 0.283 ms 0.553 ms 0.345 ms
2 * * *
3 * * *
...

However, when I tried with traceroute -T -p, the destination is appeared to be reachable.

$ traceroute -T -p 3306 dest.com
traceroute to dest.com (<dest_ip>), 30 hops max, 60 byte packets
1 172.16.101.1 (172.16.101.1) 0.270 ms 0.374 ms 0.468 ms
2 <public_ip> (<public_ip>) ....
3 <public_ip2> (<pubice_ip2>) ...
4 ...
5 <dest_ip> (dest_ip) 4.144 ms !X 4.217 ms !X 3.996 !X

And, when I tried with other port, the route is different (just one hop away).

$ traceroute -T -p 80 dest.com
traceroute to dest.com (<dest_ip>), 30 hops max, 60 byte packets
1 172.16.101.1 (172.16.101.1) 0.327 ms 0.438 ms 0.568 ms
2 <dest_ip> (dest_ip) 0.711 ms 0.865 ms 0.974 ms

So, I wonder how traceroute -T -p work and what are the reasons of the results in each step?

3 Answers 3

4

Your results indicate changing routing. This has nothing to do with how traceroute operates. Please rerun your tests, and rerun them a second time if routing appears different. The no route to host, may be a firewall blocking port 3306.

traceroute -T attempts to open a TCP connection using increasing TTLs. This should in most cases bypass the firewalls if you are connecting to a permitted port. The mechanism is described in the man traceoute output.

Your first output is normal output when your firewall is in a mostly closed configuration. Unless there is a rule permitting it, the normal UDP traceroute will fail.

Your second request shows a longer path. Depending on your firewall configuration, this may be the normal routing. Or it may be that a shorter path had not yet been discovered. The routing has nothing to do with traceroute. The !X annotation after each time indicates that communication is adminstratively prohibited. The ae nnotations are also included in the man page for traceroute.

The third request uses a shorted path. This may be a hairpin NAT configuration on the firewall. Or it may be that a shorter path has been discovered. The TCP server appears to be responding.

A few notes:

  • telnet is an effective tool for the test you are running. I often prefix the command with echo | so that the connection is closed immediately.
  • The initial failure indicates that you don't have a route to the server. In this case, the test won't tell you anything useful about connectivity at the server.
  • When running tests like this it can be helpful to retry if you get inconsistent results. In this case, you had different routing. Normally, the path should have been known or discovered on the first request.
  • netstat -ant | grep 3306 on the server will tell if MySQL is listening on a reachable port. Neither 127.0.0.1 nor ::1 are reachable from outside the server.
2
  • Often on machines (say redhat or fedora), there are default firewall rules that have a rule at the end that says to reject-with icmp-host-prohibited for any traffic that doesn't match previous accept rules. The No route to host message is what I get when I try to connect to a port that isn't explicitly opened in iptables.
    – lsd
    Jul 25, 2016 at 11:40
  • @lsd55 I believe it is a firewall rule. I posted before I completed the answer. The different routing for mysql and http does concern me.
    – BillThor
    Jul 25, 2016 at 11:43
1

Your output from traceroute dest.com shows 100% packet loss from the second hop forward. The most likely explanation for that would be a badly configured firewall on your end of the connection. It might be dropping outgoing UDP packets.

Your output from telnet dest.com 3306 and traceroute -T -p 3306 dest.com are consistent. The !X from traceroute means no route to host, just like telnet told you. However the messages about no route to host are originated from the IP address you are trying to reach. That means either that IP is lying to you, or some sort of NAT is happening at the other end causing the real IP address to be hidden from you.

The output from traceroute -T -p 80 dest.com shows a much shorter route. That looks like something on your end of the connection is hijacking traffic destined for port 80.

Since the symptoms indicate something fishy going on at each end of the connection, there are potentially two separate issues, and you should debug those separately. To aid in debugging the issues separately, it will be useful for you to have access to a third host with an internet connection with no funny business going on. That means no NAT and no firewall on the third host used for your debugging.

0

This is not an answer to your question, but might solve your actual problem.

You need to make sure that MySQL listens to the actual internet facing interface in addition to the localhost interface?

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .