Configuring Policy Based Routing on Cisco ASA
Overview
Normally when a routing device receives a packet it decides where to forward it based on the destination address of the packet. Policy Based Routing (PBR) is a mechanism which allows you forward packets based on policies manually defined by network administrators. A good use case for PBR is when a company which has multiple outside connections to different ISPs needs to control how traffic can be distributed across these connections. Compared to traditional routing PBR allows you to implement routing policies based on different criterias like source or destination address, source or destination port, protocol, size of the packet, packet classification and so on. Cisco introduced this feature on Cisco ASA beginning with version 9.4(1). Let’s dive into the PBR configuration.
PBR configuration
In order to proceed with the PBR configuration the ASA firewall needs to be setup in routed mode which is the default. Transparent firewall mode is not supported. The PBR configuration on Cisco ASA is done similarly as on Cisco IOS through the use of route-maps which are applied to an interface. For the purpose of the demonstration we will use the topology below.
Before starting the configuration let’s explain our scenario setup. We have 2 internal networks 10.10.100.0/24 (vlan 100) and 10.10.101.0/24 (vlan 101). We want that traffic from vlan 100 to go through ISP1 and traffic from vlan 101 to go through ISP2. Since both networks are internal we need to setup NAT in order to allow them outbound communication. I have added an external host (44.44.44.10) which will be used for testing that PBR works correctly. The IP addressing on the devices has been setup according to the diagram and the routing between ASA-FW, ISP1, ISP2 and INTERNET has been done using OSPF. In order to simplify things I have enabled OSPF on each of the layer 3 devices using the following command:
ASA-FW(config)# router ospf 100
ASA-FW(config-router)# network 0.0.0.0 255.255.255.255 area 0
Now that the OSPF adjacency has been setup let’s proceed and configure the IP addresses on the inside interfaces. We have two internal networks and we need to create two subinterfaces on the ASA to allow outbound connectivity. I’ll assume we have 2 departments in our inside network so I’ll name them Engineering for vlan 100 and Accounting for vlan 101.
ASA-FW(config)# interface Gi0/0.100
ASA-FW(config-if)# vlan 100
ASA-FW(config-if)# nameif Engineering
ASA-FW(config-if)# security-level 100
ASA-FW(config-if)# ip address 10.10.100.1 255.255.255.0
ASA-FW(config)# interface Gi0/0.101
ASA-FW(config-if)# vlan 101
ASA-FW(config-if)# nameif Accounting
ASA-FW(config-if)# security-level 100
ASA-FW(config-if)# ip address 10.10.101.1 255.255.255.0
Don’t forget to enable the physical interface Gi0/0 on the ASA by issuing a no shutdown command under the interface configuration mode. These 2 subinterfaces will be used as gateways for our 2 internal networks. The outside interfaces on the ASA firewall are named ISP1 and ISP2 and have the following configuration.
ASA-FW(config)# interface Gi0/1
ASA-FW(config-if)# nameif ISP1
ASA-FW(config-if)# security-level 0
ASA-FW(config-if)# ip address 1.1.1.2 255.255.255.0
ASA-FW(config)# interface Gi0/2
ASA-FW(config-if)# nameif ISP2
ASA-FW(config-if)# security-level 0
ASA-FW(config-if)# ip address 2.2.2.2 255.255.255.0
Let’s setup NAT and define the required network objects for translation.
ASA-FW(config)# object network Engineering
ASA-FW(config-network-object)# subnet 10.10.100.0 255.255.255.0
ASA-FW(config-network-object)# nat (Engineering,ISP1) dynamic interface
ASA-FW(config)# object network Accounting
ASA-FW(config-network-object)# subnet 10.10.101.0 255.255.255.0
ASA-FW(config-network-object)# nat (Accounting,ISP2) dynamic interface
The gateway of last resort on the ASA is set to 1.1.1.1 ip address which points to router ISP1.
ASA-FW(config)# route ISP1 0.0.0.0 0.0.0.0 1.1.1.1
Without any routing policy configured traffic from both Engineering and Accounting networks will go through the default gateway ISP1. As we stated before we want traffic from network 10.10.101.0/24 to be routed through ISP2. First we need to define 2 ACLs which will be used to match traffic coming from both internal networks and going to any destination. In my example I named them LAN1-ACL and LAN2-ACL.
ASA-FW(config)# access-list LAN1-ACL extended permit ip 10.10.100.0 255.255.255.0 any
ASA-FW(config)# access-list LAN2-ACL extended permit ip 10.10.101.0 255.255.255.0 any
Next we need to create a route map entry called PBR which will match traffic permitted by the 2 previous ACLs.
ASA-FW(config)# route-map PBR permit 10
ASA-FW(config-route-map)# match ip address LAN1-ACL
ASA-FW(config-route-map)# set ip next-hop 1.1.1.1
ASA-FW(config)# route-map PBR permit 20
ASA-FW(config-route-map)# match ip address LAN2-ACL
ASA-FW(config-route-map)# set ip next-hop 2.2.2.1
In our case the first route-map statement with sequence number 10 is not really needed since by default traffic from Engineering network will follow the normal route lookup process and be forwarded to the default gateway, but for the sake of completness I have added that here. The set ip next-hop command tells the ASA to forward the traffic using this specified next-hop IP address if normal route lookup fails for matching traffic. Here we told that traffic that is matched by the LAN2-ACL should be forwarded to the 2.2.2.1 next-hop. Lastly we need to apply this policy to an interface using the policy-route route-map command.
ASA-FW(config)# interface Gi0/0.100
ASA-FW(config-if)# policy-route route-map PBR
ASA-FW(config)# interface Gi0/0.101
ASA-FW(config-if)# policy-route route-map PBR
We can check that the policy was applied to the correct interfaces by using the show policy-route command.
ASA-FW# show policy-route Interface Route map GigabitEthernet0/0.100 PBR GigabitEthernet0/0.101 PBR
PBR testing and troubleshooting
Now that the policy has been configured let’s test if the configuration works properly. We can use the traceroute command from PC1 and PC2 and try to reach the external host REMOTE-PC.
PC1> tracert -d 44.44.44.10 Tracing route to 44.44.44.10 over a maximum of 30 hops 1 2ms 2ms 1ms 10.10.100.1 2 1ms 1ms 1ms 1.1.1.1 3 2ms 1ms 1ms 99.99.99.1 4 2ms 2ms 2ms 44.44.44.10
As we can see the traceroute from the Engineering vlan to 44.44.44.10 address is following the default path through router ISP1. Let’s run the same traceroute command from PC2 to see if the routing policy is in effect.
PC2> tracert -d 44.44.44.10 Tracing route to 44.44.44.10 over a maximum of 30 hops 1 1ms 1ms 1ms 10.10.101.1 2 1ms 1ms 1ms 2.2.2.1 3 2ms 2ms 1ms 123.123.123.1 4 2ms 1ms 1ms 44.44.44.10
By looking at the above output we observe that traceroute takes the secondary path through router ISP2 which means the routing policy is working properly. If we need to troubleshoot the policy based routing process we can use the debug policy-route command.
ASA-FW# debug policy-route
debug policy-route enabled at level 1
ASA-FW# pbr: policy based route lookup called for 10.10.101.10/19460 to 44.44.44.10/0 proto 1 sub_proto 8 received on interface Accounting
pbr: First matching rule from ACL(2)
pbr: route map PBR, sequence 20, permit; proceed with policy routing
pbr: evaluating next-hop 2.2.2.1
pbr: policy based routing applied; egress_ifc = ISP2 : next_hop = 2.2.2.1
From the debug output we can see that the second route-map from the PBR was matched and the action was to route traffic according to the policy through the next-hop ip address 2.2.2.1
Summary
In this article we have discussed the basics of policy based routing. Although PBR is very useful it should be used with caution because if used improperly it can cause asymmetric routing in your environment.
