Securing Routing Protocols on ASA

"The What?" - In this blog I will cover configuring, securing, verifying, & redistributing routing protocols on the ASA. Protocols covered include RIP, OSPF, EIGRP, & BGP.


"The Why?" - Securing routing protocols is one of many best practices in securing the control plane. Routing protocol security ensures that routing updates are authenticated & from legitimate peers. This deters introduction of unauthorized or false routing messages from unapproved sources.


"The How?" - The topology used in this demo is as follows:

For your situational awareness: The CSRs are deployed in a clockwise manner starting at top left. Top left CSR is CSR1, top right CSR is CSR2, bottom left is CSR3, & bottom right is CSR4. The third octets on the vlans connecting to the ASA depict which CSR the ASA connects to on each interface (ex: 10.10.34.x connects to CSR4). All ASA interfaces are configured as .1 & each CSR connecting to the ASA is .2 for each respective vlan. Lastly, the clouds depict emulated LANs which are essentially just loopbacks (ex: 34.34.34.34 is CSR4 Loopback 1).


A majority of configuration snippets & screenshots shared throughout the post are from the ASA. All CSRs are preconfigured to support this blog. I will cover securing routing protocols on IOS in other posts.


With each protocol I will cover the following from the ASA perspective:

  • Configuring the protocol

  • Authenticating the protocol

  • Verifying configuration & authentication

  • Redistribution

First I will cover RIP:

A couple of quick things to note. DMZ_1 & DMZ_2 interfaces on the ASA connecting to CSR2 & CSR3 have the same security-level. Traffic from one interface to another on the ASA with same the same security-level is dropped by default. See below for ASA interface security levels:

In order to allow traffic to flow from CSR2<-->CSR3 the following must be configured:

Prior to enabling that command on the ASA pings were failing until traffic was permitted via the command above. Enabling that command is critical for data plane traffic between the two interfaces:

Ok so now that we are good on permitting traffic between different interfaces and zones with same sec-level we can dive into RIP on the ASA:

Configuring RIP on the ASA:

The ASA will run version 1 by default so v2 needs to be enabled. The network statement is enabling RIP on the respective interfaces. Auto-summarization is also enabled by default, which allows RIP to summarize routes to their classful networks automagically so it is best to disable.


Authenticating the protocol on the ASA:

It is important to note that the ASA does not support key-chains like routers do. Quick note on keychain management:

  • Keychain management allows you to create and maintain keychains, which are sequences of keys. You can use keychains with features that secure communications with other devices by using key-based authentication. The device allows you to configure multiple keychains. Some routing protocols that support key-based authentication can use a keychain to implement a hitless key rollover for authentication.

On the ASA you apply the parameters to the interfaces connecting to the RIP routers which looks like this:

Verifying RIP on ASA:

As you can see I am receiving RIP routes (emulated LANs (Loopbacks))from each respective CSR from the control plane perspective.


Debugging authentication misconfiguration from ASA perspective:

#debug ip rip

Next up, Configuring, Securing & Verifying EIGRP on the ASA:

Configuring EIGRP on the ASA:

I am specifically enabling EIGRP only on the inside interface that connects to CSR4 in the topology:

Authenticating EIGRP on the ASA:

Verifying EIGRP on the ASA:

Configuring, Securing, & Verifying OSPF on the ASA:

Configuring OSPF on the ASA:

Authenticating OSPF on the ASA:

Verifying OSPF on the ASA:

Debugging authentication misconfiguration from ASA perspective:

Configuring, Securing, & Verifying BGP on the ASA:

Configuring BGP:

Securing BGP:

Verifying BGP:

You can see the emulated LAN from CSR1 that was advertised into BGP appear in the table:

Debugging BGP Authentication Misconfiguration on ASA:

I purposely misconfigured the password on CSR1 and enabled debugs on the ASA side:

Redistributing routing protocols on the ASA:

Redistributing into EIGRP:

Verifying EIGRP Redistribution:

Route table verification from CSR4 which is running EIGRP:

Redistributing into RIP on ASA:

Verifying RIP Redistribution:

Route table from CSR2:

Redistributing into OSPF:

Verifying OSPF Redistribution:

Ok, that about wraps this blog up which covered configuring, verifying, & securing routing protocols on/from the ASA perspective. Cheers!

0 comments

Recent Posts

See All

Understanding, Configuring, & Verifying ASA Clustering

"The What?" - In this blog I will be covering ASA clustering. I intend on providing a brief general overview of ASA clustering, as well as how to configure one of the modes & perform verification. "T

Traffic Redirection to ASA FirePOWER Module

Building off of the following blog: Installing & Configuring FirePOWER Services Module on ASA - CLI, I will now cover how to redirect traffic to an ASA SFR module. I also intend on ASA SFR packet proc