The first problem scenario is rather simple: A user cannot access the Internet. We have verified that the user can access all of the internal resources of the network, including shares on other workstations and applications hosted on local servers.
The network architecture is fairly straightforward, as all clients and servers connect to a series of simple switches. Internet access is handled through a single router serving as the default gateway, and IP addressing information is
provided by DHCP. This is a very common scenario in small offices.
Tapping into the Wire
In order to determine the cause of the issue, we can have the user attempt to browse the Internet while our sniffer is listening on the wire. We use the information from “Sniffer Placement in Practice” on page 31 (see Figure 2-15) to determine the most appropriate method for placing our sniffer.
The switches on our network do not support port mirroring. We already have to interrupt the user in order to conduct our test, so we can assume that it is okay to take him offline once again. (That said, using a tap would be the most appropriate way to tap into the wire.) The resulting file is nowebaccess1.pcap.
Analysis
The traffic capture begins with an ARP request and reply, as shown in Figure 8-17. In packet 1, the user’s computer, with MAC address 00:25:b3:bf:91:ee and IP address 172.16.0.8, sends an ARP broadcast packet to all computers on the network segment in an attempt to find the MAC address associated with the IP address of its default gateway, 172.16.0.10.
Figure 8-17: ARP request and reply for the computer’s default gateway
A response is received in packet 2, and the user’s computer learns that 172.16.0.10 is at 00:24:81:a1:f6:79. Once this reply is received, the computer now has a route to a gateway that should be able to direct it to the Internet.
Following the ARP reply, the computer must attempt to resolve the DNS name of the website to an IP address using DNS in packet 3. As shown in Figure 8-18, the computer does this by sending a DNS query packet to its primary DNS server, 4.2.2.2 .
Figure 8-18: A DNS query sent to 4.2.2.2
Under normal circumstances, a DNS server would respond to a DNS query very quickly, but that’s not the case here. Rather than a response, we see the same DNS query sent a second time to a different destination address. As
shown in Figure 8-19, in packet 4, the second DNS query is sent to the secondary DNS server configured on the computer, which is 4.2.2.1.
Figure 8-19: A second DNS query sent to 4.2.2.1
Again, no reply is received from the DNS server, and the query is sent again one second later to 4.2.2.2. This process repeats itself, alternating the destination packets between the primary . and secondary . configured DNS
servers over the next several seconds, as shown in Figure 8-20. The entire process takes around 8 seconds ., which is how long it takes before the user’s Internet browser reports that a website is inaccessible.
Figure 8-20: DNS queries repeated until communication stops
Based on the packets we’ve seen, we can begin pinpointing the source of the problem. First, we see a successful ARP request to what we believe is the default gateway router for the network, so we know that device is online and communicating. We also know that the user’s computer is actually transmitting packets on the network, so we can assume there isn’t an issue with the protocol stack on the computer itself. The problem clearly begins to occur when the DNS request is made.
In the case of this network, DNS queries are resolved by an external server on the Internet (4.2.2.2 or 4.2.2.1). This means that in order for resolution to take place correctly, the router responsible for routing packets to the Internet must successfully forward the DNS queries to the server, and the server must respond. This all must happen before HTTP can be used to request the web page itself.
We know that no other users are having issues connecting to the Internet, which tells us that the network router and remote DNS server are probably not the source of the problem. The only thing remaining as the potential source of the problem is the user’s computer itself.
Upon deeper examination of the affected computer, we find that rather than receiving a DHCP-assigned address, the computer has manually assigned addressing information, and the default gateway address is actually set incorrectly.
The address set as the default gateway is not a router and cannot forward the DNS query packets outside the network.
Lessons Learned
The problem in this scenario resulted from a misconfigured client. While the problem itself turned out to be quite simple, it significantly impacted the user. Troubleshooting a simple misconfiguration like this one could take quite some time for someone lacking knowledge of the network or the ability to perform a quick packet analysis as we’ve done here. As you can see, packet analysis is not limited to large and complex problems.
Notice that because we didn’t enter the scenario knowing the IP address of the network’s gateway router, Unicorn didn’t identify the problem exactly, but it did tell us where to look, saving valuable time. Rather than examining the gateway router, contacting our ISP, or trying to find the resources to troubleshoot the remote DNS server, we were able to focus our troubleshooting efforts on the computer itself, which was, in fact, the source of the problem.
TIPS Had we been more familiar with this particular network’s IP addressing scheme, analysis could have been even faster. The problem could have been identified immediately once we noticed that the ARP request was sent to an IP address different from that of the gateway router. These simple misconfigurations are often the source of network
problems and can typically be resolved quickly with a bit of packet analysis.