Ping Fails But Traceroute works?

By Tabish Khan on

Have you ever encountered a situation?  when you ping a device, it fails but when you traceroute to the same devices, it works.

At the end of the blog post, you will have a great understanding of why this happens.
In my previous blog post "But How Does Traceroute Works", I have explained in detail how does traceroute works. You can continue reading this blog post without reading my previous blog post but it will really help you out to read that blog post as well. Click But How Does Traceroute Works? to read my previous blog.

For the purpose of demonstration, I will use the following topology.

Figure 1

Throughout this blog post i will use the terms Source and Destination. Whereas 
Source = Kali-Linux ( having ip address 192.168.10.105)
Destination = Linux Server ( having ip address 192.168.30.105).


Case 1
Linux Server  can receive ICMP echo request packets and can respond with ICMP echo replies when it receives ICMP echo request packets.

ping -c 4 192.168.30.105
-c means number of echo request packets to  be sent.

Figure 2
Notice that ping is working.

traceroute -I 192.168.30.105  (Traceroute over ICMP)
-I means use ICMP 

Figure 2
Notice that traceroute is working.

Note: tracert 192.168.30.105 (Windows)  =  trecaroute -I 192.168.30.105 (Linux)

In my previous Blog, But How Does Traceroute Works? I have talked about  what are the different ways that you can use to implement traceroute?. Let me briefly discuss this here.
Traceroute can be implemented using ICMP, UDP, and TCP.
  1. Traceroute over ICMP
  2. Traceroute over UDP
  3. Traceroute over TCP
1) Traceroute over ICMP
 In this type of traceroute the following ICMP messages are used.
  •  ICMP echo request (type 8) messages
  •  ICMP echo reply (type 0) messages
  •  ICMP time exceeded (type 11) messages 
By default, Windows uses Traceroute over ICMP, and the command you will use is "tracert 198.168.30.105".
In Linux, if you want to use Traceroute over ICMP, you have to use the command "traceroute -I 192.168.30.105" whereas -I means to use ICMP.

Case2
Linux Server  can not receive ICMP echo request packets and can not respond with ICMP echo replies because it can not receive ICMP echo request packets.

To do so  let's block ICMP echo request  (Type 8) messages on our Linux server.

Figure 3

What this command does?
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP
  • INPUT: Iptablese uses the concept of Chains and rules. INPUT chain handles traffic that is created somewhere on the network and that is destined for the device itself. Let's say ICMP echo request packets that are generated by Kali-Linux and that are destined for Linux server.
  • -A: Append one or more rules to the end of the chain
  • -p:  The protocol of the rule or of the packet to check.  The specified protocol can be TCP, UDP, ICMP, etc.
  • --icmp-type: what ICMP message type do you want to specify.
  • -j: this specifies what to do if the packet matches the rule.
By doing so we will  prevent Linux Server from receiving the ICMP echo request packets that are sent by anyone. Mean if it can not receive ICMP echo request packets, it can not reply with an ICMP echo reply packet.

ping -c 4 192.168.30.105

Figure 4
Notice that Ping failed.

traceroute -m 5 -I 192.168.30.105
-m mean the maximum number of hops traceroute will probe & -I means use ICMP

Figure 5

Traceroute (traceroute over ICMP ) only made till R2. We never made it to the Linux server (192.168.30.105).
Why did this happen?
As we blocked ICMP echo requests on the Linux server, it can not receive any echo request message. In Both  Ping and traceroute over ICMP,  the source (kali-Linux) expects ICMP echo reply messages from the destination which is Linux Server in our case. But how can Linux Server sends ICMP echo reply messages if it can not receive ICMP echo request packets as it is blocked?. This is the reason this behaviour.

But let us try something else

traceroute 192.168.30.105 ( traceroute over UDP)

Figure 6

Boom how is it possible? that is where traceroute over UDP comes to the rescue. Let me briefly explain the traceroute over UDP for you.

2) Traceroute over UDP
In traceroute over UDP the folowing are used.
  • UDP packets
  • ICMP time exceeded message (Type 11)
  • Port unreachable (type 3, code 3) messages 
 In Traceroute over ICMP when the final destination (Linux Server) is reached, the source expects an ICMP echo reply but in Traceroute over UDP when the final destination (Linux Server) is reached source (Kali-Linux) expects port unreachable (type 3, code 3) message. Even we blocked ICMP echo request message but ICMP port unreachable ( Type 3, code 3) are not blocked that is why Traceroute over UDP worked.

Let us discuss one more option.

traceroute -T 192.168.30.105 ( traceroute over TCP)
-T means use TCP. 

Figure 7

SO we made it to the destination ( Linux server). But what is special here? This time its not traceroute over UDP but traceroute over TCP is used.
Note: By default, Linux uses traceroute over UDP.

3) Traceroute over TCP

In this type of traceroute the folowing packets are used.

  • TCP SYN packets
  • TCP SYN-ACK packets
  • TCP RST packets
  • ICMP time exceeded message (Type 11)  
In Traceroute over ICMP when the final destination (Linux Server) is reached, the source expects an ICMP echo reply but in Traceroute over TCP when the final destination (Linux Server) is reached source (Kali-Linux) expects TCP SYN-ACK and RST packets from the destination (Linux Server). Even though we blocked ICMP echo request message, still we traced the path to the destination (Linux Server). 

Case3
Linux Server  can not generate ICMP port unreachable ( Type 3, code 3) messages.

lets us block ICMP type 3 message on our Linux Server.

Figure 8

What does this command do?
iptables -A OUTPUT -p icmp --icmp-type 3 -j DROP
  • OUTPUT: Iptablese uses the concept of Chains and rules. OUTPUT chain handles traffic that is oroginated by the device itself and that is destined for any other device on the network. Let's say ICMP echo reply packets that are generated by the Linux server and that are destined for Kali-Linux.
  • -A: Append one or more rules to the end of the chain
  • -p:  The protocol of the rule or of the packet to check.  The specified protocol can be TCP, UDP, ICMP, etc.
  • --icmp-type: what ICMP message type do you want to specify.
  • -j: this specifies what to do if the packet matches the rule.
Ping -c 4 192.168.130.105

Figure 9
So ping faild. Due the very same reason of case2.

traceroute -I -m 5 192.168.30.105 

Figure 10

tracerout over ICMP could not made to the destination, reason is same as that of case2.

traceroute -m 5 192.168.30.105

Figure 11
Notice that in case2 traceroute over UDP was susseccesful but in this case we could not reach destination. Remember in traceroute over UDP, source expects port unreachable (Type 3, code 3) from destination but destination can not originiate port unreachable as it is blocked.

Here is something interesting.
traceroute -T 192.168.30.105

Figure 12

Isn't it great? Traceroute over  TCP is successfull and we tracerd complete path from source to destination despit we blocked ICMP echo request (case2) and port unreachable. And it makes sense, as in traceroute over TCP source does not exepcet ICMP echo reply or port unreachable from source rather it expects TCP SYN-ACK, and RST packets.

Okey, great. So far we talked about Source ( Kali-Linux) and destination (Linux-server) but what about Routers ( R1 and R2 in my case).

Case4
Configure R1 to deny time exceeded message (type 11).

ping -c 4 192.168.30.105


Notice that ping failed as ICMP echo requests are blocked on Linux server.
 
traceroute -I -m 5 192.168.30.105


Notice that unlike case3, we traced path only to R1. Because destination can not reply with ICMP echo reply packets.

traceroute -m 5 192.168.30.105


Unlike case3, we only traced path only to R1. Because destination can not send port unreachable message to source.

traceroute -T 192.168.30.105


So we reached the destination, but we did not know about R2. Because R1 denies time exceeded messages.

Case5
Delete Rules from Linux-Server.

Figure 13

 Notice that rules have been removed from INPUT and OUTPUT chains.

Ping -c 4 192.168.30.105


Ping is successfull. As destination can now respond with ICMP echo reply packets.

What abou traceroute?


Notice that in all cases (traceroute over ICMP, trcerute over UDP, and traceroute over TCP), we made to the destination. But we did not know about R2. The reason is same as explained in case2. If we allowed ICMP time exceeded on R1 ,we will know about R2 as well.

Conclusion

SO it is possible that ping fails but traceroute works. If the destination could not respond to the ICMP echo request packets, ping will fail and  you can not trace route (traceroute over ICMP) to the destination.But you can use traceroute over UDP to trace path to the destination given that destination was allowed to send port unreachable (type3, code3) message. If destination could not respond to ICMP echo request packets not it was allowed to send port unreachable message to the source, you can use traceroute over TCP to trace path to the destination.







Comments

Post a Comment

Popular posts from this blog

What are different SSH Authentication Methods?

By Tabish Khan on
Image
  Have you ever tried to set up an ssh connection to Linux machines? Have you ever wondered how many ssh authentication methods you can use to get remote access to a Linux machine?   At the end of the blog post, you will have a great understanding of what are some of the ssh authentication methods that you can use to get remote access to a Linux Machine. For the purpose of demonstration, I will use the following topology. I have three Linux machines. Ubuntu-Workstation having IP address = 10.0.0.249 Ubuntu-Server having IP address = 10.0.2.15 CentOS-Workstation having an IP address = 10.0.2.16 Our main objective will be to get ssh remote access to Ubuntu-Server and CentOS- workstation from Ubuntu -orkstation. I will discuss Three SSH Authentication Methods. Password-Based Authentication Key-Based Authentication  with Passphrase Key-Based Authentication  without Passphrase Before starting make sure that the OpenSSH server is installed on all of these machines. Ubun...
Read more

Ever wondered what is difference between SNMP and Syslog?

By Tabish Khan on
Image
SNMP is primarily a protocol for network management and monitoring. Using SNMP, admins can gather and manage information about network devices, track performance metrics, configure devices remotely, and receive notifications (traps) about specific events or conditions. There are two types of SNMP devices 1) SNMP Managed devices These are devices being managed using SNMP such as Routers, Switches, etc. 2) NMS (Network Management System/Status) These are devices/device managing the managed devices. This is an SNMP Server. For the purpose of demonstration, I will consider the following topology. Let's say, I want to get the system name, From the SNMP server, I am sending an SNMP GET message to the managed device to get its name. In the same you, you can send the SNMP SET message to change the system name. Notice that the Router name has been changed from R1 to R5 Syslog is primarily used for log management, troubleshooting, and security analysis. It enables admin...
Read more