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

Email Security - Breaking Down DKIM & DMARC

I recently started pursuing email security studies. Other posts have mentioned this, and a recent post shared a deeper look at SPF. In this blog I want to cover DKIM & DMARC. Starting with DKIM, it

Email Security - Breaking Down SPF

In the post I want to breakdown & cover SPF in more detail. Especially as I continue to embark on the email security journey/track. before beginning, here is another brief overview of what SPF entai

Understanding FTD Multi-Instance Capability Mode

In this post I want to cover running the multi-instance capability with Firepower Threat Detection (FTD). This capability lets you run containers that use a batch of resources of the security module/