3 tools for troubleshooting packet filtering

Nmap, Wireshark, and tcpdump are helpful tools for troubleshooting your network. This article shows you how to use them with a real-world example, because when you're trying to learn a new technology or technique, sometimes the best way is to walk through a scenario.

Trouble begins

In this scenario, a business analyst had administrative privileges on all network devices (routers, switches, servers, and clients). Unfortunately, this individual did not have a solid understanding of these devices or their services, such as firewalls and packet filters, logs, or routing. In my role, I inherited this environment and was told to accept the fact that non-administrators had administrative privileges.

A client device sat on one internal segment, and a database server resided on another. A router with strict packet filtering rules sat between the two segments. The rules were ad hoc and not in a terribly logical order, and the relevant application communicated between the client and server using non-standard ports. I was the only administrator in the company, and as luck would have it, I'd taken the day off.

The analyst decided there was a problem with the router's filter and began making changes. The analyst did not back up the original filter configuration and kept no record of the changes. The analyst made multiple changes until they became frustrated and sent me an email saying, "I don't know what is wrong. I don't know what I did. Now it doesn't work. Fix it!"

This troubleshooting opportunity arose from a real situation I faced as an administrator. Many mistakes were made that allowed this failure to occur in the first place.

Choose your tools

I could have taken several approaches to re-establish connectivity. I decided to use Nmap, Wireshark, and tcpdump to help identify what changes needed to be made to the filter. The general idea was to determine the ports the application expects to use and compare them against the ports the router permits through the interface.

You can use the following steps if you find yourself in the same situation.

1. Scan the router

One logical troubleshooting step is to identify the available connections. Begin by scanning both sides of the router to document the open ports. Nmap is an excellent tool for this job.

Run the scan from each segment against the interface in the router connected to that segment. Save the scan results, then compare the configuration of the filter against the scan results. If the two interfaces have the addresses 192.168.1.1 and 192.168.2.1, the commands are:

$ sudo nmap 192.168.1.1
$ sudo nmap 192.168.2.1

There may be more than just two interfaces in the router, so conduct any additional scans necessary to ensure the filters are not blocking (or permitting) the wrong traffic. This is a great opportunity to understand exactly how the router is configured. Use the -oN option to cause Nmap to write the results to a file.

You'll get a list of ports for each interface on the router. Next, find out what ports the application expects to see open. The idea is to compare what ports the application wants to use against what ports it is allowed to use on the router.

2. Intercept communications

Another way to find out what destination ports the application expects to see is by capturing network traffic in each segment. The capture on the client side of the router displays packets addressed to the remote server's IP address. Recall, however, that a port number also gets exposed in the packet sniffer's output. That's the data you're trying to collect.

Use either tcpdump or Wireshark to accomplish this. The following sections document both tools.

Using tcpdump

You can use tcpdump to intercept traffic originating from the client computer and destined for the remote server at 192.168.2.100. The packet header displays the destination port and shows what IP address and port number the traffic needs to use. This can be compared against the existing filter rules as seen on the device and through a Nmap scan. Remember, this capture occurs on the client segment.

$ tcpdump dst 192.168.2.100

The capture displays where the traffic is trying to go. But how can tcpdump display whether the traffic is getting through the router and doing so on the correct interface?

[ Download the checklist Considerations for implementing DevSecOps practices. ]

Use tcpdump on the server side of the router to capture traffic addressed to the server. Ideally, the captures on each side of the router should be the same; what's sent from one side should be passed through to the other side. Of course, the problem to resolve is that this is failing to happen. The capture on the server side displays what traffic is getting through—and you already know that the proper traffic is not arriving. Comparing what's sent on one side against what's received on the other side narrows down what traffic is filtered and therefore identifies the rules to edit.

Use the same capture (destination IP) on this side of the router:

$ tcpdump dst 192.168.2.100

Output the tcpdump results to files by using the -w {filename} command. Read the .pcap files tcpdump produces by using the -r option with tcpdump or Wireshark.

Using Wireshark

You can use Wireshark instead of tcpdump, if you want. Either tool can handle the job, and sometimes Wireshark is a little easier to work with. The process is the same.

First, capture traffic on the client side of the router. Next, capture traffic on the server side. Use a display filter in Wireshark to view the packets with the server's IP address as the destination (This process basically duplicates the steps from the tcpdump example, just with a different tool.)

Compare the two captures. The port numbers embedded in the client computer's packets are of particular interest. These port numbers indicate the ports the client expects to communicate on. In theory, the server side should show the same packets, but again, that's exactly the failure you're managing.

3. Check the router's firewall settings

Another way of confirming traffic flow is by specifically checking the ports from outside the router. Nmap to the rescue, again! The -sA option displays the port status of the destination machine.

The Nmap syntax for checking firewall status is fairly straightforward:

$ nmap -sA 192.168.2.100

Feel free to redirect the output to a file.

Here are the more common states reported by Nmap:

• Open: Port accepts inbound connections
• Closed: No application is listening on the port
• Filtered: Packet filtering prevents Nmap from determining whether a service is listening
• Unfiltered: Port is accessible but Nmap cannot determine port information

Preventing a recurrence

After troubleshooting the problem, we endeavored to prevent a recurrence by making it clear to the analyst that only the network administrator is allowed to make configuration changes. I also changed the administrative password on the network devices to something only I knew.

Using a packet sniffer to see what traffic gets sent from a source computer and comparing the output to the traffic captured on the other side of the router helps narrow packet filtering configuration issues, allowing you to correct or update rules as necessary. A port scan provides a second way of seeing what the router's configuration looks like from the network segments, which is useful for doing a comparison against the filters' current configuration and the expected configuration.