

Now here’s the trick: I’m still using a single filter statement with the internal RFC1918 IPv4 address as the source and the public server IPv4 address as the destination: Scenario 2: Internal Client -> External Server with outgoing SNAT/PAT aka “Dynamic IP And Port” Never mind of the VLAN tag that is present on only one side of the connection since my client network is within VLAN 69 at this point while the other interface is untagged. (I wasn’t sure about this for a long time.) No need for a second statement such as server -> client.Ĭapturing all four stages, the firewall stage has everything captured, hence Wireshark is able to correlate the echo-request/-replies as well as the whole TCP/SSH session. Returning traffic is captured automatically. Simply use a single filter statement for your client -> server. Scenario 1: End-to-End Communication w/o NAT For all the following tests, I did a ping followed by an SSH connection attempt. (Has anyone ever had a case where this checkmark saved four life? Please write a comment if so!) In addition, I’m always capturing at all four stages. I’m always enabling the “pre-parse match” checkbox. To my mind, this is a reasonable tradeoff between “filtering but not too complicated”. For the sake of simplicity, I’m only using IP addresses in the filters, not ports. The screenshots are from Wireshark version 3.6.5. Furthermore, I definitely want to use a filter to limit the amount of captured packets. Wireshark should be able to correlate the incoming/outgoing packets into a single TCP stream. (Yes, I’m aware of all disadvantages of not using a real TAP and a real capture device.) In the end, I want a single pcap which shows all relevant packets for a client-server connection, even if NAT is in place. I’m simply using the Palo as a capturing device here, similar to a SPAN port on a switch. I am using the packet capture feature very often for scenarios in which the IP connections are in fact working (hence no problems at the tx/rx level nor on the security policy/profile) but where I want to verify certain details of the connection itself. While you might be familiar with the four stages that the Palo can capture (firewall, drop, transmit, receive), it’s sometimes hard to set the correct filter – especially when it comes to NAT scenarios. It enables you to capture packets as they traverse the firewall. Palo Alto firewalls have a nice packet capture feature.
