Support FAQ

This guide is designed to help firewall admins effectively understand flood attack prevention and troubleshoot flooding incidents detected by Palo Alto Networks firewalls. Whether the event is triggered by packet buffer protection (PBP), Zone Protection (ZPP), or DoS protection profiles (DoSP), this document provides guidance on how to identify the type of flood, determine the root cause, and take corrective & preventive actions through “Best Practices”.   

Most days, BGP runs quietly in the background. BGP advertises routes that keep your WAN, VPN, cloud environments, and public services connected and reachable. Until it doesn’t. And when BGP breaks, it’s not just a routing issue, it’s unreachable services and frustrated users.   This guide will help you troubleshoot BGP on Palo Alto Networks firewalls, so you can quickly identify the problem and get traffic flowing again.   Understand the Basics: Is It You or Them? Before diving deep into logs and captures, start by asking: Is this a new BGP configuration that never came up, or an existing session that suddenly stopped working? Is the problem BGP-related or does it point to a larger connectivity or firewall policy issue?  Many BGP issues boil down to basic reachability, misconfigurations, or route filtering errors. Let’s walk through how to systematically rule those out.    Start with the Transport Before you jump to BGP configurations, always remember that BGP won't even attempt to negotiate unless the underlying TCP session (port 179) can be established. If the basic IP reachability or session is broken, BGP will stay silent. Check Interfaces and Zones: Confirm the interface is physically up, has the correct assigned IP, and is placed in the intended zone. Ensure the virtual router routing table has the correct next-hop to the peer.   Ping the Peer IP (Basic Reachability Check): Verify your firewall can reach the BGP neighbor IP from the correct interface and virtual router. This also validates that the firewall’s routing table has a path to the BGP neighbor. Review Security Policies: Confirm you are explicitly allowing the BGP App-ID (TCP/179) in both directions: From the local zone to the BGP peer’s zone. From the BGP peer’s zone to the local zone.   Always start by verifying Layer 3 and Layer 4 connectivity, before diving into BGP-level config. Check this helpful KB on learning about BGP Neighbor Adjacency.    Check BGP Session Status Once you’ve confirmed the underlying transport is open and reachable, your next move is to see what the BGP session is doing.    Before jumping into the CLI, you can check the System Logs in the GUI (Monitor -> Logs -> System). These logs can provide early hints about BGP negotiation failures, mismatched parameters, or TCP resets. You can filter the system logs to show events related to routing ( subtype eq routing ).    Why start with the system logs? They can quickly show if the firewall is attempting to open the BGP session. You'll often see useful error messages such as: "BGP peer x.x.x.x, Connection rejected." "BGP peer x.x.x.x, Wrong AS number." "BGP peer x.x.x.x, Hold timer expired." System logs can also confirm if your firewall is sending or receiving BGP connection attempts, or if the session is being actively torn down due to policy or config errors. Use the CLI to Confirm the Session State   After reviewing the system logs, you can validate the current BGP session state by entering show routing protocol bgp peer.   This command shows real-time status of your BGP peers. Here’s what the session states mean: Idle / Active No TCP session established. Go back and double-check transport, routing, peer IP, and security policies. Connect TCP handshake is trying but hasn't completed—this still points to possible transport or routing issues. OpenSent / OpenConfirm TCP is up and BGP messages are being exchanged, but something is preventing the session from finalizing. Check AS numbers, BGP passwords, and timer mismatches. Established Success! The session is up. If routes aren’t flowing as expected, you’ll want to investigate import/export policies or route filters.   If the CLI shows your session is stuck in Active or Connect, it’s usually still a basic connectivity or transport issue. Head back to the earlier steps to double-check transport and policy.   Review BGP Configuration (Local and Peer Settings) If your BGP session is stuck in OpenSent or OpenConfirm, or even if it's Established but routes aren’t flowing, the next step is to double-check your BGP configuration on both sides.   Key items to verify in the PAN Firewall GUI or CLI:   Local AS Number Confirm the local AS number matches what your peer expects.   On Palo Alto: Network > Virtual Routers > <VR> > BGP > General CLI: show routing protocol bgp peer <peer-IP>   Peer IP Address   Ensure the correct peer IP address is configured. Peer AS Number   The peer AS must match the remote device's local AS. Authentication (if configured) Confirm both sides have the same MD5 password.   A mismatch here will cause the session to hang in OpenSent or get rejected. On Palo Alto: Network > Virtual Routers > <VR> > BGP > Peer Group > <peer> > Authentication BGP Timers Ensure your keepalive and hold timers are aligned with the peer. Advanced Options If using multi-hop eBGP, confirm that EBGP multihop is enabled. Default is set to 1. Verify address families (IPv4, IPv6) match what the peer supports. Check for any route-reflector, route-server, or additional features that might require matching settings.   Check Route Advertisements and Filters Once your BGP session is established, confirm that routes are actually being exchanged. View Advertised and Received Routes: Go to: Network > Virtual Routers > [Your VR] > BGP > Peer Group > [Your Peer] Click on More Runtime Stats. Under RIB Out, view the routes being advertised. Under RIB In, view the routes being received. View Local Routing Table Go to: Network > Virtual Routers > [Your VR] Click More Runtime Stats. View the Routing Table tab. Review Filters and Policies Check if Export Rules (under BGP > Export Rules) are blocking intended prefixes. Review Import Rules (under BGP > Import Rules) to ensure you're not accidentally discarding routes from the peer. Confirm any Redistribution Profiles are properly set up if you're trying to redistribute static, connected, or other routes into BGP. If you're seeing routes in RIB In, but they're missing from the local routing table, check:   Administrative distances (BGP may lose to another protocol like static or OSPF). Route filtering policies. Overlapping or conflicting routes.   Wrapping It Up   BGP troubleshooting can feel overwhelming, especially when the symptoms impact critical services across WAN, VPN, and cloud environments. Break it down step by step to make it more manageable:   Start with the transport layer. Check the BGP session state. Validate key configurations. Review the routes being exchanged.   For more examples, use cases, and configuration tips, check out the Knowledge Base resource list for BGP Configuration and Troubleshooting.  

If you’ve ever worked with network security, you’ve probably encountered Network Address Translation (NAT) at some point. It’s one of those fundamental networking concepts that keeps the internet running smoothly. But why should you use NAT specifically on Palo Alto Networks ‘firewalls? Let’s break it down in a way that makes sense, especially if you're managing security policies and network architecture.

This guide covers SSL Forward Proxy and SSL Inbound Inspection. We will discuss and provide resources on why you might need these configurations, suitable implementation scenarios, and practical strategies for planning, configuring, and troubleshooting your deployment.    Do You Need SSL Decryption?   Not every environment requires SSL decryption, but there is a good chance you do. Start by assessing whether your organization faces threats hidden in encrypted traffic or compliance requirements requiring traffic inspection. Common indicators that you might need SSL decryption include: High volumes of encrypted traffic that lack visibility (Head over to your firewalls’ ACC tab, do you find SSL being one of your top-used applications?) Concerns about threats like malware or data exfiltration within encrypted channels. Compliance requirements for data inspection or monitoring. For insights on making this decision, check out PANcast Episode 9: Should You Have SSL Decryption Enabled?   Understanding SSL Decryption Types   SSL Forward Proxy: Used for outbound traffic from internal users to external servers. The firewall intercepts encrypted sessions, decrypts them for inspection, and re-encrypts them before forwarding to the destination. Ideal for preventing data exfiltration and inspecting malicious content in outgoing traffic. SSL Inbound Inspection: Applied to inbound traffic targeting internal servers. The firewall uses the server’s private key to decrypt incoming sessions, inspect the content, and re-encrypt it for delivery. Suitable for protecting web applications and servers that you host from encrypted attacks. For more details read through the Decryption Overview.   Planning for SSL Decryption   Effective deployment requires careful planning to minimize performance impact and comply with privacy laws. Key considerations include: Defining Your Scope: Decide which traffic to decrypt based on your organizational needs and compliance requirements. Capacity Planning: Ensure your firewall can handle the processing demands of SSL decryption. Privacy Compliance: Exclude sensitive traffic, such as financial or healthcare data, to avoid violating regulations. For a comprehensive planning guide visit, Plan Your SSL Decryption Best Practice Deployment.   Configuration Steps   Prepare Your Environment: Install and configure certificates for SSL Forward Proxy or Inbound Inspection. Define decryption profiles to specify allowed and blocked traffic. Create Policies: Set up decryption policies to identify traffic for inspection. Configure exclusions for sensitive or exempted traffic (e.g., banking or healthcare). Apply Decryption Profiles: Associate profiles with your decryption policies to enforce the desired behavior. Detailed configuration steps can be found through Configure SSL Forward Proxy and Configure SSL Inbound Inspection. Once decryption is configured, check out How Do I Know If Traffic is Hitting a Decryption Policy?   Best Practices   Start Small: Roll out decryption incrementally to specific traffic flows or user groups. Monitor Performance: Keep an eye on firewall resource utilization and session limits. Log and Analyze Traffic: Use logs to identify misconfigurations or traffic that doesn’t match policies. For additional guidance, refer to the Decryption Best Practices.   Additional Resources   SSL decryption is a powerful tool for enhancing visibility and securing your network against encrypted threats. Whether you’re just starting or optimizing an existing deployment, the resources linked in this guide can help you navigate the process effectively.   For further insights, see:   Resource List: SSL Decryption Configuring and Troubleshooting Troubleshoot and Monitor Decryption SSL Decryption Session is Full Inbound SSL Decryption for apache2 server

Are you seeking better control over your web traffic? This guide will walk you through the steps to create custom URL categories and integrate them into your security policies.

There are many reasons as to why Data Plane (DP) CPUs can be high, so addressing this behavior on Palo Alto Networks firewalls can be tricky. It’s best to use a comprehensive and methodical approach to handling DP CPUs.

Learn a methodical approach to troubleshooting IPSec VPN issues in this Support FAQ article.

LIVEcommunity's Support FAQ provide clear, comprehensive resources that address customers' most common issues. Here's what you need to know about Upgrading PAN-OS and Upgrade Paths.