12-10-2015 02:33 AM - edited 03-12-2019 12:01 AM
I have a 5525-X running 9.4.2 in multi context mode. In a test context I am configuring PBR - the topology is as follows -
The main routed path is learned via eBGP but I am selecting some Ingress traffic based on its source and pushing it to the PBR path via setting the next-hop.
Connections inbound Outside->Inside work, are policy routed correctly, which is verified by packet-tracer -
PBR-FW/TEST/pri/act# packet-tracer input TEST tcp 1.1.1.14 19100 8.8.8.2 5001
Phase: 1
Type: PBR-LOOKUP
Subtype: policy-route
Result: ALLOW
Config:
route-map TEST_PBR permit 10
match ip address BAHRAINx
set ip next-hop 192.168.8.1
set interface TEST_SITEA
Additional Information:
Matched route-map TEST_PBR, sequence 10, permit
Found next-hop 192.168.8.1 using egress ifc TEST_SITEA
Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group VF-Peering-V10-IN in interface TEST
access-list VF-Peering-V10-IN extended permit tcp any any eq 5001
Additional Information:
pbr: policy based route lookup called for 1.1.1.14/19100 to 8.8.8.2/5001 proto 6 sub_proto 0 received on interface TEST
pbr: First matching rule from ACL(3)
pbr: route map TEST_PBR, sequence 10, permit; proceed with policy routing
pbr: evaluating next-hop 192.168.8.1
pbr: policy based routing applied; egress_ifc = TEST_SITEA : next_hop = 192.168.8.1
Phase: 3
Type: NAT
Egress connections from the Inside->Outside between the same two endpoints fails. TCP as well as pings fail. So testing with ICMP for simplicity -
Dec 10 2015 09:45:21: %ASA-6-302020: Built outbound ICMP connection for faddr 1.1.1.14/0 gaddr 8.8.8.2/13974 laddr 8.8.8.2/13974
Dec 10 2015 09:45:21: %ASA-6-110003: Routing failed to locate next hop for ICMP from TEST:1.1.1.14/0 to TEST_SITEA:8.8.8.2/13974
Dec 10 2015 09:45:21: %ASA-6-302021: Teardown ICMP connection for faddr 1.1.1.14/0 gaddr 8.8.8.2/13974 laddr 8.8.8.2/13974
However packet-tracer says -
PBR-FW/TEST/pri/act# packet-tracer input TEST icmp 1.1.1.14 0 0 8.8.8.2
Phase: 1
Type: PBR-LOOKUP
Subtype: policy-route
Result: ALLOW
Config:
route-map TEST_PBR permit 10
match ip address BAHRAINx
set ip next-hop 192.168.8.1
set interface TEST_SITEA
Additional Information:
Matched route-map TEST_PBR, sequence 10, permit
Found next-hop 192.168.8.1 using egress ifc TEST_SITEA
pbr: policy based route lookup called for 1.1.1.14/0 to 8.8.8.2/0 proto 1 sub_proto 0 received on interface TEST
pbr: First matching rule from ACL(3)
pbr: route map TEST_PBR, sequence 10, permit; proceed with policy routing
pbr: evaluating next-hop 192.168.8.1
pbr: policy based routing applied; egress_ifc = TEST_SITEA : next_hop = 192.168.8.1
Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group VF-Peering-V10-IN in interface TEST
access-list VF-Peering-V10-IN extended permit icmp any any
Additional Information:
Phase: 3
So the firewall appears to be dropping the ingress ICMP echo-replies because it can't find a route to the destination network on the interface to which PBR has sent it, even though PBR has provided it with a next hop already.
The whole point of PBR is that the route table DOES NOT have a route to the destination network via the next-hop that we are manually pushing the traffic to.
Packet tracer believes the packets should be forwarded.
Suggestions?
--------------------------------------
Update
A usable workaround is to place the PBR exit interfaces into a zone. The zone based interfaces are allowed up to 8 ECMP routes, so you can place a static summary route to your destination network via each zone member, leaving your more specific learned route to provide the primary routed path. The next hop will be correctly provided by PBR while the summary ECMP routes allow the destination check to complete.