Virtual Routing and Forwarding

Configuring Virtual Routing and Forwarding (VRF) on Cisco Secure Firewall


The Virtual Routing and Forwarding (VRF) feature was added in Firewall Threat Defense (FTD) release 6.6 to allow for routing table segregation. Also, VRF allows network segments with overlapping IP address spaces. VRF implementation on FTD is akin to VRF-lite on Cisco routers. You can also use VRFs for routing plane separation during migration from multi-context ASAs to FTD.

Release 7.2 adds VRF support for the 1010 series and allows VTIs in user-defined VRFs.


Using VRF, we can separate the firewall functions for different routing domains across an enterprise network. Also, it allows for overlapping address space to co-exist and communicate through the FTD.



The FMC and FDM user interface refer to a VRF as Virtual Router. These terms will be used interchangeably.

Firewall Management Center

This section details the configuration steps using Firewall Management Center (FMC).

Creating a VRF

Step 1: Choose Devices > Devices Management. Click on the "pencil" icon against the FTD you wish to configure for VRFs.

Step 2: Click on the Routing tab.

**Figure 1:**  Routing tab

Figure 1: Routing tab

Step 3: Click Manage Virtual Routers. Notice that all the interfaces are assigned to the Global VRF, which is the default configuration.

**Figure 2:** Manage Virtual Routers

Figure 2: Manage Virtual Routers



Under Manage Virtual Routers, there is a dropdown menu to select a VRF. After creating a new VRF, use this to select that VRF and configure settings within the VRF, such as interface assignments, static and dynamic routing.

Step 4: Click + Add Virtual Router

**Figure 3:**  Click "Add Virtual Router"

Figure 3: Click "Add Virtual Router"

Step 5: Enter the VRF name and description. Click OK.

**Figure 4:** New virtual router details

Figure 4: New virtual router details



Verify the VRF name before assigning interfaces to the VRF. The FMC does not allow editing the name of the VRF once it is created. If you wish to change the VRF name, you need to click on Manage Virtual Routers, delete the VRF and recreate the VRF with the correct name.

Step 6: Now, you will be redirected to the Virtual Router Properties page with the newly created VRF selected in the dropdown menu. Select the interface/s from the Available Interfaces and click Add.

**Figure 5:**  Virtual Router Properties

Figure 5: Virtual Router Properties



Available Interfaces only the interfaces configured with a logical name and not assigned to another user-defined VRF are available.

Step 7: You can repeat Steps 3 to 6 for adding more VRFs.

Step 8: Remember to save the changes after adding the VRFs.

**Figure 6:**  Make sure to save your changes!

Figure 6: Make sure to save your changes!

Step 9: Deploy from the FMC if you are not making any more configuration changes.

Configure Static Routes for VRF

You can use Static routes for intra VRF routing or to leak routes into other user-defined VRFs or the global VRF. When selecting an interface for the static route, the FMC shows the VRF that the interface belongs to.

Step 1: Select the VRF from the dropdown menu under Manage Virtual Routers.

**Figure 7:**  Selecting a user-defined VRF

Figure 7: Selecting a user-defined VRF

Step 2: Click on Static Route.

**Figure 8:**  Static routes

Figure 8: Static routes

Step 3: Click on Add Route.

**Figure 9:** Add Route

Figure 9: Add Route

Step 4: Select IPv4 or IPv6

Step 5: Select an interface from the interface dropdown list



FMC shows the VRF assignment of each interface. Interfaces that are part of Global VRF have the word Global shown against them. For route leaking, don't specify the next hop.

Step 6: Select Network from the Available Network dropdown list. Click Add to populate the table named Selected Network.

Step 7: Select the next hop from the Gateway dropdown list. If leaking routes, leave this blank.

Step 8: Click OK.

**Figure 10:** Static route configuration

Figure 10: Static route configuration

Step 9: Click Save to save the changes to the VRF configuration.

**Figure 11:**  Don't forget to save your changes

Figure 11: Don't forget to save your changes



You must leak the route in the reverse direction as well if the traffic is not matching any inspection rules such as ICMP inspection. If the Gateway objects don't exist, you can create a new object from the route configuration window.

Step 10: Deploy from FMC if you are not making any more configuration changes.

Configure OSPF for VRF

FTD supports OSPFv2 for user-defined VRFs and OSPFv2/v3 for Global VRFs.

Step 1: Select the VRF from the dropdown menu under Manage Virtual Routers. (See Figure 7)

Step 2: Click on OSPF.

Step 3: Check the Process 1 checkbox.

**Figure 12:**  OSPF settings

Figure 12: OSPF settings



The Process ID is pre-filled and cannot be changed. FTD allows 2 OSPF processes per VRF. The numbers 1 and 2 are reserved for the OSPF Process IDs in global VRF. The next two numbers, 3 and 4, are allocated to the two OSPF Process IDs in the first user-defined VRFs. This incremental pattern continues whenever OSPF is enabled in the next user-defined VRF.

Step 4: The rest of the OSPF configuration is similar to a non-VRF aware OSPF configuration.



InterfaceΒ allows you to select only the interfaces of the virtual router that you are configuring.Β OSPFv3 configuration is available only in the Global VRF.

Step 5: Deploy from FMC if you are not making any more configuration changes.

Configure BGP for VRF

All VRFs share a single BGP process with each VRF as an address family within that process. That is why the BGP configuration is split into two steps. There are general settings (e.g. AS number) and per user-defined VRF settings.

Step 1: In the same column as the Manage Virtual Routers, click on BGP under General Settings (Irrespective of the VRF selected under Manage Virtual Routers).

**Figure 13:**  Configuring BGP

Figure 13: Configuring BGP

Step 2: Check the checkbox named Enable BGP. Enter the AS number.

**Figure 14:**  Enabling BGP

Figure 14: Enabling BGP

Step 3: Configure the rest of the BGP General Settings.

Step 4: Select a VRF from the dropdown menu under Manage Virtual Routers.

Step 5: Click BGP. Configure the BGP settings specific to the selected VRF.

**Figure 15:**  BGP general settings

Figure 15: BGP general settings



You cannot change all the global BGP settings within User-defined VRFs. However, you can override the router-Id within each VRF. The rest of the BGP configuration is similar to non-VRF aware BGP configuration.

Step 6: Click IPv4 under BGP. Click on Enable IPv4. Configure the IPv4 address family settings.

**Figure 16:** Enabling IPv4 for BGP

Figure 16: Enabling IPv4 for BGP



User-defined VRFs support BGP IPv4 address family, whereas Global VRFs BGP configuration supports IPv4 and IPv6 address families.

Step 7: Deploy from FMC if you are not making any more configuration changes.

Multi-Instance with VRF

VRF configuration remains the same when using multi-instance on the Firepower and Secure Firewall platforms. However, the number of VRFs in an instance depends on the number of cores allocated to that instance and is calculated as follows:


Let's use the FP9300 SM-36 module as an example to calculate the number of VRFs in an instance. This platform supports a maximum of 70 cores and 100 VRFs. Here is the calculation for the VRFs in an instance with 20 cores:

(100/70)\*20 = 28 ( We use the value rounded down after calculation )

How policies interact with VRF

Assigning the interfaces to different VRFs segments the routing table. However, the Security Policies consider the interface's Security Zone, which implies that the policy evaluation is not VRF aware by default.



The Security Intelligence policy is not VRF aware. If an IP address, domain or URL is blocked as part of Security Intelligence, it will be blocked across all the VRFs.

E.g. If you create a rule with the source zone as "any," it matches the traffic originating from all interfaces across all VRFs.

For applying policies based on VRF, you need to assign the same Security Zone to all the interfaces from a VRF and then use that Security Zone in the security policy.

Overlapping IP addresses

VRFs create mutually exclusive routing tables, enabling FTD to allow overlapping or same address spaces across different VRFs. While creating a security policy, we need to be aware of overlapping IP subnets.

E.g. IP subnet exists in VRF-A and VRF-B. The network administrators require users in VRF-A to have Internet access and users in VRF-B to not have Internet access. If you create a security policy that allows Internet access based solely on the source IP network, you will inadvertently allow access to the Internet from both VRFs. You need to assign the interfaces belonging to VRF-A and VRF-B in different Security Zones. Use the Security Zone assigned to the VRF-A interfaces and the source IP network to allow Internet access.


Identity policies require different realms per VRF and different ISE connections per VRF to segregate the user-IP and SGT-IP mappings per VRF.

Features such as Threat Intelligence Director (TID), Host Profiling and Malware Trajectory rely on the FMC to map the network. Overlapping IP addresses make it impossible to differentiate when the same IP address belongs to two different hosts. When an overlapping IP segment exists on the same device across multiple VRFs, the analysis from these features is not accurate.

NAT interaction with VRF

FTD uses NAT and/or a routing table for selecting the egress interface and the next hop adjacency resolution. NAT can be used to leak routes across two VRFs and also as a way of enabling communication between overlapping subnets.

Route Leaking using NAT

If you configure NAT rules with the source and destination interfaces in different VRFs, the traffic passes from one VRF to another. However, suppose you do not specify the route lookup option. In that case, the NAT configuration determines the egress interface and the traffic will be sent to the VRF mapped to the destination interface without validating if the destination VRF has a route. We recommended using static routes for route leaking along with a NAT policy configuration.

**Figure 37:**  Route Leaking using NAT

Figure 37: Route Leaking using NAT

Overlapping IP addresses

**Figure 38:**  Overlapping IP Addresses

Figure 38: Overlapping IP Addresses

If a NAT rule is applied to VRFs with overlapping IP address spaces, ensure that the source interface is specified in a NAT rule for each VRF, ideally with separate NAT/PAT pools. Using 'any' in the source interface causes reverse translation to fail. Even without overlapping IP addresses, using specific interface definitions in the NAT rules is highly recommended.

NAT can enable overlapping subnets to communicate with each other without using BVIs or another network hop, as shown in this example:

**Figure 39:**  Using NAT to enable overlapping IP addresses

Figure 39: Using NAT to enable overlapping IP addresses

Verification and Troubleshooting

show vrf
show route \[vrf name\]

show ospf \[ vrf name \| all\]

show bgp \[ vrf name \| all\]

A special SI route flag shows leaked routes in the routing table.

**Figure 40:** "show route" output

Figure 40: "show route" output

Number of Supported VRFs per Platform

Firepower PlatformVRF Limit
1010, 11205
1140, 1150, 2110, ISA300010
2130, FTDv​30
4110, 4112​60
4115, 4120​80
3140, 4125, 4140, 4145, 4150, 9300 SM-24/36/40/44/48/56 (per-blade)​100
9300 with fully populated blades (3x SM)​300

Table 1: VRFs per Platform


VRF combined with multi-instance can provide true multi-tenancy through routing, security policy and management plane separation.

πŸ“š Additional Resources

More detailed information about VRF is available in the configuration guides for: