Just had a blast playing with VRF Route Leaking with a FTD. It is so cool and super simple to do.

Let’s say you have a Cisco Firewall, a 3140 FTD in this instance, and you want to have varying VRFs created to segment off varying customers, internal segments in your company, or partners. At the same time while you don’t want to have them be able to communicate with each other you do want them to be able to access a common Core.

Something maybe like below. Below what we have is “segments” that we want to have setup in the Firewall in their own individual VRFs (virtual route forwarding instances). Below we have the big picture with, essentially, 4 VRFs – Blue, Green, Yellow and also a VRF created for the GRT (global routing table). Just to let you know we did not have to do this. We could have used the default VRF for the Global routing table.

What I want you to see first is basically 4 silo’d blocks.

A side note, by the way, there is a GREAT CiscoLive US 2022 presentation that I’d also recommend Firepower Virtual Routing and Forwarding (VRF) – BRKSEC-3580

Obviously first you have to configure each of the individual 4 blocks above – create the VRFs, assign interfaces to them, assign IP addresses, do whatever routing you want inside that VRF, etc. To route leak between the VRFs we have to “connect the blocks”.

Connecting the Blocks

So I want to “connect the blocks”. Well let me rephrase, I want to connect SOME blocks. I want Blue, Green, and Yellow to be able to communicate with the “Core” off the GRT (global routing table) VRF. I do not want Blue, Green, or Yellow to be able to communicate with each other though.

There are 3 things I did to connect the blocks.

• Routing: Route Leaking between the VRFs using static routes
• Allowing Traffic in the Access Control Policy (ACP): Configure in the ACP that Blue and GRT, for example, are allowed to talk with each other
• NAT: Configured source NAT (not covered in this blog)

In this blog I will be focusing primarily on just the “Routing” one for VRF route leaking. I will touch also on modifying the ACP.

So let’s break this down

Routing

Let’s look only at the BLUE vrf and the GRT vrf first. And let’s imagine that they were actually 2 different routers. If something in the BLUE LAN was trying to get to something in the GRT subnet range (14/8 or 10.214/16) the BLUE router would have to have a route for it via dynamic routing or a static. Also, of course, for the traffic to return from the GRT subnet range back to the BLUE LAN our GRT router would need the return routing.

If the two were actually routers we would find that the routing tables of each would have in them the next hop IP address.

But there isn’t a physical subnet between the BLUE VRF and the GRT VRF. So there isn’t a “next hop IP addresses”. So when we configure the static VRF route leaking between the two we obviously have to do something a little different than a next hop IP address. Basically we are going to configured a VRF static route that tells BLUE VRF to next hop over to the GRT VRF and vice versa.

This will be VRF route leaking and we need to do it in both directions just like we would in the diagram above if they were 2 routers instead of 2 VRFs in one 3140.

So using the diagram above let’s talk about what we need to configure inside of the BLUE VRF. What we need inside the BLUE VRF is not that much dissimilar from if it were a router. Since we are doing static routes we need a static in the BLUE vrf that let’s us know where to send a packet destined to 14.0.0.0/8 or 10.214.0.0/16. Since we do not have a next-hop IP address to point to, we will point to the GRT VRF and the interface to use over there.

Note: Object GRT-14 is defined elsewhere as 14.0.0.0/8, similarly object GRT_214 is defined elsewhere as 10.214.0.0/16

The above is the static route as configured inside of VRF blue. This is VRF route leaking when done statically. So now the BLUE vrf has 14.0.0.0/8 (GRT-14) and 10.214.0.0/16 (GRT_214) “leaked” into it from VRF GRT.

Of course, if we want the traffic to work in the other direction (from GRT vrf to the BLUE VRF) for bidirectional traffic to occur, we need to also leak the BLUE IPv4 routes into the GRT VRF. And we will need this in GRT for Blue, Green, and Yellow.

Note: Yes, I sometimes like to use objects so things make a little more sense to me instead of memorizing IP addresses. Also remember, I do proof of concepts for a living, so much easier when I am showing customers things to give them names. Blue_Network = 10.1.0.0/16, Green_Network = 10.2.0.0/16, and Yellow_Network=10.3.0.0/16.

If you do look at the actually running config deployed on the FTD you would see, btw, something more like the below. Please note that everything that actually has a “next hop IP address defined” is really just a static route inside of Blue, Green, or Yellow on how to get from the FP3140 VRF to the LAN subnet for that VRF.

Allowing Traffic in the ACP

Don’t forget to allow the traffic. :). After all this is a firewall with an access control policy tied to the FP3140.

This is a super overly simplified ACP. Basically the default rule is to block everything. I did that just to really kinda make it all super clear. Blue and GRT are allowed to communicate with each other, Green and GRT, and also Yellow and GRT.

It was all just so simple. Admittedly I also had a bunch of fun playing with NAT as well. Instead of explaining everything here though, I strongly recommend Luis’ CiscoLive 2022 US breakout. If you didn’t know this, CiscoLive is free for you to get an account. Once you have an account you can search thru all of the many fabulous sessions in the Video on Demand Library. Watch the videos or just down load the presos. I really liked Luis’ session and learned tons!

Firepower Virtual Routing and Forwarding (VRF) – BRKSEC-3580

Categories: Firewall

Tags: 3140, VRF Route Leaking