• RX - Pre-decryption, pre-NAT
• FW - Post-decryption, pre-NAT
• TX - Post-decryption, post-NAT
• DR - Dropped packets

Putting RX and TX into the same file will, if NAT is involved, result in the packet capture putting both the pre-NAT packet and the post-NAT packet in the PCAP. Including the FW stream will result in duplicate errors as it will clash with RX.

I've seen drops recorded when a packet was tranmisted and then a routing loop pushed the packet straight back at the firewall. So the packet was shown in TX and DR.

NAT affects what IP you should put in the packet capture filter.

I've noticed that you don't really need to put the reverse stream into the capture. Just source and destination will end up capturing both c2s and s2c streams of the traffic flow. An exception may be sesssions that can be bi-directional like IKE on udp-500.

In the following example there are two devices 10.2.2.22 10.3.3.33

Client 10.2.2.22 will try to access server 10.3.3.33. However, client 10.2.2.22 will source NAT behind 192.168.2.22 and will try and access the sever on IP 192.168.3.33 which is then destination NAT'd to 10.3.3.33.

In the example below, we have

• actual client (pre-NAT client)
• actual server (post-NAT server)
• fake client (post-NAT server)
• fake server (pre-NAT server)

If we capture with no IP filter, we get

• rx
  • c2s actual client to fake server
  • s2c actual server to fake client
• fw
  • c2s actual client to fake server
  • s2c actual server to fake client
• tx
  • c2s fake client to actual server
  • s2c fake server to actual client

If we filter by IP

• 10.2.2.22 > 10.3.3.33 doesn't work
• 192.168.2.22 > 192.168.3.33 doesn't work

However

• 10.2.2.22 > 192.168.3.33 works
• rx
  • c2s actual client to fake server
  • s2c actual server to fake client
• fw
  • c2s actual client to fake server
  • s2c none (nothing captured)
• tx
  • c2s none (nothing captured)
  • s2c fake server to actual client

Also

• 192.168.2.22 > 10.3.3.33 works
• rx
  • c2s actual client to fake server
  • s2c actual server to fake client
• fw
  • c2s none (nothing captured)
  • s2c actual server to fake client
• tx
  • c2s fake client to actual server
  • s2c none (nothing captured)

If you set the capture to have two filters

• 10.2.2.22 > 192.168.3.33
• 192.168.2.22 > 10.3.3.33
• rx
  • c2s actual client to fake server
  • s2c actual server to fake client
• fw
  • c2s actual client to fake server
  • s2c actual server to fake client
• tx
  • c2s fake client to actual server
  • s2c fake server to actual client

Conclusions for double NAT'd traffic:

• Capturing “recieved” traffic is easy.
• Capturing “firewalled” and “transmitted” traffic that included both directions of traffic flow requires you to include two filters, the pre-NAT IP address and the post-NAT IP addresses

If you have destination NAT only where 10.2.2.22 connects to 192.158.3.33 which is D-NAT'd to 10.3.3.33, then

• 10.2.2.22 > 192.168.3.33 works
• rx
  • c2s actual client to fake server
  • s2c actual server to actual client
• fw
  • c2s actual client to fake server
  • s2c none (nothing captured)
• tx
  • c2s none (nothing captured)
  • s2c fake server to actual client

Also

• 10.2.2.22 > 10.3.3.33 works
• rx
  • c2s actual client to fake server
  • s2c actual server to actual client
• fw
  • c2s none (nothing captured)
  • s2c actual server to actual client
• tx
  • c2s actual client to actual server
  • s2c none (nothing captured)

If you set the capture to have two filters

• 10.2.2.22 > 192.168.3.33
• 10.2.2.22 > > 10.3.3.33
• rx
  • c2s actual client to fake server
  • s2c actual server to actual client
• fw
  • c2s actual client to fake server
  • s2c actual server to actual client
• tx
  • c2s actual client to actual server
  • s2c fake server to actual client

If you have Source NAT only where 10.2.2.22 connects to 10.3.3.33 and S-NAT's behind 192.168.2.22, then

• 10.2.2.22 > 10.3.3.33 works
• rx
  • c2s actual client to actual server
  • s2c actual client to actual server
• fw
  • c2s actual client to actual server
  • s2c actual client to actual server
• tx
  • c2s actual client to actual server
  • s2c actual client to actual server

Also

• 192.168.2.22 > 10.3.3.33 doesn't work

Base on this article and this article.

• delta yes indicates I want to view counters that have incremented since the last time I executed this command.
• packet-filter yes indicates I want to see only global counters that match my filters.

show counter global filter packet-filter yes delta yes

Next you're going to configure the stages—there are 4:

• drop stage is where packets get discarded. The reasons may vary and, for this part, the global counters may help identify if the drop was due to a policy deny, a detected threat, or something else.
• receive stage captures the packets as they ingress the firewall before they go into the firewall engine. When NAT is configured, these packets will be pre-NAT.
• transmit stage captures packets how they egress out of the firewall engine. If NAT is configured, these will be post-NAT.
• firewall stage captures packets in the firewall stage.

Start packet captures

debug dataplane packet-diag set capture on

Stop packet captures

debug dataplane packet-diag set capture off

To Troubleshoot connectivity issues with the management plane, the built-in tcpdump command can be used to capture useful information:

tcpdump filter "port 53"

tcpdump filter "host 10.16.0.106 and not port 22"

view-pcap mgmt-pcap mgmt.pcap

First we're going to verify that nothing's been configured yet that could interfere with our new settings:

debug dataplane packet-diag show setting

If anything's still configured, we can clear out all filters and previous flow basic logs using these commands:

debug dataplane packet-diag clear all

debug dataplane packet-diag clear log log

We can now go ahead and create and enable the filters, making sure pre-parse is disabled. A second filter from the server to the NAT IP on the external interface of the firewall will help capture returning packets before they are NAT'ed in the 'ingress stage.' More about that below:

debug dataplane packet-diag set filter match source 192.168.0.34 destination 198.51.100.97 destination-port 80 protocol 6 non-ip exclude 

debug dataplane packet-diag set filter match source 198.51.100.97 destination 198.51.100.230 source-port 80 protocol 6 non-ip exclude 

debug dataplane packet-diag set filter on

debug dataplane packet-diag show setting

debug dataplane packet-diag set log feature flow basic

When you're ready to initiate traffic make sure any existing sessions have been terminated, then disable session offloading to ensure all packets are captured even if the session would normally be offloaded into hardware and finally go ahead and enable the logging feature.

show session all filter source 192.168.0.34 destination 198.51.100.97

If there are still active sessions you can clear them by using the clear session command:

clear session all filter source 192.168.0.34 destination 198.51.100.97

set session offload no

debug dataplane packet-diag set log on

You can now go ahead and start the session you want to capture, wait for it to gracefully end, then disable logging:

show session all filter source 192.168.0.34 destination 198.51.100.97

debug dataplane packet-diag set log off

set session offload yes

A nifty little tool is provided to aggregate these files into a single file:

debug dataplane packet-diag aggregate-logs

The final output file is then stored on the management plane as pan_packet_diag.log:

less mp-log pan_packet_diag.log

=Packet Filter=

debug dataplane packet-diag set filter match source 192.0.2.1 non-ip exclude

debug dataplane packet-diag set filter on

Then show your counters as a delta with just that filter:

show counter global filter delta yes packet-filter yes