I’m not even quite sure why they are called “captures”. No packets are held hostage or harmed in the process. Honestly, without the -w or -o option (tcpdump and fw monitor respectively) you are only watching the traffic, not even copying it to file! All joking aside, packet captures rock. I don’t plan on getting into troubleshooting network applications with them in this article, but rather using them to troubleshoot some basic networking issues from the firewall, such as NAT and routing.

The tools used for this are tcpdump and fw monitor. Both have strengths and weaknesses, but when used in conjunction, they are extremely valuable. I’ve touched base on these tools in a previous article or two, but in this 3 part series I wanted to get a little more in depth about when and where each is appropriate to use, how best to use them, and more importantly how to interpret the results to find answers.

TCPDUMP – An oldie but goody:

This tool can be found or installed on most Linux/UNIX operating systems, including Secure Platform (SPLAT). An example of this command, to see HTTP traffic to/from y.y.y.y, is: ‘tcpdump -n -i ethX host y.y.y.y and port 80’. The ‘-n’ argument tells the command to not resolve IPs to DNS names. DNS resolution greatly reduces the performance of the capture and may bring it to a grinding halt when IPs fail to resolve. I recommend always using -n, because you most likely already know which IPs are being dealt with, but if not then a simple ‘dig -x y.y.y.y’ from the command line will provide reverse resolution for you (where y.y.y.y is the IP in question). The argument ‘-i ethX’ is used to specify the interface (where ethX is the interface name) that you plan to listen to traffic on. This is an important option and I will cover more on it after explaining the remaining arguments. The ‘ host’ argument is used to provide an IP address to filter for. You may also use the ‘net’ argument in place of it to specify an entire network. Syntax for filtering on network n.n.n.n mask 255.255.255.0 would be: tcpdump -n -i ethX net n.n.n.n/24. You may also include a ‘not’ just before the word host or net to make tcpdump ignore traffic from that host or net. This can also be used for the ‘port’ argument to ignore traffic on certain ports. A few other useful arguments that can be used to filter, or filter out, are: udp, tcp, multicast, broadcast, and arp. You may also use multiple arguments in a single statement, by joining them with and or or.

In dealing with tcpdump on a firewall, you must really understand your network and choose the interface (-i ethX) wisely, or else you might completely miss the traffic that you are searching for. Generally on a firewall, a connection will traverse two interfaces, but there are a few things to consider as to when/why this might not always be the case. An internal user connects to a resource across a VPN tunnel. The internal user connects to the firewall via eth1 and the VPN tunnel crosses the Internet via eth0. Logically the traffic must traverse both of those interfaces to reach the final destination, but why doesn’t tcpdump show the connection on eth0? It does. However when you realize how it does, it then becomes clear that it is of no use to you to sniff on eth0 for this connection. As traffic enters eth1, it matches on a VPN community and becomes encrypted. Then it leaves eth0 as an IPSEC connection sourced (on the wire) as your firewall’s public IP address destined for the peer’s public IP address. As far as eth0 is concerned the traffic you are interested in seeing is completely hidden from your view. Another good example is when a NAT takes place. It is a similar pattern: Traffic enters eth1, a NAT is then applied to the source, and the traffic exits eth0 with a new source IP address. If you were still sniffing on eth0 looking for traffic from a host on your internal network, you simply won’t see it because the NAT changed that IP in the header. The connection is there, but just not as you might be expecting it. Now in the case of a NAT you can change your filter to search for the destination IP, since it will not change. Assuming not too much other traffic is heading to that address this usually works best and I have made it my general practice to filter by destination in these cases. These are just two common examples of why knowing your network AND understanding how the firewall works are very important when it comes to feeling productive using packet capture tools. Next month: FW MONITOR struts its stuff.