[ScreenOS] Policy Based Routing (PBR) not working across multiple Virtual Routers (VR)

For cross-VR (virtual router) traffic, Policy-Based Routing (PBR) must be configured with all of the following:

The action-group must contain a next-hop value only. Do not enter a next-interface value.
Because the egress point for the PBR (this is on the ingress VR) is the next-hop VR, not a physical interface, the action-group entry should not specify an egress interface value, but only a next-hop address.

Note: There is an error in early ScreenOS 5.3/5.4 releases where, from the WebUI, it was not possible to configure the action-group entry without also specifying a next-interface value. Even if nothing is selected, the WebUI will write the Null interface entry to the configuration, which will cause matching traffic to be dropped. This error is fixed from ScreenOS 5.3.0r8 and 5.4.0r5 releases. However, if you are using one of those early versions, you can get around this by setting the action-group entry from the CLI (see below):

Compare the two commands:

Result from the WebUI in early 5.3/5.4 releases:
set action-group 1 next-interface null next-hop 1.2.3.4 action-entry 1 (this fails)

From the CLI, change it to be like the following:
set action-group 1 next-hop 1.2.3.4 action-entry 1 (this works)
A route for the next hop should be configured in the ingress VR pointing to egress VR.

A self-referenced host (/32) route must be added for the next-hop value. Regardless that the next-hop is reachable via the routing table or even directly connected, PBR still must have the /32 host route. This requirement seems strange as it works okay without it in a single-VR setup; however, for cross-VR traffic, PBR will fail without the host route to the next-hop address, even though a valid, less-specific route exists:
set vr <egress-vr> route <next-hop>/32 interface <interface name> gateway <next-hop>
Note: You must specify the same /32 next-hop value along with the gateway value. Without both, PBR will also fail.

Please note that it is highly recommended to specify the interface option when adding the route. Otherwise, the gateway tracking feature may be triggered and this may cause the route to be in an inactive state.

Output of command debug flow basic:
pbr setup : destination 8.8.8.8 dst-port 25
Without the /32 host route :
****** 09856.0: <PC/ethernet0/3> packet received [52]****** ipid = 17091(42c3), @05b42064 packet passed sanity check. flow_decap_vector IPv4 process ethernet0/3:10.20.30.5/53550->8.8.8.8/25,6<Root> no session found flow_first_sanity_check: in <ethernet0/3>, out <N/A> chose interface ethernet0/3 as incoming nat if. flow_first_routing: in <ethernet0/3>, out <N/A> search route to (ethernet0/3, 10.20.30.5->8.8.8.8) in vr trust-vr for vsd-0/flag-0/ifp-null PBR lookup params: dst-ip: 8.8.8.8, src-ip: 10.20.30.5, dst-port: 25, src-port: 53550, protocol: 6, dscp: 0 PBR: no route to (8.8.8.8) in vr trust-vr [ Dest] 11.route 8.8.8.8->9.9.9.1, to ethernet0/0 routed (x_dst_ip 8.8.8.8) from ethernet0/3 (ethernet0/3 in 0) to ethernet0/0 policy search from zone 100-> zone 2 policy_flow_search policy search nat_crt from zone 100-> zone 2 RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip 8.8.8.8, port 25, proto 6) No SW RPC rule match, search HW rule swrs_search_ip: policy matched id/idx/action = 320000/-1/0x0 Searching global policy. swrs_search_ip: policy matched id/idx/action = 320000/-1/0x0 policy id (320000) packet dropped, denied by policy
As you can observe, the route taken is a destination route even though the PBR has been configured.

With the /32 route :
****** 10006.0: <PC/ethernet0/3> packet received [52]****** ipid = 17176(4318), @05d8a864 packet passed sanity check. flow_decap_vector IPv4 process ethernet0/3:10.20.30.5/53556->8.8.8.8/25,6<Root> no session found flow_first_sanity_check: in <ethernet0/3>, out <N/A> chose interface ethernet0/3 as incoming nat if. flow_first_routing: in <ethernet0/3>, out <N/A> search route to (ethernet0/3, 10.20.30.5->8.8.8.8) in vr trust-vr for vsd-0/flag-0/ifp-null PBR lookup params: dst-ip: 8.8.8.8, src-ip: 10.20.30.5, dst-port: 25, src-port: 53556, protocol: 6, dscp: 0 [PBR route] 9.route 8.8.8.8->192.168.3.1, to ethernet0/1 routed (x_dst_ip 8.8.8.8) from ethernet0/3 (ethernet0/3 in 0) to ethernet0/1 policy search from zone 100-> zone 101 policy_flow_search policy search nat_crt from zone 100-> zone 101 RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip 8.8.8.8, port 25, proto 6) No SW RPC rule match, search HW rule swrs_search_ip: policy matched id/idx/action = 4/3/0x9 Permitted by policy 4 dip id = 2, 10.20.30.5/53556->192.168.3.8/1348 choose interface ethernet0/1 as outgoing phy if no loop on ifp ethernet0/1. session application type 7, name SMTP, nas_id 0, timeout 1800sec ALG vector is not attached service lookup identified service 0. flow_first_final_check: in <ethernet0/3>, out <ethernet0/1> existing vector list 103-cfe4d2c. Session (id:63950) created for first pak 103 flow_first_install_session======> route to 192.168.3.1 arp entry found for 192.168.3.1 ifp2 ethernet0/1, out_ifp ethernet0/1, flag 10800800, tunnel ffffffff, rc 1 outgoing wing prepared, ready handle cleartext reverse route search route to (ethernet0/1, 8.8.8.8->10.20.30.5) in vr trust-vr for vsd-0/flag-3000/ifp-ethernet0/3 [ Dest] 6.route 10.20.30.5->10.20.30.5, to ethernet0/3 route to 10.20.30.5 arp entry found for 10.20.30.5 ifp2 ethernet0/3, out_ifp ethernet0/3, flag 00800801, tunnel ffffffff, rc 1 flow got session. flow session id 63950 flow_main_body_vector in ifp ethernet0/3 out ifp ethernet0/1 flow vector index 0x103, vector addr 0xcfe4d2c, orig vector 0xcfe4d2c tcp seq check. Got syn, 10.20.30.5(53556)->8.8.8.8(25), nspflag 0x801801, 0x10800800 post addr xlation: 192.168.3.8->8.8.8.8. packet send out to 0014f6e8f889 through ethernet0/1
Now, with the /32 route, the PBR look-up is successful and packet has been forwarded.

Knowledge Base