# Palo Packet Capture: Choosing the Right Filter

Palo Alto firewalls have a nice packet capture feature. It enables you to capture packets as they traverse the firewall. 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. (At least it was hard for me…)

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. I’m simply using the Palo as a capturing device here, similar to a SPAN port on a switch. (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. Wireshark should be able to correlate the incoming/outgoing packets into a single TCP stream. Furthermore, I definitely want to use a filter to limit the amount of captured packets. This is how I’m doing it:

# PAN: Logging of Packet-Based Attack Protection Events e.g. Spoofed IP

I just had a hard time figuring out that a network routing setup was not working due to a correctly enforced IP Spoofing protection on a Palo Alto Networks firewall. Why was it a hard time? Because I did not catch that the IP spoofing protection kicked in since there were no logs. And since we do log *everything*, a non-existent log means nothing happened, right? Uhm, not in this case. Luckily you can (SHOULD!) enable an additional thread log on the Palo.

# Palo Alto Syslog via TLS

As we have just set up a TLS capable syslog server, let’s configure a Palo Alto Networks firewall to send syslog messages via an encrypted channel. While it was quite straightforward to configure I ran into a couple of (unresolved) problems as I added and deleted some syslog servers and their certificates. Uhm.

# Palo Alto: User Group Count Exceeds Threshold

We have run into an annoying situation: A hardware-dependent limit of user groups on a Palo Alto Next-Generation Firewall. That is: We cannot use more Active Directory groups at our firewalls. The weird thing about this: We don’t need that many synced groups on our Palo, but we have to do it that way since we are using nested groups for our users. That is: Palo Alto does not support nested groups out of the box, but needs all intermediary groups to retrieve the users which results in a big number of unnecessary groups.

I am asking you to give me some input on how you’re using user groups on the Palo. How are you using group filters? What count of AD groups do you have? Are you using nested groups (which is best practice)?

# Palo Alto Networks Cluster “not synchronized”

For whatever reason, I had a Palo Alto Networks cluster that was not able to sync. A manual sync was not working, nor did a reboot of both devices (sequentially) help. Finally, the PAN support told me to “Export device state” on the active unit, import it on the passive one, do some changes, and commit. Indeed, this fixed it. A little more details:

# Route-Based VPN Tunnel Palo Alto <-> Cisco ASA

More than 6 years ago (!) I published a tutorial on how to set up an IPsec VPN tunnel between a Palo Alto Networks firewall and a Cisco ASA. As time flies by, ASA is now able to terminate route-based VPN tunnels (which is great!), we have IKEv2 running everywhere and enhanced security proposals. Hence, it’s time for an update:

# Palo Alto GRE Tunnel

Since PAN-OS version 9.0 you can configure GRE tunnels on a Palo Alto Networks firewall. Greetings from the clouds. As always, this is done solely through the GUI while you can use some CLI commands to test the tunnel. This time Palo put a little stumbling block in there as you have to allow a GRE connection with a certain zone/IP reference. I will show how to set up such a GRE tunnel between a Palo and a Cisco router. Here we go:

# Palo Alto Networks Feature Requests

This is a list of missing features for the next-generation firewall from Palo Alto Networks from my point of view (though I have not that many compared to other vendors such as Fortinet). Let’s see whether some of them will find their way into PAN-OS in the next years…

# Workaround for Not Using a Palo Alto with a 6in4 Tunnel

Of course, you should use dual-stack networks for almost everything on the Internet. Or even better: IPv6-only with DNS64/NAT64 and so on. ;) Unfortunately, still not every site has native IPv6 support. However, we can simply use the IPv6 Tunnel Broker from Hurricane Electric to overcome this time-based issue.

Well, wait… Not when using a Palo Alto Networks firewall which lacks 6in4 tunnel support. Sigh. Here’s my workaround:

# PAN Blocking Details

One of my readers sent me this question:

We have an internal discussion about whether it is possible to block the 3 way hanshake TCP but allow the JDBC application protocol. In other words we would like to block the test of the port with the command “telent address port” but we would like that the connections via JDBC continue to work. is it possible to do this theoretically? Is it possibile to do it with paloalto firewall?

Let’s have a look:

# My IPv6/Routing/Cisco Lab Rack (2019)

My lab rack of 2019 consists of multiple Cisco routers and switches, as well as Juniper ScreenOS firewalls for routing purposes, a Palo Alto Networks firewall, a Juniper SRX firewall, a server for virtualization and some Raspberry Pis. That is: This rack can be used for basic Cisco courses such as CCNA or CCNP, or for even bigger BGP/OSPF or IPsec VPN scenarios since those ScreenOS firewalls are perfect routers as well. Of course, everything is IPv6 capable. Having some PoE-powered Raspberry Pis you can simulate basic client-server connections. A Juniper SA-2500 (aka Pulse Connect Secure) for remote accessing the Lab rounds things up.

I am just writing down a few thoughts on why I have “designed” the rack in that way. It’s basically a reminder for myself. ;)

# Palo Alto Networks NGFW using NTP Authentication

Everyone uses NTP, that’s for sure. But are you using it with authentication on your own stratum 1 servers? You should since this is the only way to provide security against spoofed NTP packets, refer to Why should I run own NTP Servers?. As always, Palo Alto has implemented this security feature in a really easy way, since it requires just a few clicks on the GUI. (Which again is much better than other solutions, e.g., FortiGate, which requires cumbersome CLI commands.) However, monitoring the NTP servers, whether authentication was successful or not, isn’t implemented in a good way. Here we go:

# Using Case Sensitive IPv6 Addressing on a Palo Alto

IPv6 brings us enough addresses until the end of the world. Really? Well… No. There was an interesting talk at RIPE77 called “The Art of Running Out of IPv6 Addresses” by Benedikt Stockebrand that concludes that we will run out of IPv6 addresses some day.

Luckily Palo Alto Networks has already added one feature to expand the IPv6 address space by making them case sensitive. That is: you can now differentiate between upper and lower case values “a..f” and “A..F”. Instead of 16 different hexadecimal values you now have 22 which increases the IPv6 space from $2^{128}$ to about $2^{142}$. Here is how it works on the Palo Alto Networks firewall: