Virtual Routing and Forwarding
Configuring Virtual Routing and Forwarding (VRF) on Cisco Secure Firewall
Introduction
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.
Configuration
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.
Note
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.
Step 3: Click Manage Virtual Routers. Notice that all the interfaces are assigned to the Global VRF, which is the default configuration.
Note
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
Step 5: Enter the VRF name and description. Click OK.
Warning
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.
Note
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.
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.
Step 2: Click on Static Route.
Step 3: Click on Add Route.
Step 4: Select IPv4 or IPv6
Step 5: Select an interface from the interface dropdown list
Note
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.
Step 9: Click Save to save the changes to the VRF configuration.
Note
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.
Note
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.
Note
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).
Step 2: Check the checkbox named Enable BGP. Enter the AS number.
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.
Note
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.
Note
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:
VRF_INSTANCE = (MAX_VRF_PLATFORM / MAX_CORES_PLATFORM) \* (CORES_IN_INSTANCE)
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.
Note
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 192.168.1.0/24 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.
Limitations
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.
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:
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.
Number of Supported VRFs per Platform
Firepower Platform | VRF Limit |
---|---|
1010, 1120 | 5 |
1140, 1150, 2110, ISA3000 | 10 |
3110 | 15 |
2120 | 20 |
3120 | 25 |
2130, FTDv | 30 |
2140 | 40 |
3130 | 50 |
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
Summary
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:
Updated over 2 years ago