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 is unchanged when using multi-instance deployments on Secure Firewall platforms. However, instance sizing should account for both throughput requirements and route scale.

Route capacity is not calculated directly from the number of cores assigned to an instance. Instead, each instance size has a supported maximum route scale. Use the route-sizing table or sizing tool to select an instance that supports the required aggregate number of routes across the VRFs in that instance.

For releases through 10.0, an instance can support up to 100 VRFs as long as the total route count remains within the supported route limit for that instance. In release 10.1 and later, the VRF limit increases to 250 VRFs per instance, again subject to the supported route limit within that instance.

When throughput-based sizing and route-based sizing result in different instance sizes, choose the larger instance.

Secure Firewall 4245 route capacity by instance size

The figures below apply to the 4245 appliance. Figures for other appliances will be added soon.

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

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:

• FMC VRF Configuration

• FDM VRF Configuration