Active/Active HA in Layer 2 Mode

Active/Active High Availability (HA) is not supported in Layer 2 mode on Palo Alto Networks firewalls. This mode is only supported in Layer 3 and Virtual Wire (vWire) deployments.

In Active/Active HA, both firewalls process traffic simultaneously. This requires synchronization of session and routing tables, which isn't feasible in Layer 2 mode.

If Layer 2 is required, Active/Passive HA is the supported alternative, where one firewall is active and the other is on standby.

Official Configuration Guide

Session Matching in Palo Alto Firewalls

Palo Alto Networks firewalls use a 6-tuple to identify and match sessions. This ensures consistent policy enforcement and stateful inspection.

The 6-tuple includes:

• Source IP address
• Destination IP address
• Source port
• Destination port
• Protocol (e.g., TCP, UDP, ICMP)
• Zone (from/to)

Session matching enables the firewall to apply security policies, NAT, QoS, and logging accurately. Changes in any of the six fields result in a new session.

Learn more in the PAN-OS Admin Guide

Basic WildFire Service – Supported File Types

The basic WildFire service included with Palo Alto Networks firewalls allows forwarding of the following file types for malware analysis:

• Portable Executable (PE) files – e.g., .exe files
• Adobe Flash files – e.g., .swf files
• Android Application Packages (APK) – e.g., .apk files

These files are submitted to the WildFire public cloud for analysis. To enable forwarding of additional file types (such as PDFs, Microsoft Office documents, Java files, and scripts), an Advanced WildFire subscription is required.

Learn more about WildFire subscription options

Firewall Reboot – Rule Usage Tracking Behavior

✅ Rule Usage Hit Counter:

• Tracks rule match counts.
• Stored in RAM – resets to zero on reboot .

🔍 Highlight Unused Rules:

• Persistent (commit-based) tracking of unused rules.
• After reboot : no runtime session data → shows zero highlights initially .
• Rules will be marked as unused again only after new session data is collected.

📘 References:

• PAN-OS Admin Guide – View Policy Rule Usage
• Live Community – Rule Usage and Highlight Unused Differences

GlobalProtect Gateway – Supported Split Tunnel Methods

GlobalProtect Gateways support the following split tunnel methods:

• Access Route-Based Split Tunneling : Include or exclude traffic based on destination subnets or IP addresses. This method allows you to define which network routes should be sent through the VPN tunnel and which should bypass it. Learn more
• Domain-Based Split Tunneling : Include or exclude traffic based on destination domains. This method enables you to specify domain names whose traffic should be routed through or outside the VPN tunnel. Learn more
• Application-Based Split Tunneling : Include or exclude traffic based on specific applications. This method allows you to define application process names to determine which application traffic should be tunneled. Learn more

Firewall Bootstrapping via USB Flash Drive

🧰 Prerequisites:

• Firewall must be in factory default state or have all private data deleted.
• PAN-OS version 7.1.0 or later.

📁 USB Flash Drive Requirements:

• File system: FAT32 or ext3.
• Supported USB drives include:
  • Kingston SE9 8GB/16GB/32GB
  • SanDisk Cruzer Fit CZ33 8GB/16GB
  • SanDisk Cruzer CZ36 16GB/32GB
  • SanDisk Extreme CZ80 32GB
  • Silicon Power Jewel 32GB
  • Silicon Power Blaze 16GB
  • PNY Attache 16GB
  • PNY Turbo 32GB

📝 Required Files on USB:

• init-cfg.txt : Mandatory file containing bootstrap parameters.
• bootstrap.xml : Optional full configuration file exported from an existing firewall.
• License files: Placed in the /license directory.

⚙️ Preparation Steps:

1. Create init-cfg.txt with necessary parameters (e.g., hostname, IP addresses).
2. Optionally, export and rename a configuration file to bootstrap.xml .
3. Organize files into /config and /license directories.
4. Compress the directories into a .tar.gz file.
5. Transfer the bundle to the firewall using SCP or TFTP.
6. Insert the USB drive into the firewall and execute:

   request system bootstrap-usb prepare from <bundle_name>.tar.gz

🚀 Bootstrapping Process:

1. Insert the prepared USB drive into the firewall's USB port.
2. Power on the firewall; it will automatically detect and apply the bootstrap configuration.
3. Monitor the status LED; it turns green upon successful configuration.

📘 References:

• Prepare a USB Flash Drive for Bootstrapping a Firewall
• Bootstrap a Firewall Using a USB Flash Drive
• USB Flash Drive Support

Understanding Session End Reasons: incomplete, unknown-tcp, unknown-udp

When analyzing traffic logs on a Palo Alto Networks firewall, the "Session End Reason" provides crucial context for why a session terminated. Understanding the difference between `incomplete`, `unknown-tcp`, and `unknown-udp` is key for troubleshooting connectivity issues.

incomplete

ℹ️ Definition: This reason specifically applies to TCP sessions and indicates that the TCP three-way handshake (SYN, SYN/ACK, ACK) did not successfully complete . The firewall saw the beginning of a connection attempt, but the full handshake sequence was never observed.

🤔 Common Causes:

• No SYN/ACK Received: The firewall saw the initial SYN packet from the client, but never saw a SYN/ACK response from the server.
  • Possible Reasons: Server offline/unreachable, network path issue preventing return traffic, firewall upstream blocking the SYN/ACK, security policy on the PANW firewall blocking the SYN/ACK (less common if SYN was allowed).
• No Final ACK Received: The firewall saw the SYN from the client and the SYN/ACK from the server, but never saw the final ACK from the client to complete the handshake.
  • Possible Reasons: Client-side issue, network path issue preventing the final ACK from reaching the server/firewall, intermediate device blocking the ACK, **asymmetric routing** (where the ACK takes a different path that bypasses the firewall).
• Asymmetric Routing: A common cause where parts of the handshake traverse the firewall, but other parts (like the final ACK or the SYN/ACK) bypass it due to different routing paths for client-to-server vs. server-to-client traffic.

unknown-tcp

ℹ️ Definition: This reason applies to TCP sessions where the three-way handshake completed successfully , but the session terminated afterwards in a way that wasn't a graceful TCP close (FIN exchange). It often means the firewall observed a TCP Reset (RST) packet.

🤔 Common Causes:

• TCP RST Received: The most frequent cause. A RST packet was seen by the firewall, abruptly terminating the connection.
  • Possible Reasons: Application on the client or server closed the connection forcefully, an intermediate device sent a RST, OS-level issues, security policy on the PANW firewall configured to "reset" traffic matching certain criteria *after* the session was established, intrusion prevention system (IPS) action.
• TCP Sequence/State Issues: Less commonly, unexpected TCP flags or sequence numbers might cause the firewall to classify the end reason as unknown.
• Session Timeout (Less Common if RST Seen): While `aged-out` is the typical reason for timeouts, if a TCP session becomes completely idle after handshake and eventually times out without any FIN or RST packets being observed *just before* timeout, it might sometimes be logged as `unknown-tcp`, though `aged-out` is more specific.

unknown-udp

ℹ️ Definition: This reason applies to UDP (and ICMP) sessions. Since UDP is connectionless (no handshake or formal close procedure like TCP's FIN), this essentially means the firewall created a session for the UDP flow, but then stopped seeing packets for that flow, causing the session to expire based on its inactivity timer .

🤔 Common Causes:

• Normal UDP Timeout: This is often expected behavior. Many UDP applications send data sporadically. Once the communication stops, the firewall keeps the session open for the configured UDP timeout period and then closes it if no further packets arrive. Examples include DNS lookups, some streaming protocols during pauses, etc.
• Application Stopped Sending: The client or server application simply finished its UDP communication or was closed.
• Network Issues: Packet loss preventing further UDP packets from reaching the firewall for that specific flow.
• Asymmetric Routing: Similar to TCP, if UDP return traffic bypasses the firewall, the firewall will only see one direction and eventually time out the session.

🔑 Key Takeaway: `incomplete` relates to handshake failure (TCP only). `unknown-tcp` means the handshake succeeded, but the close was abrupt (often RST). `unknown-udp` means the UDP session timed out due to inactivity.

📘 References:

• PAN-OS Session End Reasons (Palo Alto Networks Knowledge Base)