Cisco ASA 9.4 (and later) is now supporting Policy Based Routing. Yeah. Great news, since many customers are requesting something like “HTTP traffic to the left – VoIP traffic to the right”. Coming with a new Cisco ASA 5506-X I was happy to try the policy based routing feature.
The configuration steps through the ASDM GUI are not easy and full of errors, so I try to give some hints within this blog post.
The main document from Cisco for policy based routing on a ASA is here. It describes the use-cases for PBR and gives examples.
Configuration
I am doing all of my configurations through the GUI ASDM. (I know, some people really love the CLI even for configurations, but I don’t. I am using it only for troubleshooting issues.) For this lab I am using a Cisco ASA 5506-X with ASA version 9.5(1), while ASDM is version 7.5(1). In my lab, I have a default route to ISP 1 (gi1/1) and a different connection to ISP 2 (gi1/2). There is no route to ISP 2 in the routing table. I want that each user generated http/https traffic is routed to ISP 2, while anything else is still traversing through ISP 1 to the Internet.
To configure PBR, an ACL that matches the traffic must be defined, then referenced in a route map with the “set ip next-hop” statement, and this route map must be applied to the incoming interface. I ran into many error messages through the configuration, e.g., a false warning message stating “will not have any effect”. Here is my path: (And as always: Note the descriptions under the screenshots for more details.)
The complete CLI commands for my test scenario are the following:
interface GigabitEthernet1/3 policy-route route-map map-pbr ! access-list aclex-pbr extended permit tcp any any eq www access-list aclex-pbr extended permit tcp any any eq https ! route-map map-pbr permit 10 match ip address aclex-pbr set ip next-hop 10.49.254.1
Test
The following debug output on the CLI reveals the PBR process. The DNS request (line 2) has no match -> skip to normal route (line 3). The HTTP traffic (line 4) is matched and processed to the next-hop (lines 5-8).
ASA5506-X# debug policy-route pbr: policy based route lookup called for 192.168.170.10/59848 to 8.8.8.8/53 proto 17 sub_proto 0 received on interface inside pbr: no route policy found; skip to normal route lookup pbr: policy based route lookup called for 192.168.170.10/2755 to 80.237.133.136/80 proto 6 sub_proto 0 received on interface inside pbr: First matching rule from ACL(4) pbr: route map map-pbr, sequence 10, permit; proceed with policy routing pbr: evaluating next-hop 10.49.254.1 pbr: policy based routing applied; egress_ifc = outside2 : next_hop = 10.49.254.1 pbr: policy based route lookup called for 192.168.170.10/2756 to 80.237.133.136/80 proto 6 sub_proto 0 received on interface inside pbr: First matching rule from ACL(4) pbr: route map map-pbr, sequence 10, permit; proceed with policy routing pbr: evaluating next-hop 10.49.254.1 pbr: policy based routing applied; egress_ifc = outside2 : next_hop = 10.49.254.1
How to “Not PBR”?
An unsolved problem for me is the “do not pbr” policy which is needed to not forward traffic to inside private IP addresses (RFC1918) to the second ISP, but due to the normal routing table. I tried the following configurations, but none of them worked: (Maybe someone has an idea?)
- Route-map statement “deny” referencing an ACL that lists the private networks: There was only the following warning in the CLI: “WARNING: Route-map map-pbr with sequence number 10 does not have any set actions defined. Not installing PBR datapath rules for this route-map entry”. But the private IP ranges are still policy-routed to the second ISP.
- Same route-map with the ACL that denies the private networks while permitting “any” with port http/https: Does not work either.
- Route-map statement “permit” referencing an ACL that lists the private networks with “Set Null0 interface as the default interface”: Not working.
- Route-map statement “permit” referencing an ACL that lists the private networks with any kind of “next-hop” address: Would not make sense since I have many different routes in the routing table. Furthermore, some private networks are connected via VPNs, which are not route-based VPNs but policy-based VPNs. I do not know how these two policy features (policy-routing and policy-based VPN) do merge.
(By the way: It is not possible to delete a certain route map statement through ASDM. Through the CLI, this is no problem. For example, if I want to deleted sequence number 5, the following error message appears:)
Conclusion
I don’t know if I should be happy or not. Ok, in general, PBR is working on the ASA, but the configuration process is not intuitive. If a customer already has a new ASA 5500-X, then he might be happy to have PBR now. However, the policy based routing configurations on other firewall vendors such as Palo Alto or Fortinet are much better.
(And by the way: The example configuration commands on the Cisco page are not correct at some points, e.g. this one:)
Then, we need to configure an access-list for matching the traffic. (config)# access-list acl-1 permit ip 10.1.0.0 255.255.0.0 (config)# access-list acl-2 permit ip 10.2.0.0 255.255.0.0 ASA5506-X(config)# access-list acl-1 permit ip 10.1.0.0 255.255.0.0 ERROR: % Incomplete command