>
    About Policy Based Forwarding
    Focus
    Download PDF
    Focus
    1. Home
    2. Next-Generation Firewall
    3. Set Up Firewalls
    4. Policy
    5. Policy Based Forwarding
    6. About Policy Based Forwarding
    Download PDF
    Next-Generation Firewall

    About Policy Based Forwarding

    Table of Contents

    About Policy Based Forwarding

    Learn more about Policy Based Forwarding (PBF) for your managed firewalls.
    Contact your account team to enable Cloud Management for NGFWs using Strata Cloud Manager.
    Where Can I Use This?What Do I Need?
    One of these:
    Policy Based Forwarding (PBF) allows you to configure traffic to take an alternative path from the next hop specified in the route table. PFB is typically used to specify an egress interface for security or performance reasons. For example, 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. 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 or drop the traffic.
    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 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, enable the Symmetric Return option.
    With symmetric return, the logical 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 or egress interface’s IP address, a route lookup is performed and symmetric return isn’t enforced. This behavior prevents traffic from being silently discarded.

    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 failover or wait-recover action. Disabling the PBF rule allows the logical router to take over the routing decisions. When the failover or wait-recover action is taken, the monitoring profile continues to monitor whether the target IP address is reachable. 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 might be applied before the firewall has enough information to determine the application. Therefore, application-specific rules aren’t 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 doesn’t have enough information to identify the application, and therefore can’t 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 isn’t an exact match and isn’t 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 can’t enforce a change in application identity. For example, YouTube 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 isn’t recognized thereafter.

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