ARP is used by IP to resolve the destination MAC address out of the IP address of the device that we wish to communicate with. When we send packets to a destination, the first packet is the ARP request to find the MAC address of the destination. We get it from the destination and then send the other packets destined to it.
Tip
ARP operation is only local, that means the ARP request, which is a broadcast, will be sent only on the LAN. In case you send a packet to a device on your IP network (with the same IP network and mask), ARP will try to find its address. When you send a packet to someone out of your network, ARP will be sent to find out the default gateway MAC address.
We will use three methods to find the basic connectivity problems:
- The standard command line (In MS-Windows go to Start and in the command window type
run. In Linux use any available Shell) - Wireshark
- Connecting to a LAN switch or router directly and getting information from there
Tip
To connect to the communication devices (routers, switches, and so on), you first connect with a console cable (in Cisco, this is the light-blue flat cable); you configure the device with an IP address, and then you can access the device via Telnet, HTTP, or SNMP software. With all of these methods you can read the device counters that provide you with information of the traffic, errors, CPU utilization, and more.
In each one of the following recipes, we will see exactly what to use and where.
In this recipe, we will see several connectivity issues and how to deal with them. Let's look at the very simple network in the following figure. Here, we can see a typical network and discuss some of the connectivity problems that can happen on it.
In the network, we can see two PCs, PC1 and PC2, that are connected to switch ports 16 and 20 respectively, a server connected to switch port 24, a router that connects us to the remote offices on switch port 3, and a firewall that connects us to the Internet on switch port 5. Our laptop with Wireshark installed on it is connected to port 2.
Let's see some of the problems that might occur here and how to solve them.
Let's consider case 1 when there is no connectivity from the PCs to the server:
- Ping the server from PC1 and PC2.
- If there is no answer, type
ARP –aon the command line. In the ARP table, you should see the IP address of the server and its MAC address. - If you see the MAC address of the server, probably there is a firewall running on the server that blocks ICMP requests. For the test, disable the firewall and test again.
- If you have pinged, but your application still doesn't work, go to Chapter 9, UDP/TCP Analysis, and continue from there.
You've gone through steps 1 to 3 in case 1, and still don't get a ping response (you get request time out).
- Connect to the LAN switch and get the list of MAC addresses that the switch has learned.
- If you don't see the addresses of your PC and the server, check for physical problems such as bad cable, adapter problem, and switch port problem. For doing so, you can simply switch cables or replace the switch for the test, replace ports on the switch and so on.
Now let's see how to use Wireshark to resolve this problem.
- When clients complain about connectivity problems to a specific device (server, printer, and so on), you connect Wireshark to the port (with port mirror), and you see many ARP requests and no answer. You can see an example of this in the following screenshot:
- In this example, we see that both 172.30.116.100 and 172.30.116.253 are looking for the MAC address of 172.30.116.254, but there is no reply.
- In this case, check in the switch if the MAC address has been learned, and if not, check for physical problems.
One of the types of a Man-in-the-Middle attack is when an attacker poisons the ARP cache of the devices that he wants to listen to with the MAC address of his Ethernet NIC. Once the ARP cache has been successfully poisoned, each of the victim devices sends all their packets to the attacker while communicating with the other device. The attacker, of course, will resend it to them after reading the data.
This is called Man-in-the-Middle attack since it puts the attacker in the middle of the communication path between the two victim devices. It is also called ARP Poisoning since the attacker actually poisons the victim's ARP cache with wrong information.
In the following figure, we see an example of a Man-in-the-Middle attack:
The following screenshot shows Wireshark:
A gratuitous ARP takes place when a device wants to verify if some other device has its own IP address. In this case, you will see an ARP with the same source and destination address fields. There is nothing wrong with gratuitous ARPs. There are devices that work this way; for example, home routers that scan for attached devices.
ARP sweep is used when, for some reason, we see a device that scans the network with ARPs, requests, or response in order to get information or attack the network.
While watching an ARP sweep, just check for the following:
- Is it requests or replies, and who is the sender?
- How many ARPs (per second)?
ARP requests and replies are a part of the regular network operation. Here are some rules of thumb to make sure they are actually so:
- Requests from different sources—no problem, this is how a network works (as long as there are not too many of them!)
- Many requests from a singles device—look at the source address and verify who is the device actually sending the requests to:
- It can be a management system that auto-discovers the network
- It can be a router that scans to see who is on the local network (see the previous screenshot)
- If you don't identify the source, it might be a problem, like a worm or ARP poisoning. Get into the details!
- If you see replies that are not to specific requests, it might be a problem. Get intothe details!
An ARP is sent when a device wishes to send data to a destination for the first time (see the How it works... section). It is difficult to estimate the exact number of ARPs per minute on a network, but this thumb rule gives you a general idea.
- Around 1-2 ARPs per device per minute is ok. If, for example, you have 100 devices (PCs, servers, printers, and so on) on your network, up to 200 ARPs per minute or 2-3 ARPs per second are still ok.
- Even if you have more than this, for example, 5 and even 10 per second for the network mentioned earlier, it is not necessarily a problem; it will be a good idea to just look for a suspicious pattern.
Tip
The number of ARPs on the network depends on what the devices on the network actually do. If all devices are connecting only to a single device (for example, to a router that connects them to the world), you will see a small number of ARPs. However, if devices, for example, send periodic messages to all their neighbors, you will see many ARPs. Don't forget, God is in the details!
When we send a packet from our IP address to a destination IP address through the LAN, we send the data in an IP packet that is encapsulated in an Ethernet frame.
Let's say for example, we send a Ping (ICMP request) from 192.168.1.1 to 192.168.1.3 on the same LAN. To send the packet, we need the IP and the MAC addresses of the destination, but what we have is only its IP address. We know it because this is our destination.
In order to find out what is the MAC address of the destination, we simply send an ARP broadcast to the LAN, asking all devices attached to it: who has the IP address 192.168.1.3? If the destination station is alive, it sends an ARP response with the MAC address of the destination.
From this moment, the source station holds the data in a cache, the ARP Cache, and the next time it wants to transmit, the station transmits the data directly to the destination address.
The ARP Cache remains in the host buffer for the next several minutes (how many minutes depends on the operating system). The ARP entry is flushed a few minutes after the last packet is sent to the destination.
The ARP request will be a broadcast sent to the LAN, as you see in the following screenshot:
The ARP reply will be a packet sent from the destination that we looked for to the source with the required MAC address, as you see in the following screenshot:
Anything that doesn't look like the standard and is a known exception (for example, gratuitous ARP, ARP sweep by router) should be checked!
Here is a short example to understand the principle of ARP operation. In the following diagram, we see an interesting case: two devices attached to the same LAN with different subnets with a default gateway configured to their own IP address. The question is: will a Ping (or any communication) work between them?
Well, intuitively, you will say no because these are two devices on different subnets and therefore require a router between them. But let's look at what actually happens over the wire:
- 192.168.1.10 wants to send a packet to 192.168.2.20. Since the default gateway is configured to its own address, it thinks the destination is on the same LAN and sends an ARP request.
- Since we are on the same LAN as the destination, the destination receives the ARP request (because it is a broadcast) and answers to 192.168.1.10 with its MAC address.
- Now, the source has the MAC address of the destination. It sends the packet to it, and although not on the same IP subnet, the destination receives the packet.
Another important issue is Proxy ARP. While a proxy in communications is a device that performs an operation on behalf of someone else, Proxy ARP is the technique in which one host, usually a router, answers the ARP requests intended for another machine.
The proxy ARP concept is implemented in various cases, for example:
- While placing a device in front of a router, for example, WAN acceleration/optimization device. When you configure this device in bridge (or transparent) mode, it will answer to the ARP requests intended for the router.
- Firewalls, web filters, and other devices that work in the transparent mode and are located in front of a server.
- In case of a software that requires an IP address in addition to the IP of the server it is installed on.