Knowledge Search


×
 

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

  [KB9404] Show Article Properties


Summary:

Policy Based Routing (PBR) is not working across multiple Virtual Router (VR) configurations. This article provides the steps to correct the configuration.

Symptoms:

Policy Based Routing (PBR) is not working across multiple Virtual Router (VR) configurations.

Solution:

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

  1. 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)
  2. A route for the next hop should be configured in the ingress VR pointing to egress VR.

  3. 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:
  4. 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.




  5.  
  6.  
Modification History:
2017-12-26: Article reviewed for accuracy. No changes made. Article is correct and complete.
Related Links: