Packet captures are an excellent way of troubleshooting FireEye error messages because they contain all the information that passes from one device to another, regardless of compression and encryption.
If it didn't happen in the packet capture, then it didn't happen, regardless of what the error message says.
Example: SSL handshake failed
This error indicates that a connection was made and the certificate or cipher looked wrong. But when you examine the capture, you see that there never was a handshake all; a reset was sent at the beginning of the connection attempt. Instead of going down the path of trying to figure out what ciphers everyone is using and what device is mucking up the certificate/ssl stream, you can now focus on the simple fix of changing a firewall setting to unblock the connection.
Examples of when to use packet capture for troubleshooting
|Examples of things you can do with a packet capture|
NX Deployment Check Tool
The NX includes a deployment check tool that will monitor all ports for 150 seconds or 100,000 packets.
- From the Web UI, go to About > Deployment Check > Network Deployment Check
- From the CLI:
# enableNote: ftp, tftp, scp and sftp are supported. You can also use an scp utility to access the file at /var/opt/tms/tcpdumps
> configure terminal
> file tcpdump upload deployment_check.pcap <*p://username[:password]@hostname/path/filename>
Capturing VLAN and non-VLAN traffic
You can capture VLAN and non-VLAN traffic at the same time, but this requires the parts of the filter to be in a specific order. Each use of vlan changes the decoding offsets for the remainder of the expression.
For example, here we search the host first to catch packets with no VLAN, then we search for vlan and the same host to catch VLAN packets with that host.
tcpdump -nnvvi eth0 'host 220.127.116.11 or (vlan and host 18.104.22.168)'
If we reverse this to '(vlan and host 22.214.171.124) or host 126.96.36.199', we would not find packets in the native or untagged VLANs because the second mention of host would be offset by 4 bits, causing it to fail.
Because Q-in-Q uses two vlan tags next to each other in the header, we use vlan twice to move the offset for the rest of the filter.
tcpdump -nnvvi eth0 'vlan and vlan and host 188.8.131.52'
Although it seems intuitive that (host x.x.x.x or (vlan and host x.x.x.x ) or (vlan and vlan and host x.x.x.x)) would catch all the types of traffic (non-VLAN, VLAN, and Q-in-Q traffic), the third use of vlan pushes the alignment 4 bits too far. The solution is to repeat the single vlan statement a second time, which moves the offset four more bits to match the Q-in-Q VLAN.
Let's say you want to catch a set of addresses and you're not sure if they have a VLAN. The hosts are in the following ranges: 184.108.40.206, 220.127.116.11, and 18.104.22.168 to 22.214.171.124.
Capturing normal and single VLANs
tcpdump -nnvvi eth0 '(host 126.96.36.199 or host 188.8.131.52 or net 184.108.40.206/28)or (vlan and (host 220.127.116.11 or host 18.104.22.168 or net 22.214.171.124/28))'
Capturing Q-in-Q packets
tcpdump -nnvvi eth0 '(host 126.96.36.199 or host 188.8.131.52 or net 184.108.40.206/28) or (vlan and vlan and (host 220.127.116.11 or host 18.104.22.168 or net 22.214.171.124/28))'
Capturing all three packet types
tcpdump -nnvvi eth0 '(host 126.96.36.199 or host 188.8.131.52 or net 184.108.40.206/28) or (vlan and (host 220.127.116.11 or host 18.104.22.168 or net 22.214.171.124/28)) or (vlan and (host 126.96.36.199 or host 188.8.131.52 or net 184.108.40.206/28))'
Use the -w <filename> option to write the results to a file that can be accessed in /var/opt/tms/tcpdumps/