• Tcpdump Filter For Mac Shortcut
• Tcpdump Show Mac
• Tcpdump Filter Multiple Mac Addresses

Important

Netgate is offering COVID-19 aid for pfSense software users, learn more.

Tcpdump supports the “ether” qualifier to specify ethernet addresses in the standard colon-separated format. For example, to capture any broadcast traffic, $ tcpdump ether dst ff:ff:ff:ff:ff:ff. To capture any traffic sent to or from a given MAC address, $ tcpdump ether host e8:2a:ea:44:55:66.

1. Create a capture file with 1000 packets (-c 1000) without using a cature filter; Use tcpdump to extract a file with the filter (tcpdump -r full.pcap -w incl.pcap 'ether0:4 & 0xffffff0f = 0x0009fb06 or ether6:4 & 0xffffff0f = 0x0009fb06').
2. Capture Packets from Specific Interface. The command screen will scroll up until you interrupt.

The tcpdump program is a command line packet capture utility provided withmost UNIX and UNIX-like operating system distributions, including FreeBSD. It isalso included in pfSense® firewalls, and usable from a shell on the consoleor over SSH.

It is an exceptionally powerful tool, but that also makes it daunting to theuninitiated user. The tcpdump binary in FreeBSD 10.3 supports 50 differentcommand line flags, limitless possibilities with filter expressions, and its manpage, providing only a brief overview of all its options, is nearly 1200 lineslong and 67k. After learning to use it, knowledge of how to interpret the datait provides is also necessary, which can require an in-depth understanding ofnetworking protocols.

A comprehensive review of packet capturing and interpretation of the results isoutside the scope of this documentation. For those with a thirst for more thanbasic knowledge in this area, some recommendations are provided in theAdditional References section. This section is intended to provide anintroduction to this topic, and leave the reader with enough knowledge for basictroubleshooting.

tcpdump commonly used flags¶

The following table shows the most commonly used command line flags withtcpdump. Each option will be discussed in further detail in this section.

-i flag¶

The -i flag specifies the interface on which tcpdump will listen. UseFreeBSD interface names here, such as igb0, em0, vmx0, etc.

-n flag¶

Do not resolve IP addresses using reverse DNS. When this option is notspecified, tcpdump will perform a reverse DNS (PTR) lookup for each IP address.This generates a significant amount of DNS traffic in captures displaying largevolumes of traffic. Disable this to avoid adding load to DNS servers. Werecommend always using -n because it eliminates the delay between a packet’scapture and its display that is caused by performing the reverse lookup. Also IPaddresses tend to be easier to read and understand than their PTR records. Thatis a matter of personal preference though, and in familiar environments wherethe PTR records are known to provide the actual host names of the devices,captures may be run without -n to show the hostnames.

Another reason to use -n, is to be “sneaky.” One means of detecting packetcapturing is looking for spikes and patterns in DNS PTR lookups. Skipping theDNS lookup will not cause any extra traffic to be generated in the process.

-w flag¶

tcpdump allows capture files to be saved in pcap format for later analysis oranalysis on another system. This is commonly done from command line only deviceslike pfSense so the file can be copied to a host running Wireshark or anothergraphical network protocol analyzer and reviewed there. When saving to a fileusing -w, the frames will not be displayed in the terminal as they otherwiseare.

See also

See Using Wireshark with pfSense for moreinformation about using Wireshark with pfSense.

-s flag¶

By default tcpdump will only save the first 64 bytes of each frame whencapturing to a file. This is enough to get the IP and protocol header for mostprotocols, but limits the usability of capture files. By using the -s flag,tcpdump can be told how much of the frame to capture, in bytes. This is calledthe snap length.

In most cases, using -s0 is the best practice when capturing to a file foranalysis on another system. The only exception to this is scenarios where asignificant amount of traffic must be captured over a longer period of time. Ifthe information being sought is known to be in the header, the default 64 bytesof each frame may be used to get the required information while significantlyreducing the size of the resulting capture file.

-c flag¶

To capture a certain number of frames and then exit, use the -c flag.Example usage: tcpdump will exit after capturing 100 frames by specifying-c100.

-p flag¶

Normally when capturing traffic with tcpdump, it puts the network interfaceinto promiscuous mode. When not running in promiscuous mode, the NIC onlyreceives frames destined for its own MAC address as well as broadcast andmulticast addresses. When switched into promiscuous mode, the interface showsevery frame on the wire that arrives at the network interface. In a switchednetwork, this generally has little impact on the capture. In networks where thedevice is connected to a vswitch also in promiscuous mode, or a hub, using-p can significantly limit noise in the capture when the only traffic ofinterest is to and from the system performing the capture.

-v flag¶

The -v flag controls the detail, or verbosity, of the output. Using more “v”options yields more detail, so use -v, -vv, or -vvv to view evenmore detail in the output printed to the console. This option does not affectthe detail stored in a capture file when using the -w switch, but willinstead cause the process to report the number of packets captured every 10seconds.

-e flag¶

Normally tcpdump does not show any link layer information. Specify -e todisplay the source and destination MAC addresses, and VLAN tag information forany traffic tagged with 802.1q VLANs.

Example capture without -e¶

This capture shows the default output, containing no link layerinformation:

Example capture using -e¶

Here the link layer information is included by using -e. Note the source anddestination MAC addresses in addition to the source and destination IPaddresses:

tcpdump Filters¶

On most firewalls running tcpdump with no filters will produce so muchoutput that it will prove very difficult to find traffic of interest. There arenumerous filtering expressions available that limit the traffic displayed orcaptured.

Host filters¶

To filter for a specific host, append host and the IP address to thetcpdump command. To filter for host 192.168.1.100 use the followingcommand:

That will capture all traffic to and from that host. To only capture trafficbeing initiated by that host, use the src directive:

Similarly, filtering for traffic destined to that IP address is possible byspecifying dst:

Network filters¶

Network filters narrow the capture to a specific subnet using the netexpression. Following net, specify a dotted quad ( 192.168.1.1), dottedtriple ( 192.168.1), dotted pair ( 192.168) or simply a number (192). A dotted quad is equivalent to specifying host, a dotted tripleuses a subnet mask of 255.255.255.0, a dotted pair uses 255.255.0.0, and anumber alone uses 255.0.0.0.

The following command displays traffic to or from any host with a192.168.1.x IP address:

The next command will capture traffic to or from any host with a 10.x.x.x IPaddress:

Those examples will capture all traffic to or from the specified network. Thesrc or dst keywords may be used the same as with host filters tocapture only traffic initiated by or destined to the specified network:

A CIDR mask can also be passed as an argument to net:

Protocol and port filters¶

Narrowing down by host or network frequently isn’t adequate to eliminateunnecessary traffic from a capture. Or the source or destination of traffic maynot be significant, and all traffic of a certain type should be captured. Inother cases, filtering out all traffic of a specific type can reduce noise.

TCP and UDP port filters¶

To filter on TCP and UDP ports, use the port directive. This captures bothTCP and UDP traffic using the specified port either as a source or destinationport. It can be combined with tcp or udp to specify the protocol, andsrc or dst to specify a source or destination port.

Capture all DNS traffic¶

Capture all DNS traffic (usually UDP, but some queries use TCP):

Protocol filters¶

Specific protocols can be filtered using the proto directive or by using theprotocol name directly. Parameters passed to the proto directive can bespecified using the IP protocol number or one of the names icmp, igmp,igrp, pim, ah, esp, carp, vrrp, udp, or tcp.Because the normal protocol names are reserved words, they must be escaped withone or two backslashes when used with the proto directive, depending on theshell. The shell available in pfSense requires two backslashes to escape theseprotocol names. If a syntax error is returned, check that the protocol name isproperly escaped.

The following capture will show all ICMP traffic on the igb1 interface:

Specifying carp for the protocol will capture CARP traffic but it also needs-Tcarp in order to interpret the CARP packets correctly when viewing theoutput using tcpdump. The GUI makes this adjustment automatically whencapturing CARP.

The following capture will show all CARP traffic on the igb1 interface,which can be useful to ensure CARP traffic is being sent and received on thespecified interface. It also omits the proto keyword, showing that it workson its own:

Negating a filter match¶

In addition to matching specific parameters, a filter match can be negated byspecifying not in front of the filter expression. When troubleshootingsomething other than CARP, and its multicast heartbeats are cluttering thecapture output, exclude it as follows:

Combining filters¶

Any of the aforementioned filters can be combined using and or or. Thefollowing sections provide some examples.

Tcpdump Filter For Mac Shortcut

Display all HTTP traffic to and from a host¶

Display all HTTP traffic to or from 192.168.1.11:

Display all HTTP traffic to and from multiple hosts¶

Display all HTTP traffic from either 192.168.1.11 or 192.168.1.15:

Filter expression usage¶

Filter expressions must come after every command line flag used. Adding anyflags after a filter expression will result in a syntax error.

More on Filters¶

This section covered the most commonly used tcpdump filter expressions, andprobably covers all the syntax most users will need. However this barelyscratches the surface of the possibilities. There are many documents on the webthat cover tcpdump in general and filtering specifically. SeeAdditional References at the end of this chapter forlinks to more resources.

Practical Troubleshooting Examples¶

This section details an approach we prefer for troubleshooting a few specificproblems. There are multiple ways to approach any problem, but packet capturingcan rarely be beat for its effectiveness. Examining the traffic on the wireprovides a level of visibility into what is actually happening on the network

Port forward not working¶

In this example, a new port forward is failing to respond to a request from ahost on the Internet. The troubleshooting steps outlined inPort Forward Troubleshooting offers one way to approach this, butsometimes packet capturing is the only or easiest way to find the source of theproblem.

Start from WAN¶

First, make sure the traffic is getting to the WAN interface. Start a tcpdumpsession on the WAN interface, and watch for the traffic:

Tcpdump Show Mac

In this case, a packet comes in from the WAN, so it is making it that far. Notethat the first part of the TCP handshake, a packet with only SYN set (the Sshown), is reaching the firewall. If the port forward was working, a SYN ACK(S.) packet would be shown in reply to the SYN. With no return trafficvisible, it could be a firewall rule or the target system may be unreachable –turned off, not listening on the specified port, host firewall blocking thetraffic, etc.

Check Internal Interface¶

The next step would be to run a tcpdump session on the internalinterface associated with the port forward:

Looking at the internal traffic, the connection left the inside interface andthe local IP address was translated correctly. If this local address matcheswhat was expected, then both the port forward and the firewall rule are workingproperly, and connectivity to the local PC must be confirmed by other means. Ifno output was displayed, then there is a problem with the firewall rule or theport forward may have been incorrectly defined. For this example, the targetsystem was unplugged.

IPsec tunnel will not connect¶

tcpdump has some awareness of the protocols being used, which can be veryhelpful in figuring out problems with IPsec tunnels. The next few examples willshow how certain error conditions may present themselves when monitoring withtcpdump. The IPsec logs are usually more helpful, but this can confirm whatis actually being seen by the firewall. For encrypted traffic such as IPsec,packet capturing of the traffic is of less value as the payload of the capturedpackets cannot be examined without additional parameters, but it is helpful todetermine if traffic from the remote end is reaching the firewall and whichphases complete.

This first tunnel has an unreachable peer:

This tunnel attempt has a mismatched PSK, notice how it attempts to move tophase 2, but then stops:

Now Phase 1 is OK but there is a mismatch in the Phase 2 information. It willrepeatedly attempt phase 2 traffic but there will not be any traffic in thetunnel:

Finally, a fully working tunnel with two-way traffic after Phase 1 and Phase 2have completed!:

Traffic traversing an IPsec tunnel¶

Traffic can also be observed traversing IPsec tunnels by capturing on theenc0 interface. This can help determine if traffic is attempting to reachthe far end by using the tunnel. All traffic for all IPsec tunnels appears onthe enc0 interface.

In the following example, a host on one side of the tunnel is successfullysending an ICMP echo request (ping) to the far side, and receiving replies:

If traffic was not properly entering the tunnel, no output would be shown. Ifthere is a firewall or internal routing issue on the far side, traffic willappear leaving but nothing will show returning.

Troubleshooting Outbound NAT¶

Tcpdump Filter Multiple Mac Addresses

For complex environments where Manual Outbound NAT is needed, tcpdump can beof great assistance in troubleshooting the Outbound NAT configuration. One goodcapture to use is to look for traffic with private IP addresses on the WANinterface, as everything on WAN should be have NAT applied and appear to be apublic IP address. The following capture will display any traffic with RFC 1918IP addresses as the source or destination. This will show any traffic that isnot matching one of the outbound NAT rules, providing information to help reviewthe Outbound NAT configuration to find the problem: