Palo Alto Packet Capture

Capture on MGMT interface:

> tcpdump filter "host x.x.x.x"

> view-pcap mgmt-pcap mgmt.pcap

================

 1. Filter is bi-directional. 
         Packet captures are session-based, so a single filter is capable of capturing both client2server and server2client

2. Receive and transmit stage can use same capture file so we can see tx/rx in one capture file. If not doing this, we can merge rx/tx files in Wireshark.

3. Only new session is captured.

4. Four stages

• 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  packet is inspected against policy, includes packets that establish or match to an existing session

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

capture on local VPN tunnel interface only see traffic comes out from the tunnel ( incoming decrypted traffic)

> view-pcap filter-pcap <name>

===================

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClTJCA0

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClfqCAC&lang=en_US&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

========

For Ping from 192.168.50.50 (NATed to 192.168.2.102) to 4.2.2.2, capture filter:

firewall stage capture

Receive stage capture

Transmit stage capture

Conclusion:

Transmit capture has initial traffic left egress interface and return traffic comes out from ingress interface. If see both, means both initial and return traffic pass through firewall.
Firewall stage and receive stage are same, which have initial traffic enter ingress interface and return traffic enter egress interface.

For Ping from 192.168.50.50 (NATed to 192.168.2.102) to 4.2.2.2 with capture on inside interface, capture filter:

Firewall Stage:

Receive stage:  this doesn't make sense

Transmit stage:

For Ping from 192.168.50.50 (NATed to 192.168.2.102) to 4.2.2.2 with capture on outside  interface, capture filter:

Firewall stage:

Receive stage:

Transmit stage:

Ping from PA side 192.168.50.50 to FG side 10.10.10.6 cross S2S VPN tunnel with filter:

When ping has response

Transmit stage

Receive stage 

Firewall stage

When ping 10.10.10.10 which is not alive

Firewall stage

Receive stage:

Transmit stage no packet is captured.

=============================CLI=============

filter-marked-session

   It displays the active session match capture filter, even now capture filter is already OFF

   So suggested to clear all active filter-marked-session before turn on capture.

   Also need clear the matching session from session table before turn on capture

debug dataplane packet-diag show setting

debug dataplane packet-diag clear all

debug dataplane packet-diag show filter-marked-session.

debug dataplane packet-diag clear filter-marked-session all

debug dataplane packet-diag set filter on

debug dataplane packet-diag set filter match ....

debug dataplane packet-diag set capture on

debug dataplane packet-diag set capture off

view-pcap [no-dns-lookup yes] filter-pcap <filename>
  <tftp | scp> export filter-pcap from <filename> to <tftp-ip | user@ip-address:path>

Flow Basic Stages
ingress stage

session setup (slow path)

security processing (fastpath)

egress stage (forwarding)

block page, closing session

Packet capture filter can be applied to global counter

produces results relative to the last time that the command was run

[Palo Alto Networks]  

show counter global filter packet-filter yes delta yes

https://fwknowledge.wordpress.com/2013/03/07/palo-alto-packet-capture-cli/

Best practice:

1. Capture on ingress interface to verify if see both initial traffic and reply. This works for tunnel interface.
    set same file "rt" so we can see bidirectional traffic in on capture file

2. if don't see reply, capture on egress interface to verify if traffic pass firewall and if reply reach firewall

 Ping from 10.0.0.10 to 4.2.2.2

1. capture on ingress interface

2. capture on egress interface