Skip to main content

Policy Based Routing on a Cisco ASA


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 am trying 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:

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).

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:)
Cisco ASA PBR 09 trying to delete a route map statement

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:)

Comments

Post a Comment

Popular posts from this blog

Cisco SG300 CLI Commands

Cisco SG300 CLI Commands Other parts were obtained using the CLI PDF provided by Cisco Remove a Trunk and switch to access config t int gi44 switchport trunk allowed vlan remove 2 switchport mode access switchport access vlan 2 or config t int gi44 switchport mode general switchport general allowed vlan remove 2 switchport mode access switchport access vlan 2 Change CDP Device ID Format to Hostname opposed to default MAC address s-sg300#sh cdp Global CDP information:         CDP is globally enabled         CDP log duplex mismatch is globally enabled         CDP log voice VLAN mismatch is globally enabled         CDP log native VLAN mismatch is globally enabled         Mandatory TLVs validation is disabled         Sending CDPv2 advertisements is enabled         Sending Appliance TLV is enabled       ...
Post a Comment
Read more

Branches, Part II

Now that we’ve covered the mechanics behind Git branches, we can discuss the practical impact that they have on the software development process. Instead of introducing new commands, this module covers how the typical Git user applies this workflow to real projects, as well as some of the problems that arise in a branched environment. To Git, a branch is a branch, but it’s often useful to assign special meaning to different branches. For example, we’ve been using master as the stable branch for our example project, and we’ve also used a temporary branch to add some CSS formatting. Temporary branches like the latter are called topic branches because they exist to develop a certain topic, then they are deleted. We’ll work with two types of topic branches later in this module. Amid our exploration of Git branches, we’ll also discover that some merges cannot be “fast-forwarded.” When the history of two branches diverges, a dedicated commit is required to combine the branches. This ...
Post a Comment
Read more

Distributed Workflows

Now that we know how to share information via a centralized workflow, we can appreciate some of the drawbacks of this collaboration model. While it may be convenient, allowing everyone to push to an “official” repository raises some legitimate security concerns. It means that for anyone to contribute content, they need access to the entire project. This is fine if you’re only interacting with a small team, but imagine a scenario where you’re working on an open-source software project and a stranger found a bug, fixed it, and wants to incorporate the update into the main project. You probably don’t want to give them push-access to your central repository, since they could start pushing all sorts of random snapshots, and you would effectively lose control of the project. But, what you can do is tell the contributor to push the changes to their own public repository. Then, you can pull their bug fix into your private repository to ensure it doesn’t contain any undeclared code. If y...
Post a Comment
Read more