ASA Application-Based Routing

  • Post author:
  • Post category:ASA / Cisco

ASA Application-Based Routing

The Cisco Secure Firewall ASA supports application-based routing using Policy-based routing  (PBR) and DNS snooping. DNS snooping identifies the domain name based on the IP address learnt from the DNS response of DNS traffic passing through the firewall. With the IP address the ASA can match an IP address to a domain specified in a network-service object, this object is used in an Access Control List as criteria to route traffic using Policy-Based routing.

This post covers the simple scenario of a network with 2 ISP connections, requiring priority traffic to be routed over a separate ISP connection.

  • The default route for all internet traffic will be via ISP-1.
  • Priority traffic will be matched and routed via ISP-2 and if ISP-2 connection fails, internet traffic will failover to ISP-1.

Configuration

The following configuration was validated using Cisco Secure Firewall ASA version 9.20.2.

Objects

Objects are used to identify the domains to be matched for routing via PBR.

object network-service "Search-Engines"
 domain www.yahoo.com ip
 domain www.google.com ip
 domain www.google.co.uk ip
!
object network-service "Microsoft"
 domain outlook.com ip
 domain office.com ip
 domain office365.com ip
 domain teams.microsoft.com ip
 domain live.com ip

The objects are referenced in a network-service object-group.

object-group network-service PRIORITY-APPS
 network-service-member "Microsoft"
 network-service-member "Search-Engines"

Enable DNS Snooping

The ASA must snoop the DNS traffic to determine the IP address of the domain name.

DNS domain lookups are enabled.

dns domain-lookup ISP-1
dns domain-lookup ISP-2

Optionally, a trusted DNS server source is specified, this prevents DNS spoofing.

dns trusted-source 8.8.8.8

Configure OUTSIDE interfaces

The ISP interfaces are configured as standard with an IP address, security level and nameif. For Policy Based routing ISP-1 interface is configured with a higher (less preferable) policy-route cost of 2 and ISP-2 interface with a lower cost of 1, this provides an Active/Backup configuration.

interface GigabitEthernet0/0
 nameif ISP-1
 security-level 0
 ip address 192.168.10.100 255.255.255.0 
 policy-route cost 2
!
interface GigabitEthernet0/1
 nameif ISP-2
 security-level 0
 ip address 192.168.101.100 255.255.255.0 
 policy-route cost 1

Network Address Translation

As standard, NAT will be required to translate internal networks behind the outside interfaces.

object network LAN
 subnet 10.10.0.0 255.255.252.0
!
object network LAN-VIA-ISP1
 subnet 10.10.0.0 255.255.252.0
 nat (INSIDE,ISP-1) dynamic interface
!
object network LAN-VIA-ISP2
 subnet 10.10.0.0 255.255.252.0 
 nat (INSIDE,ISP-2) dynamic interface

Access Control List

An Access Control List is used to match policy-based routing traffic, to be later referenced in the route-map. In this example, traffic is matched from LAN network (10.10.0.0/22) to the domains in the group PRIORITY-APPS.

access-list PBR-ACL extended permit ip object LAN object-group-network-service PRIORITY-APPS

Route Map

The route-map matches the address in the PBR-ACL and sets an adaptive cost to direct traffic to the egress interface, with ISP-2 as the priority and ISP-1 as backup.

route-map PBR permit 10
 match ip address PBR-ACL
 set adaptive-interface cost ISP-2 ISP-1

Enable Policy Based Routing on INSIDE interface

Policy based routing is enabled on the ingress interface (INSIDE), referencing the route-map PBR created in the previous step.

interface GigabitEthernet0/2
 nameif INSIDE
 security-level 100
 ip address 10.10.0.1 255.255.255.0
 policy-route route-map PBR

Routing

ISP-1 is defined as the default route with a lower cost, traffic NOT matching the route-map policy-based routing will be routed via ISP-1.

route ISP-1 0.0.0.0 0.0.0.0 192.168.10.1
route ISP-2 0.0.0.0 0.0.0.0 192.168.101.1 20

Testing

For testing, enable debug policy-route on the ASA.

Generate traffic towards a PRIORITY-APPS domain – i.e., office365.outlook.com. From the output below, we can see the connection matching the route map PBR sequence and policy-based routing applied, with the egress interface via ISP-2 (as expected).

ASA# pbr: policy based route lookup called for 10.10.0.2/51266 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 10.10.0.2/85 to 40.71.11.169/0 proto 1 sub_proto 8 received on interface INSIDE, 
pbr: First matching rule from ACL(2)
pbr: route map PBR, sequence 10, permit; proceed with policy routing
pbr : PBR Using Default DP Table for forwarding for dest addr 40.71.11.169
pbr: Ingress ifc INSIDE, PBR adaptive traffic forward for dest 40.71.11.169, egress-ifc ISP-2 nh 192.168.101.1
pbr: policy based routing applied; egress_ifc = ISP-2 : next_hop = 192.168.101.1
pbr: policy based route lookup called for 10.10.0.2/85 to 40.71.11.169/0 proto 1 sub_proto 8 received on interface INSIDE, 
pbr: First matching rule from ACL(2)
pbr: route map PBR, sequence 10, permit; proceed with policy routing
pbr : PBR Using Default DP Table for forwarding for dest addr 40.71.11.169
pbr: Ingress ifc INSIDE, PBR adaptive traffic forward for dest 40.71.11.169, egress-ifc ISP-2 nh 192.168.101.1
pbr: policy based routing applied; egress_ifc = ISP-2 : next_hop = 192.168.101.1
pbr: policy based route lookup called for 10.10.0.2/85 to 40.71.11.169/0 proto 1 sub_proto 8 received on interface INSIDE, 
pbr: First matching rule from ACL(2)

If you run show conn and filter on the IP address of the lookup, we can determine that the connection was established via the egress interface ISP-2.

ASA# show conn | I 40.71.11.169

1 in use, 71 most used
ICMP ISP-2 40.71.11.169:0 INSIDE  10.10.0.2:90, idle 0:00:00, bytes 112, flags

Run the command show dns ip-cache to confirm DNS snooping is working and an entry for 40.71.11.169.

Generate traffic is any random domain, that is NOT defined in the PRIORITY-APPS groups. We can see the lookup via 8.8.8.8 and the resolved IP address 142.250.200.35, the debug output confirms no policy-based route found and skipped to use the normal route lookup.

ASA# pbr: policy based route lookup called for 10.10.0.2/32900 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 10.10.0.2/78 to 142.250.200.35/0 proto 1 sub_proto 8 received on interface INSIDE, 
pbr: no route policy found; skip to normal route lookup
pbr: policy based route lookup called for 10.10.0.2/78 to 142.250.200.35/0 proto 1 sub_proto 8 received on interface INSIDE, 
pbr: no route policy found; skip to normal route lookup

If you run show conn and filter on the IP address of the lookup, we can determine that the connection was established via ISP-1, which is the default route.

ASA# show conn | i 142.250.200.35
ICMP ISP-1 142.250.179.227:0 INSIDE  10.10.0.2:80, idle 0:00:00, bytes 112, flags

Tags: