Policy-Based Forwarding & Multi-VR — Override the FIB on Purpose

① Why PBF exists — when the FIB is "right" but wrong

Palo Alto's default behaviour: every packet hits a destination-based FIB lookup, takes the best route, exits the chosen interface. Clean. Predictable. But sometimes you need policy to override routing — say, you want all guest-WiFi → internet traffic forced over the cheap ISP2 link while corp-LAN → internet stays on the premium ISP1 link, even though both have a default route to 0.0.0.0/0.

That's PBF. A PBF rule matches on the same kind of attributes as a security rule — source zone, source/dest IP, application, user, service — and instead of "allow / deny" the action is forward via egress interface + next-hop. PBF is evaluated before the FIB lookup. If a PBF rule matches, the FIB is bypassed for that packet. If no PBF rule matches, the FIB takes over as usual.

② Watch a packet hit a PBF rule — and what happens next

Eight stages from ingress to egress, with the PBF rule applied. Press Play to see how the firewall sequences the lookups.

What can a PBF rule actually do?

③ Symmetric Return — when the FIB picks the wrong way home

Imagine an inbound web request lands on ISP2's public IP. The firewall accepts the session, hands it to the internal web server. The server replies — and PAN-OS does an FIB lookup for the reply's destination IP (the internet client). The FIB picks the default route, which usually points at ISP1. Reply goes out ISP1. Client sees a packet with a different source IP than the one it sent to. TCP drops it. Application breaks. Welcome to asymmetric routing.

Symmetric Return fixes this. Tick the flag on a PBF rule, and PAN-OS remembers — per session — the source MAC of the device that sent the first packet. When the reply leaves, PAN-OS ignores the FIB and ARP-resolves back to that same MAC. Reply takes the same path the original packet came in on. Symmetric. Stateful. Survives.

④ Multi-VR — when PBF starts to hurt and routing should take over

PBF is great for tactical overrides. But once your rule count grows, or you need full BGP per ISP, or your Symmetric Return tables fill up, the right answer is to stop fighting the FIB and split it: create a virtual router per ISP. Each VR has its own RIB, its own default route, its own BGP / OSPF process. You stitch them together with next-vr static routes.

Why multi-VR is the right answer for inbound dual-ISP

An inbound flow landing on ISP2 is routed by VR-ISP2's FIB (default-route via ISP2). When the server replies, the reply enters VR-Internal — but VR-Internal's only route back to the internet client is via next-vr VR-ISP2 (because the source IP of the original request was learned via VR-ISP2's interface, not VR-ISP1's). Routing does the symmetric-return work for free. No PBF rule. No return-mac table. No silent drops at scale.

# VR-Internal
set network virtual-router VR-Internal interface [ ethernet1/1 ethernet1/2 ]
set network virtual-router VR-Internal routing-table ip static-route Default \
    destination 0.0.0.0/0 nexthop next-vr VR-ISP1

# VR-ISP1
set network virtual-router VR-ISP1 interface [ ethernet1/4 ]
set network virtual-router VR-ISP1 routing-table ip static-route Default-ISP1 \
    destination 0.0.0.0/0 nexthop ip-address 203.0.113.1
set network virtual-router VR-ISP1 routing-table ip static-route Internal \
    destination 10.0.0.0/8 nexthop next-vr VR-Internal

# VR-ISP2 (symmetric to VR-ISP1)
set network virtual-router VR-ISP2 interface [ ethernet1/5 ]
set network virtual-router VR-ISP2 routing-table ip static-route Default-ISP2 \
    destination 0.0.0.0/0 nexthop ip-address 198.51.100.1
set network virtual-router VR-ISP2 routing-table ip static-route Internal \
    destination 10.0.0.0/8 nexthop next-vr VR-Internal

⑤ Two commands you'll actually run during a PBF incident

test pbf-policy-match from trust-lan to untrust-isp2 source 192.168.99.45 destination 8.8.8.8 application ssl protocol 6 destination-port 443

Guest-to-ISP2 {
    from         guest-wifi;
    source       any;
    destination  any;
    application  any;
    action       forward;
    nexthop      198.51.100.1;
    egress       ethernet1/3;
    monitor      4.2.2.2 (status: up);
}

show pbf return-mac all
show pbf rule all