This is a small example on how to configure policy based forwarding (PBF) on a Palo Alto Networks firewall. The use case was to route all user generated http and https traffic through a cheap ADSL connection while all other business traffic is routed as normal through the better SDSL connection. Since I ran into two problems with this simple scenario, I am showing the solutions here.
The covered PAN-OS version during this tests was 6.0.0.
The mere setup is really easy: The SDSL router is behind eth1/1 and a default route on the PA points to that router. The ADSL router resides behind eth1/2 and has NO static route entry in the router on the PA. No second virtual router or the like is needed. (This limits the usage of the second ISP connection. It can only be used for this policy based forwarding and not for incoming connections. E.g., no remote access VPN tunnels can terminate at this second connection since it has no default route to the router backwards. However, static Site-to-Site VPNs could be used if the remote endpoint has an entry in the routing table.)
The routing decision based on the destination ports 80 and 443 are made within the Policy Based Forwarding rules in the Policies tab. The following screenshots document my policy. Note that I have NOT selected the applications “web-browsing” and “ssl” but the mere ports, i.e., services. This is due to the fact that the PA cannot decide which application it sees based on the very first packet. Therefore, I simply forward all requests to the ports 80 and 443 to the ADSL connection:
The following screenshot shows that the same destination is called once with ping and once with http. According to the PBF, both connections take a different egress interface:
Do not PBF my Private Networks
My policy was a bit too wide: I was not able to reach my own http servers on the LAN anymore. 
Of course, the single PBF rule forwards all http requests to the ADSL router. The solution was to add a second PBF rule BEFORE the already existing one, which has the destination IP addresses set to all the internal IPv4 addresses (e.g., all RFC1918 addresses) and an action of “No PBF”.
IPv4 to the Left, IPv6 to the Right
Another problem in my scenario was IPv6 since I could not route my global unicast IPv6 space from the ISP with the SDSL connection through another ADSL connection. 
(Really bad, because IPv6 is the solution for so many other cases. Here it is a bit difficult. And yes, the hated NAT for IPv4 makes it easy to use PBF in this scenario.)
The solution was to configure another “no-pbf” rule that forwards all IPv6 packets to its normal default router which is of course capable of this global unicast IPv6 range.
Here is a screenshot of my final policy:
After that, all connections worked as expected. To show both links at the same time, a homepage that reveals both Internet protocol addresses such as the german www.wieistmeineip.de site can be used. Here, the IPv4 address from the dynamic ADSL connection as well as the global unicast IPv6 address (with privacy extensions enabled) are shown:
The egress interface can be seen in the traffic log. IPv4 connections are correctly forwarded to the ADSL router on eth1/2 while IPv6 traffic still goes out on eth1/1:
Reference
- Palo Alto: Policy Based Forwarding