>
    Strata Copilot
    Policy-Based Forwarding
    Focus
    Download PDF
    Focus
    1. Home
    2. Network Security
    3. Network Security: Security Policy
    4. Policy-Based Forwarding
    Download PDF
    Network Security

    Policy-Based Forwarding

    Table of Contents

    Policy-Based Forwarding

    Learn how policy-based forwarding allows override the routing table and send packets through a specified egress port.
    Where Can I Use This?What Do I Need?
    • Prisma Access (Managed by Panorama)
    • PAN-OS
    • Prisma Access license
      (for Panorama and Cloud Management)
    Normally, the firewall uses the destination IP address in a packet to determine the outgoing interface. The firewall uses the routing table associated with the virtual router to which the interface is connected to perform the route lookup. Policy-Based Forwarding (PBF) allows you to override the routing table, and specify the outgoing or egress interface based on specific parameters such as source or destination IP address, or type of traffic.
    PBF rules allow traffic to take an alternative path from the next hop specified in the route table, and are typically used to specify an egress interface for security or performance reasons. Let's say your company has two links between the corporate office and the branch office: a cheaper internet link and a more expensive leased line. The leased line is a high-bandwidth, low-latency link. For enhanced security, you can use PBF to send applications that aren’t encrypted traffic, such as FTP traffic, over the private leased line and all other traffic over the internet link. Or, for performance, you can choose to route business-critical applications over the leased line while sending all other traffic, such as web browsing, over the cheaper link.

    Egress Path and Symmetric Return

    Using PBF, you can direct traffic to a specific interface on the firewall, drop the traffic, or direct traffic to another virtual system (on systems enabled for multiple virtual systems).
    In networks with asymmetric routes, such as in a dual ISP environment, connectivity issues occur when traffic arrives at one interface on the firewall and leaves from another interface. If the route is asymmetrical, where the forward (SYN packet) and return (SYN/ACK) paths are different, the firewall is unable to track the state of the entire session and this causes a connection failure. To ensure that the traffic uses a symmetrical path, which means that the traffic arrives at and leaves from the same interface on which the session was created, you can enable the Symmetric Return option.
    With symmetric return, the virtual router overrides a routing lookup for return traffic and instead directs the flow back to the MAC address from which it received the SYN packet (or first packet). However, if the destination IP address is on the same subnet as the ingress/egress interface’s IP address, a route lookup is performed and symmetric return is not enforced. This behavior prevents traffic from being silently discarded.
    To determine the next hop for symmetric returns, the firewall uses an Address Resolution Protocol (ARP) table. The maximum number of entries that this ARP table supports is limited by the firewall model and the value is not user configurable. To determine the limit for your model, use the CLI command: show pbf return-mac all.

    Path Monitoring for PBF

    Path monitoring allows you to verify connectivity to an IP address so that the firewall can direct traffic through an alternate route, when needed. The firewall uses ICMP pings as heartbeats to verify that the specified IP address is reachable.
    A monitoring profile allows you to specify the threshold number of heartbeats to determine whether the IP address is reachable. When the monitored IP address is unreachable, you can either disable the PBF rule or specify a fail-over or wait-recover action. Disabling the PBF rule allows the virtual router to take over the routing decisions. When the fail-over or wait-recover action is taken, the monitoring profile continues to monitor whether the target IP address is reachable, and when it comes back up, the firewall reverts back to using the original route.
    The following table lists the difference in behavior for a path monitoring failure on a new session versus an established session.
    Behavior of a session on a monitoring failure
    If the rule stays enabled when the monitored IP address is unreachable
    If rule is disabled when the monitored IP address is unreachable
    For an established session
    wait-recover—Continue to use egress interface specified in the PBF rule
    wait-recover—Continue to use egress interface specified in the PBF rule
    fail-over—Use path determined by routing table (no PBF)
    fail-over—Use path determined by routing table (no PBF)
    For a new session
    wait-recover—Use path determined by routing table (no PBF)
    wait-recover—Check the remaining PBF rules. If no match, use the routing table
    fail-over—Use path determined by routing table (no PBF)
    fail-over—Check the remaining PBF rules. If no match, use the routing table

    Service Versus Applications in PBF

    PBF rules are applied either on the first packet (SYN) or the first response to the first packet (SYN/ACK). This means that a PBF rule may be applied before the firewall has enough information to determine the application. Therefore, application-specific rules are not recommended for use with PBF. Whenever possible, use a service object, which is the Layer 4 port (TCP or UDP) used by the protocol or application.
    However, if you specify an application in a PBF rule, the firewall performs App-ID caching. When an application passes through the firewall for the first time, the firewall does not have enough information to identify the application and therefore cannot enforce the PBF rule. As more packets arrive, the firewall determines the application and creates an entry in the App-ID cache and retains this App-ID for the session.When a new session is created with the same destination IP address, destination port, and protocol ID, the firewall could identify the application as the same from the initial session (based on the App-ID cache) and apply the PBF rule. Therefore, a session that is not an exact match and is not the same application, can be forwarded based on the PBF rule.
    Further, applications have dependencies and the identity of the application can change as the firewall receives more packets. Because PBF makes a routing decision at the start of a session, the firewall cannot enforce a change in application identity. YouTube, for example, starts as web-browsing but changes to Flash, RTSP, or YouTube based on the different links and videos included on the page. However with PBF, because the firewall identifies the application as web-browsing at the start of the session, the change in application is not recognized thereafter.
    You cannot use custom applications, application filters, or application groups in PBF rules.

    © 2026 Palo Alto Networks, Inc. All rights reserved.