Securing Routing Protocols on FTD

"The What?" - In this post I will be covering how to configure several routing protocols on FTD via FMC, how to secure the protocols, how to verify routing authentication, & how to simply verify that routing is working as expected. The topology that will be used is the same from other recent FTD posts:



"The Why?" - Another important security task to secure the control plane. Securing routing protocols ensures that all updates are from legitimate peers. This aides in accepting route messages from illegitimate sources.


"The How?" - Now I will cover how to configure routing in general, securing & authenticating the protocols depicted above, & how to verify it all.


Let's start with OSPF. Note that for the purpose of this blog I am omitting the OSPF configuration on the CSRs. I am configuring routing between FTD & the 4 CSRs. All loopbacks will be advertised into the respective protocol. Later I will do some redistribution between the protocols to show how to do so with FMC & allow connectivity to other loopbacks emulating remote LANs. So, to configure FTD routing: Device Management->Devices->Routing.

Above depicts the OSPF process being enabled as process 1 (FTD can run 2 OSPF processes). The role is configured as ABR & ASBR since we connect to other routing protocols and two different areas. Next I configured the interface options for process 1 which includes the md5 authentication used to authenticate our neighbor:

Using FTD CLI to verify OSPF neighbors:

Purposely misconfiguring auth key on the CSR to verify and see errors on FTD CLI:

7 Authentication errors; To view this use: show ospf traffic

Next I share enabling RIPv2 within FMC for the two connections (inside/dmz2 interfaces) with md5 authentication:

RIP verification from FTD CLI:

Using show route we can see the rip routes installed on FTD (depicted with R).


The last piece to configure before diving into redistribution is that outside OSPF connection. Below I added the configuration to the FTD device & share how to specifically identify the neighbor when enabling/adding another OSPF enabled interface with FTD:

Adding the outside interface:

Adding additional area and enabling OSPF on the outside interface:

Verification of OSPF area configuration in FMC:

Verifying outside OSPF neighbor adjacency and routes after deployment:

Quick overview of debugging OSPF from FTD CLI; Logs depicted below were due to key mismatch: debug ip ospf adj

To wrap this up I covered deploying & securing RIP & OSPF on FTD using FMC. In the next FTD routing post I will cover FTD route redistribution between RIP & OSPF, & vice versa. Cheers!

0 comments

Recent Posts

See All

Configuring FTD Basics with FMC

"The What?" - In this blog I will be covering FTD/FMC basics to include managing FTD instances from FMC & deploying/managing interfaces. First, to see more about FMC/FTD Registration/Communications &

Cisco 4110 Platform - Upgrade an HA Pair

"The What?" - In this post I am going to share how to properly upgrade a pair of 4110 units with FTD acting as an HA pair (Active/Standby). I will cover upgrading FXOS, FTD, FMC, & even firmware. "T