In a dedicated B2B router design, the device is usually serving one very specific role:
terminating VPN tunnels for partners, vendors, customers, or external business connections.
In that type of environment, VRFs become extremely useful because they let you isolate routing
domains and keep one partner’s traffic separate from another.
One design question that often comes up is whether the Internet-facing side of the router should
remain in the global routing table or be moved into a Front-Door VRF (FVRF).
This article explains what a VRF is, what an FVRF is, how they relate to IKEv2/IPsec, and when
using an FVRF makes sense on a dedicated B2B edge.
What a VRF Actually Does
A VRF (Virtual Routing and Forwarding) instance creates a separate routing table
on the router.
Instead of a single global routing table, the router can maintain multiple independent routing domains.
| VRF | Purpose |
|---|---|
| GLOBAL | Default routing table used when an interface is not assigned to a VRF |
| INTERNET | Internet-facing transport routing |
| PARTNER_A | Routing domain for one B2B partner |
| PARTNER_B | Routing domain for another B2B partner |
| SERVICES | Shared internal services reachable across tunnels |
Each VRF has its own routes, forwarding decisions, and attached interfaces.
That separation is what makes VRFs so useful in B2B environments where different partners may use
overlapping private IP ranges or require strict routing isolation.
Why VRFs Are Common on a Dedicated B2B Router
On a dedicated B2B router, the tunnel interfaces are often assigned to different VRFs so that each
partner or external business connection stays isolated from the others.
| Function | Why VRFs Help |
|---|---|
| Partner VPN isolation | Keeps one partner’s routes separate from another’s |
| Overlapping private IP space | Allows multiple partners to use the same RFC1918 ranges without conflict |
| Security boundaries | Reduces the risk of accidental route leaking between business connections |
| Operational clarity | Makes troubleshooting easier because each routing domain is explicit |
Two Planes in a VPN Design: Transport and Inside
Once you start using IPsec/IKEv2 with VRFs, it helps to think in terms of two different planes.
| Plane | Purpose | Typical VRF |
|---|---|---|
| Transport plane | Where IKE and ESP packets travel to the remote peer over the Internet | GLOBAL or FVRF such as INTERNET |
| Inside plane | Where decrypted business traffic is routed after it enters the tunnel | Partner/customer VRF such as PARTNER_A |
Cisco refers to these as:
- FVRF = Front-Door VRF, used for transport routing
- IVRF = Inside VRF, used for protected traffic routing
Traditional B2B Design: Global Internet + Partner VRFs
A very common enterprise design keeps the Internet-facing interface in the global routing table,
while each VPN tunnel interface belongs to a partner VRF.
Internet
|
Te0/0/0 (GLOBAL)
|
IKE / IPsec
|
-------------------------
| | |
Tunnel10 Tunnel20 Tunnel30
PARTNER_A PARTNER_B PARTNER_C
In that model, the Internet-facing interface and the IKEv2 negotiation both live in the global
routing table.
The tunnel interface and the decrypted traffic, however, live in the partner VRF.
| Component | Routing Table |
|---|---|
| Internet-facing interface | GLOBAL |
| IKEv2 negotiation | GLOBAL |
| Tunnel interface | Partner VRF |
| Decrypted traffic | Partner VRF |
This design is simple, common, and entirely valid.
Many environments with dozens of tunnels run this way without issue.
What an FVRF Changes
A Front-Door VRF moves the transport side of the VPN into its own routing table.
Instead of the Internet interface living in the global table, it is placed into a VRF such as
INTERNET.
Internet
|
Te0/0/0 in VRF INTERNET
|
IKE / IPsec
|
-------------------------
| | |
Tunnel10 Tunnel20 Tunnel30
PARTNER_A PARTNER_B PARTNER_C
The partner VRFs still exist, but the Internet transport path is now separated from the global
routing table.
That is the defining trait of an FVRF design.
What a Clean FVRF Design Looks Like
In a clean FVRF model, the Internet-facing interface belongs to the transport VRF and the tunnel
interface belongs to the partner VRF.
vrf definition INTERNET rd 65000:100 address-family ipv4 exit-address-family vrf definition PARTNER_A rd 65000:201 address-family ipv4 exit-address-family interface TenGigabitEthernet0/0/0 description Internet Edge vrf forwarding INTERNET ip address 203.0.113.10 255.255.255.248 ip route vrf INTERNET 0.0.0.0 0.0.0.0 203.0.113.9 interface Tunnel10 description Partner A VPN ip vrf forwarding PARTNER_A ip address 10.10.10.1 255.255.255.252 tunnel source TenGigabitEthernet0/0/0 tunnel destination 198.51.100.10 tunnel mode ipsec ipv4 tunnel protection ipsec profile PARTNERA-IPSEC
In this architecture, transport is isolated in VRF INTERNET, while the inside
traffic for the partner is isolated in VRF PARTNER_A.
How the Routing Tables Look
One of the easiest ways to understand the difference between a traditional design and an FVRF design
is to look at the routing tables.
Example: Transport VRF
show ip route vrf INTERNET Gateway of last resort is 203.0.113.9 to network 0.0.0.0 S* 0.0.0.0/0 [1/0] via 203.0.113.9 C 203.0.113.8/29 is directly connected, TenGigabitEthernet0/0/0 L 203.0.113.10/32 is directly connected, TenGigabitEthernet0/0/0
This table contains the public Internet path used to reach external VPN peers.
Example: Partner VRF
show ip route vrf PARTNER_A Gateway of last resort is not set C 10.10.10.0/30 is directly connected, Tunnel10 L 10.10.10.1/32 is directly connected, Tunnel10 S 172.16.20.0/24 [1/0] via 10.10.10.2 S 172.16.30.0/24 [1/0] via 10.10.10.2
This table contains only the decrypted partner routes reachable across the VPN.
That separation is the heart of the FVRF model: transport routing is isolated from business routing.
Reading the IKEv2 Output: Why fvrf = none Matters
One of the most useful ways to confirm how a VPN is actually negotiating is to look at the
IKEv2 security association detail.
In a traditional B2B design where the Internet-facing interface remains in the global routing
table, the output will often look like this:
Tunnel-id Local Remote fvrf/ivrf Status 12 203.0.113.10/500 198.51.100.25/500 none/PARTNER_A READY Encr: AES-CBC, keysize: 256, PRF: SHA256, Hash: SHA256, DH Grp:14 Life/Active Time: 28800/4629 sec Status Description: Negotiation done Local id: 203.0.113.10 Remote id: 198.51.100.25 Initiator of SA: Yes PEER TYPE: Other
The most important field in this output is:
fvrf/ivrf none/PARTNER_A
| Field | Meaning |
|---|---|
| fvrf = none | IKE negotiation is occurring in the global routing table |
| ivrf = PARTNER_A | Protected traffic is being routed in the partner VRF |
That distinction is critical.
Engineers sometimes assume that because a tunnel interface is assigned to a VRF, the IKE
negotiation must also be happening in that VRF.
That is not necessarily true.
If the tunnel source is a public-facing interface in the global routing table, the router will
negotiate IKE in the global table.
In that case, the fvrf field shows none.
In most cases, this happens because the tunnel source points to an Internet-facing interface that is
still in the global routing table rather than in a transport VRF.
Why This Matters for Policy Matching
Consider the following IKEv2 policy:
crypto ikev2 policy 10 match fvrf INTERNET proposal STANDARD-B2B
This policy only matches if the router sees the IKE negotiation arriving through
VRF INTERNET.
If the live SA output shows:
fvrf/ivrf none/PARTNER_A
then that policy will never match, because the router does not see the front-door VRF as
INTERNET.
It sees the front-door VRF as none, which means global.
What This Tells Us About the Design
If the IKEv2 output shows fvrf = none, the design is not using a true Front-Door VRF.
It is using a more traditional model:
Internet-facing interface = Global routing table IKE negotiation = Global routing table Tunnel interface = Partner VRF Protected traffic = Partner VRF
By contrast, in a true FVRF design the output would look more like this:
fvrf/ivrf INTERNET/PARTNER_A
That would confirm that:
- The Internet-facing transport path is in VRF INTERNET
- IKE negotiation is occurring in VRF INTERNET
- Protected traffic is still routed in VRF PARTNER_A
Operational Takeaway
This output is one of the fastest ways to determine whether an FVRF-based policy design will
actually work.
If the router shows fvrf = none, then any policy based on
match fvrf INTERNET will not apply until the transport interface is actually moved
into that VRF.
Using FVRF in IKEv2 Policy Control
One important benefit of an FVRF design is that it allows IKEv2 policy selection to be scoped to a
specific transport VRF.
crypto ikev2 policy 10 match fvrf INTERNET proposal STANDARD-B2B
This lets the router apply a policy specifically to IKE negotiations arriving through the
INTERNET transport VRF.
That can be valuable in environments where different transports or edge domains require different
policy handling.
Why FVRF Can Be Useful
FVRFs are most useful when you want to isolate the transport side of VPN routing from the rest of
the router.
| Benefit | Why It Matters |
|---|---|
| Transport isolation | Internet routing is separated from the global table |
| Cleaner policy control | IKEv2 policies can be scoped to a specific transport VRF |
| Multi-tenant scale | Useful when one router handles many partner or customer VPNs |
| Multiple transports | Supports separate Internet, MPLS, or LTE transport VRFs |
| Operational consistency | Keeps all WAN-facing routes and crypto transport behavior in one place |
Why FVRF Is Not Always Necessary
FVRF is a strong design pattern, but it is not automatically the right answer for every B2B router.
If the router has a single Internet-facing uplink, stable routing, and the transport side is simple,
keeping the WAN in the global routing table can be perfectly reasonable.
| Drawback | Why It Matters |
|---|---|
| Higher complexity | Transport routing, NAT, monitoring, and failover become more VRF-aware |
| Design change impact | Moving an existing Internet interface into a VRF is a major change |
| Troubleshooting overhead | Engineers must track both transport VRFs and inside VRFs |
| Operational burden | Not all teams need the extra segmentation if the environment is small and stable |
When FVRF Usually Makes Sense
On a dedicated B2B edge, FVRF becomes more compelling when one or more of these conditions exist:
- The router terminates a large number of business VPNs
- Different transports are in use, such as Internet primary and LTE backup
- Crypto policy needs to be scoped by transport path
- The routing design is evolving toward a larger multi-tenant VPN edge
- The team wants strict separation between Internet routing and the global table
In those situations, moving the transport side into an FVRF often makes the overall design cleaner
and more predictable.
Current Design vs FVRF Design
| Feature | Global WAN + Partner VRFs | FVRF + Partner VRFs |
|---|---|---|
| Internet-facing interface | Global routing table | Transport VRF such as INTERNET |
| IKEv2 negotiation | Global | FVRF |
| Partner traffic | Partner VRF | Partner VRF |
| Operational simplicity | Higher | Lower |
| Transport isolation | Lower | Higher |
| Scalability for large B2B edge | Good | Better |
Final Takeaway
On a dedicated B2B router, using partner VRFs for tunnel traffic is already a strong design pattern.
The main question is whether the Internet-facing transport side should remain in the global table or
move into a dedicated transport VRF.
If the environment is relatively simple, global Internet transport plus partner VRFs is often enough.
But when scale, policy control, or transport isolation become more important, introducing an
FVRF such as INTERNET can make the design cleaner and more maintainable.
In short:
- IVRF isolates partner traffic
- FVRF isolates transport routing
- Both are valid tools, and the right answer depends on the architecture you are trying to build