Policy-Based Forwarding (PBF) Overview

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.

Basic comparison of standard routing vs. PBF decision process.

PBF Concepts: 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 (meaning traffic arrives at and leaves from the same interface on which the session was created), you can enable the Symmetric Return option within the PBF rule.

With symmetric return enabled:

• The virtual router overrides a routing lookup for return traffic.
• It directs the flow back to the MAC address from which it received the SYN packet (or the first packet of the flow).
• The firewall uses an internal Address Resolution Protocol (ARP) table specifically for symmetric returns to determine the next hop MAC address.

admin@PA-NGFW> show pbf return-mac all

PBF Concepts: Path Monitoring

Path monitoring allows you to verify connectivity to a specific IP address (typically the next hop or a reliable target beyond it) 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 configure:

• The interval between heartbeats.
• The threshold (number of consecutive failed heartbeats) to determine if the IP address is unreachable.

When the monitored IP address becomes unreachable, you can configure one of the following actions in the PBF rule's monitoring settings:

• Disable PBF Rule: The PBF rule is temporarily disabled, allowing the virtual router's standard routing table to determine the path.
• Fail-over: The firewall uses the standard routing table immediately for *both new and existing sessions* affected by the rule.
• Wait-recover: The firewall uses the standard routing table for *new sessions* but attempts to keep *existing sessions* flowing through the original PBF path (which might fail).

When the fail-over or wait-recover action is taken, the monitoring profile continues to check if the target IP address becomes reachable again. If it does, the firewall automatically reverts back to using the original PBF rule path.

Flowchart illustrating Path Monitoring actions upon failure and recovery.

Behavior on Path Monitoring Failure

The following table summarizes the behavior for new vs. established sessions when a path monitoring failure occurs:

Understanding the difference between Fail-over and Wait-recover, especially regarding established sessions, is important for exam scenarios involving high availability and failover behavior.

PBF: Wait-Recover vs. Failover

Policy-Based Forwarding (PBF) allows network administrators to forward traffic based on specific policies (like source IP, destination IP, port, or application) rather than solely relying on the destination IP address in the routing table. When using PBF with multiple potential paths (e.g., different internet connections), mechanisms are needed to handle path failures and recoveries. Two key concepts related to this are Failover and Wait-Recover .

PBF Failover

Failover is the fundamental mechanism for high availability. In the context of PBF:

• Trigger: A monitored path (e.g., the primary path defined in a PBF rule) becomes unavailable, usually detected by a path monitoring probe (like ICMP pings or HTTP requests) failing repeatedly.
• Action: When the primary path fails, the PBF rule stops forwarding traffic via that path. Traffic matching the policy is then forwarded using the configured backup option. This could be:
  • The next PBF rule in sequence.
  • A specified backup interface or next-hop.
  • Falling back to the standard routing table lookup.
• Goal: To maintain connectivity by quickly switching traffic away from a failed path to a working alternative, minimizing disruption.

PBF Wait-Recover

Wait-Recover is a specific mechanism that controls how PBF handles the *restoration* of a previously failed path. It's often an option configured alongside path monitoring and failover.

• Trigger: A path that previously failed (triggering a failover) is now detected as available again by the path monitoring probe.
• Action: Instead of immediately switching traffic back to the newly recovered path, the system *waits* for a configured period (the "Wait-Recover" time). During this wait time, path monitoring continues.
  • If the path remains stable and available throughout the wait period, the system will then revert traffic back to this original path (if it's configured as the preferred path).
  • If the path becomes unavailable again *during* the wait period, the timer resets, and the system continues using the backup path. It won't attempt to revert until the path proves stable for the full duration.
• Goal: To ensure path stability before reverting traffic. This prevents "flapping" – rapidly switching back and forth between paths if the primary path is unstable (coming up and down frequently). It adds hysteresis to the recovery process.

Key Differences Summarized

• Focus: Failover focuses on *reacting to a failure* by moving traffic away. Wait-Recover focuses on *qualifying a recovery* before moving traffic back.
• Timing: Failover happens *immediately* (or after configured failure thresholds) upon path failure detection. Wait-Recover introduces a *delay* upon path recovery detection.
• Purpose: Failover ensures *continuity*. Wait-Recover ensures *stability* during restoration.
• Relationship: Wait-Recover is typically a feature *applied to the recovery phase* after a failover event has already occurred. You need failover first; wait-recover modifies how you *exit* the failed state.

Mermaid State Diagram

This diagram illustrates the state transitions for a PBF path with path monitoring, failover, and wait-recover enabled:

Note: To render the diagram, you need a library or tool that supports Mermaid syntax (like GitHub, GitLab, or various plugins/editors).

PBF Failover vs. Wait-Recover: The Driving Analogy

Imagine you have a special GPS rule (that's Policy-Based Forwarding or PBF) for your important work video calls: " Always use the super-fast Main Highway (ISP 1) for video calls! " You also have a slower, but reliable, Side Road (ISP 2) available.

1. Failover: Taking the Detour

Suddenly, there's a big traffic jam or accident! The Main Highway (ISP 1) is completely blocked.

• What Failover does: Your GPS (the network device) immediately sees the Highway is blocked. It instantly says, " Okay, can't use the Highway! Quick, take the Side Road (ISP 2) instead! "
• The Goal: Keep your video call going! Don't get stuck. Switch *away* from the broken road to a working one as fast as possible.

2. Wait-Recover: Checking Before Going Back

After a while, the accident on the Main Highway (ISP 1) is cleared, and the road reopens.

• What Wait-Recover does: Your GPS sees the Highway is open again. But instead of immediately telling you to go back, it thinks, " Hmm, let's wait 5 minutes just to be sure it's *really* clear and they won't close it again right away. "
• During the Wait: You *keep driving on the Side Road* (ISP 2).
• After the Wait:
  • If the Highway stays open and clear for the whole 5 minutes, *then* the GPS says, " Okay, looks stable now. Let's get back on the fast Highway! "
  • If the Highway gets blocked *again* during that 5-minute wait, the GPS says, " Nope, still not reliable. Stay on the Side Road. " The wait starts over next time it looks clear.
• The Goal: Stop you from getting annoyed by switching back and forth if the Main Highway keeps opening and closing randomly ("flapping"). Make sure the road is truly fixed and stable before you rely on it again.

So, What's the Difference in Simple Terms?

• Failover is about quickly switching AWAY from a broken path when it fails. (Handles the problem).
• Wait-Recover is about pausing and checking BEFORE SWITCHING BACK to the fixed path, to make sure the fix is stable. (Handles the recovery cautiously).

You need Failover to deal with the road blockage in the first place. Wait-Recover is like an extra safety check to make getting back on the main road smoother and less frustrating.

PBF Concepts: Service Versus Applications

PBF rules are evaluated based on the initial packets of a session (typically SYN or SYN/ACK). At this early stage, the firewall often does not have enough information to definitively identify the application (App-ID).

Therefore, using application objects in PBF rules is generally not recommended . Whenever possible, use a Service object (which defines Layer 4 TCP/UDP ports) as the matching criteria, as port information is available in the first packet.

App-ID Caching Behavior with PBF

If you *do* specify an application in a PBF rule, the firewall employs App-ID caching :

1. When the first session for a specific Destination IP/Port/Protocol arrives, the PBF rule might *not* match initially because the App-ID isn't known. The traffic follows the standard route table.
2. As more packets arrive, the firewall identifies the application and caches this App-ID associated with that Destination IP/Port/Protocol.
3. When a *new* session starts to the *same* Destination IP/Port/Protocol, the firewall might immediately use the cached App-ID from the previous session. If this cached App-ID matches the PBF rule, the PBF rule *will* be applied to this new session, even if this new session eventually turns out to be a different application. This can lead to incorrect forwarding.

Application Dependencies and Shifts

Furthermore, many modern applications have dependencies or shift their identity during a session. For example:

• YouTube might start as web-browsing (HTTP/HTTPS on port 80/443).
• Clicking a video could shift the App-ID to flash , rtsp , or youtube-base .

Because PBF makes its routing decision at the very beginning of the session based on limited information (or potentially a cached App-ID), it cannot react to these mid-session application shifts. The traffic will continue to follow the path determined by the initial PBF evaluation (or lack thereof).

Configuration: Create a Policy-Based Forwarding Rule

Use a Policy-Based Forwarding (PBF) rule to direct specific traffic to a designated egress interface, overriding the default routing table path.

Before creating a PBF rule, remember that IPv4 addresses are treated as a subset of IPv6 addresses in policy evaluation.

Steps to Create a PBF Rule:

1. Navigate and Add Rule:

   • Go to Policies > Policy Based Forwarding and click Add .

2. General Tab:

   • Enter a descriptive Name for the rule.

   

3. Source Tab:

   • Select the Type (Zone or Interface) the rule applies to and specify the source zone(s) or interface(s). You must select a source interface if you intend to use Symmetric Return.
   • Note: Only Layer 3 interfaces support PBF. Loopback interfaces do not.
   • (Optional) Specify Source Address (es) (IP, Address Object, FQDN). Use Negate to exclude specific source IPs/subnets.
   • (Optional) Add Source User (s) or groups.

4. Destination/Application/Service Tab:

   • Specify Destination Address (es). Default is 'Any'. Use Negate to exclude destinations.
   • (Optional, Not Recommended) Add specific Application (s).
   • (Optional, Recommended) Add Service (s) (e.g., service-http, service-https, or custom service objects).

   As discussed previously, avoid using Applications if possible due to identification timing and caching issues. Use Service objects based on L4 ports instead.

5. Forwarding Tab:

   • Select the Action :
     • Forward: Directs matching packets to a specified Egress Interface.
     • Forward to VSYS: (Multi-VSYS environments) Sends packets to another virtual system.
     • Discard: Drops matching packets.
     • No PBF: Excludes matching packets from PBF evaluation; these packets will use the standard route table. Useful for creating exceptions.
   • (Optional) Attach a Schedule to apply the rule only during specific times.
   • Select the Egress Interface for the 'Forward' action.
   • Configure the Next Hop :
     • IP Address: Enter the IP address of the next router (must be /32 for IPv4, /128 for IPv6, or use an Address Object).
     • FQDN: Enter a Fully Qualified Domain Name that resolves to the next hop IP. The FQDN must resolve to an IP on the same subnet as the PBF egress interface. The firewall typically uses the first IP returned by DNS for each address family (IPv4/IPv6).
     • None: Uses the packet's destination IP as the next hop. Only works if the destination is directly connected (on the same subnet) as the egress interface.
   • (Optional) Enable Monitor :
     • Attach a monitoring Profile (default or custom).
     • Specify the IP Address to monitor (usually the next hop, but can be another target). If left blank, monitors the configured Next Hop IP.
     • Optionally check Disable this rule if nexthop/monitor ip is unreachable (alternative to profile actions Fail-over/Wait-recover).
   • (Optional, but Required for Asymmetric Routing) Enable Enforce Symmetric Return :
     • Crucially, you MUST Add one or more specific IP addresses in the Next Hop Address List when using Symmetric Return. Failure to do so can exhaust the symmetric return ARP table (see Troubleshooting section).

6. Commit Changes:

   • Click OK to save the rule, then Commit the configuration to the firewall.

Understanding each option in the PBF rule configuration, especially Action types, Next Hop settings, Monitoring, and Symmetric Return (including its requirement for a Next Hop Address List entry), is vital for configuration and troubleshooting.

Use Case: PBF for Outbound Access with Dual ISPs

This scenario demonstrates using PBF for redundant internet access in a branch office with two ISP connections, without relying on dynamic routing protocols like BGP.

Goal: Use ISP1 as the primary path for most outbound traffic. Use ISP2 as the backup, automatically failing over if ISP1 becomes unavailable.

Configuration Summary:

1. Interfaces: Configure interfaces for LAN, ISP1, and ISP2, placing ISP interfaces in appropriate zones (can be the same zone).
2. Static Route (Backup): Add a default static route (0.0.0.0/0) in the virtual router pointing to the backup ISP's gateway (ISP2). This route will be used if no PBF rule matches or the primary PBF rule fails.
3. PBF Rule (Primary):
   • Match traffic originating from the LAN zone.
   • Optionally, match specific services (like HTTP/HTTPS) or use 'Any' for all traffic.
   • Optionally, use 'Negate' on Destination Address to exclude traffic destined for internal networks.
   • Action: Forward
   • Egress Interface: Interface connected to ISP1.
   • Next Hop: IP address of the ISP1 gateway router.
   • Monitor: Enable monitoring , targeting the ISP1 gateway (or another reliable IP via ISP1). Use a profile with 'Fail-over' or 'Disable Rule' action on failure.
   • (Optional but recommended for asymmetry) Enforce Symmetric Return (with ISP1 gateway added to Next Hop Address List).
4. Source NAT Rules: Create two Source NAT rules:
   • Rule 1: Translates traffic from LAN zone going to ISP1 zone (egress interface ISP1) using the ISP1 interface IP address.
   • Rule 2: Translates traffic from LAN zone going to ISP2 zone (egress interface ISP2) using the ISP2 interface IP address.
   • These ensure the correct source IP is used depending on which path (primary PBF or backup static route) the traffic takes.
5. Security Policy: Create a Security Policy rule allowing traffic from the LAN zone to the ISP zone(s).

Simplified traffic flow for Dual ISP PBF during normal operation and ISP1 failure.

Verification Steps:

• Check traffic logs ( Monitor > Logs > Traffic ) to see sessions flowing through the ISP1 interface initially.
• Use show pbf rule all to confirm the PBF rule is active.
• Simulate ISP1 failure (e.g., disconnect cable, shut down ISP1 router port).
• Use show pbf rule all again; the rule state should change (e.g., 'Disabled' if monitoring action is set to disable).
• Check traffic logs again; new sessions should now egress via the ISP2 interface.
• Use show session id <session_id> to verify the egress interface and the correct NAT rule (ISP2 NAT rule) is being applied.

This Dual ISP configuration using PBF, static routes, monitoring, and interface-based NAT is a common and important scenario to understand for network redundancy.

Use Case: PBF with GlobalProtect and Dual ISPs

This use case builds upon the Dual ISP scenario but adds GlobalProtect VPN, dedicating one ISP link specifically for VPN traffic while the other handles regular internet traffic.

Goal: Route all regular LAN outbound traffic via ISP1 (primary). Route all traffic originating from connected GlobalProtect VPN clients via ISP2.

Configuration Adjustments from Dual ISP Use Case:

1. Interfaces: In addition to LAN, ISP1, ISP2 interfaces, configure a Tunnel interface (e.g., `tunnel.1`) and assign it to a dedicated VPN zone (e.g., 'Zone VPN').
2. GlobalProtect Setup: Configure GlobalProtect Portal and Gateway.
   • The Gateway will typically listen on an interface connected to the internet (could be ISP1 or ISP2, often the one *not* used for VPN egress if dedicated).
   • Assign an IP pool for VPN clients (e.g., 172.16.1.0/24).
   • Associate the Gateway with the configured Tunnel interface (`tunnel.1`).
   • Configure client settings to push routes (e.g., push 0.0.0.0/0 to force all client traffic through the tunnel).
3. Static Route (Primary): Keep the default static route pointing to ISP1 for general LAN traffic.
4. PBF Rule (GlobalProtect Traffic): Create a *new* PBF rule:
   • Source Type: Interface
   • Source Interface: Select the Tunnel interface (`tunnel.1`).
   • Source Address: The IP pool assigned to VPN clients (e.g., 172.16.1.0/24). Or use 'Any' if only VPN client traffic hits the tunnel interface.
   • Destination Address: Typically 'Any', but you might use 'Negate' to exclude destinations reachable via ISP1 or the LAN if split-tunneling were used (though this example uses full tunnel).
   • Action: Forward
   • Egress Interface: Interface connected to ISP2.
   • Next Hop: IP address of the ISP2 gateway router.
   • Monitor: Optional, but recommended for the ISP2 path if redundancy is needed for VPN traffic itself.
   • Symmetric Return: Generally not needed here if NAT handles return path correctly, but consider if ISP2 path has asymmetry issues.
5. NAT Rules: Keep the NAT rules from the Dual ISP case. Traffic egressing ISP1 (LAN default) uses ISP1 NAT. Traffic egressing ISP2 (VPN via PBF) uses ISP2 NAT.
6. Security Policy: Ensure Security Policy rules allow traffic:
   • From LAN zone to ISP1 zone.
   • From VPN zone to ISP2 zone.
   • From the zone where the GP Gateway listens (e.g., ISP1 or ISP2 zone) to the firewall itself (for GP connections).

Traffic Flow Summary:

• LAN Client to Internet: Matches no PBF rule (or maybe a default rule pointing to ISP1), uses static default route -> ISP1. NAT via ISP1 IP.
• VPN Client to Internet: Traffic enters `tunnel.1` (VPN Zone). Matches the PBF rule for source `tunnel.1` -> Forwarded via ISP2 interface. NAT via ISP2 IP.

Traffic flow distinguishing LAN vs. GlobalProtect VPN traffic using PBF.

This configuration effectively segregates VPN traffic onto a dedicated ISP link using PBF based on the source tunnel interface, overriding the default route used by regular LAN traffic.

Troubleshooting: Symmetric Return Issues

Connectivity problems can arise when using PBF with Symmetric Return enabled, often due to misconfiguration or resource limits.

Symptom: Forwarding Fails for Specific Traffic

Traffic matching a PBF rule with "Enforce Symmetric Return" enabled fails, while other traffic works.

Diagnosis: Check the Symmetric Return MAC Table

The most common cause is exhausting the firewall's symmetric return MAC address table. This happens frequently if Symmetric Return is enabled *without* specifying any IP addresses in the "Next Hop Address List" within the PBF rule's Forwarding tab.

Use the following CLI command to check the table status:

admin@firewall> show pbf return-mac all

Look for these lines in the output:

• maximum of ipv4 return mac entries supported : <max_limit> (This limit varies by firewall model)
• total ipv4 return mac entries in table : <current_count>

If the `total ipv4 return mac entries in table` equals the `maximum ... supported` limit, the table is full, and new symmetric return sessions cannot be established.

Resolution: Configure Next Hop Address List

To resolve this, edit the PBF rule(s) where "Enforce Symmetric Return" is enabled:

1. Go to Policies > Policy Based Forwarding .
2. Edit the relevant PBF rule.
3. Go to the Forwarding tab.
4. Under the "Enforce Symmetric Return" section, click Add in the Next Hop Address List .
5. Enter the IP address(es) of the actual next-hop router(s) reachable via the PBF Egress Interface. You can add up to 8 addresses.
6. Click OK and Commit the changes.

By specifying the valid next-hop router IP(s), the firewall only needs to learn and store the MAC address(es) for those specific IPs in the symmetric return table, preventing it from filling up unnecessarily with MACs of numerous hosts beyond the next hop.

Troubleshooting: Application-Based PBF Issues

Using applications as matching criteria in PBF rules can lead to unexpected behavior due to how and when PBF rules and App-ID are evaluated.

Symptom: PBF Rule Based on Application Doesn't Match Consistently or Matches Incorrectly

You configure a PBF rule to forward, discard, or route specific application traffic (e.g., forward 'youtube-base' via a specific ISP), but the rule doesn't seem to apply, or it applies to traffic that isn't actually that application.

Diagnosis: Understand the Limitations

1. Timing Issue: PBF rules are evaluated on the first packets (SYN/SYN-ACK). App-ID often requires more packets to identify the application accurately. The PBF decision might be made *before* the application is known, causing the rule to be skipped initially.
2. App-ID Caching: Once an application is identified for a flow (Destination IP/Port/Protocol), the firewall caches this App-ID. Subsequent *new* sessions to the *same* Destination IP/Port/Protocol might immediately use the cached App-ID for the PBF lookup. If the cached App-ID matches the PBF rule, the rule will apply, even if the new session is actually a different application that just happens to use the same destination/port.
3. Application Shifts: Many applications change identity mid-session (e.g., web-browsing -> youtube-base). PBF makes its decision at the start and cannot react to these mid-session shifts.
4. Unsupported Objects: Custom applications, Application Filters, and Application Groups cannot be used in PBF rules. Only pre-defined applications are selectable (and even those are not recommended).

Resolution / Best Practice

• Prioritize Service Objects: Whenever possible, base PBF rules on Service objects (TCP/UDP ports) instead of Application objects. Port information is available in the initial packets, leading to more predictable PBF behavior.
• Use 'No PBF' for Exceptions: If you need specific traffic (identifiable by source/destination/service) to *not* use a broader PBF rule, create a more specific rule matching that traffic with the action set to No PBF . Place this exception rule *before* the broader PBF rule.
• Accept Limitations: If you absolutely must use an application object, understand the caching and timing limitations. The PBF rule might not catch the very first session, and it might misclassify subsequent sessions based on the cache. It will also not adapt to mid-session App-ID changes.

Interactive Quiz: Policy-Based Forwarding

Test your understanding of the key PBF concepts covered.