VRF-Aware IPsec: Keeping VPNs in Their Lane

VRF-aware IPsec has a reputation for being fiddly, and it mostly is not. What it has is two things called almost the same thing, doing completely different jobs, and until you separate them in your head nothing about the configuration makes sense. Once you do, the rest is bookkeeping.

The two things are FVRF and IVRF. FVRF (front-door VRF) is where the tunnel's outer packets get routed: the encrypted ESP packets that go out to the peer, and the routing table used to reach the tunnel destination. IVRF (inside VRF) is where the decrypted inner packets land: the protected traffic, after the crypto engine has done its work. Front door versus inside. Underlay versus overlay. Getting those two straight is most of VRF-aware IPsec.

We built it on a cat8000v in the CCIE Security lab, put the inside of a certificate-authenticated tunnel into a VRF called RED, and captured the one line of output that makes the whole concept click. This builds directly on the IPsec VPN guide, and on the same tunnel we brought up with certificate authentication in the previous article.

FVRF and IVRF, Precisely

Two VRFs, two jobs. A packet leaving a customer LAN enters the tunnel in the IVRF, gets encrypted, and the resulting ESP packet is routed out in the FVRF. Coming back, the ESP packet arrives via the FVRF, gets decrypted, and the plaintext inside is forwarded using the IVRF's routing table. They never touch each other, which is precisely the property you want.

They are also independent. You can set one, both, or neither. Our lab set the IVRF and left the FVRF global, which is the most common real-world shape: the transport is the normal routing table, and the protected traffic belongs to a tenant.

The Config

Start with the VRF and something to put in it:

vrf definition RED
 rd 65000:1
 address-family ipv4
interface Loopback20
 vrf forwarding RED
 ip address 10.60.10.1 255.255.255.0

Loopback20 stands in for a customer LAN: an interface that lives in RED and nowhere else. It is invisible from the global routing table, which is the whole point of a VRF.

Now put the tunnel's inside into RED:

interface Tunnel5
 vrf forwarding RED
 ip address 10.0.5.1 255.255.255.252
ip route vrf RED 10.60.20.0 255.255.255.0 Tunnel5

Three moving parts. vrf forwarding RED on the tunnel makes RED the IVRF: everything that comes out of this tunnel decrypted gets forwarded in RED. The tunnel's own IP address (10.0.5.1) now lives in RED, not the global table. And the static route tells RED how to reach the remote LAN: out Tunnel5.

Notice what is not in that config. The tunnel source (GigabitEthernet2, 10.100.0.21) and the tunnel destination (10.100.0.22) are untouched. They are still in the global routing table, and the router still uses the global table to route the encrypted ESP packets to the peer. That is the FVRF, and here it is simply "none" (global). The inside moved. The front door did not.

The Gotcha That Bites Everyone Once

Type vrf forwarding RED on an interface that already has an IP address and IOS says this:

GM1(config-if)#vrf forwarding RED
% Interface Tunnel5 IPv4 disabled and address(es) removed due to disabling VRF RED

Read it slowly, because the wording is genuinely confusing (it says "disabling VRF RED" while you are in the act of enabling it). What actually happened: moving an interface into a VRF wipes its IP address. Gone. The address was an address in the global table, and that table is not this interface's table any more, so IOS removes it rather than silently leave a global address on a VRF interface.

The consequence is an ordering rule you must never forget:

interface Tunnel5
 vrf forwarding RED
 ip address 10.0.5.1 255.255.255.252

VRF first. IP address second. Every single time. If you paste a config block in the other order, the vrf forwarding line silently destroys the IP address you just applied, and you are left with an interface in the right VRF and no addressing, wondering why your tunnel will not come up.

This is worse than it sounds when you are changing an existing interface remotely. Apply vrf forwarding to the interface you are managing the router through and you have just removed its IP address and hung up on yourself. It is the crypto-config equivalent of sawing off the branch you are sitting on. If the interface is anywhere near your management path, do it from the console.

The Money Capture

Here is the single line this entire article exists for:

GM1#show crypto session detail
Interface: Tunnel5
Session status: UP-ACTIVE
Peer: 10.100.0.22 port 500 fvrf: (none) ivrf: RED
  IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
        Outbound: #pkts enc'ed 6 drop 0 life (KB/Sec) 4607999/3538

fvrf: (none) ivrf: RED. That is the design, printed by the router.

Peer: 10.100.0.22 port 500 with fvrf: (none) says the IKE session to the peer, and the ESP packets that follow, are being routed in the global table. The underlay is global. The router looked up 10.100.0.22 in the global routing table and sent the encrypted traffic out GigabitEthernet2.

ivrf: RED says the decrypted inner traffic belongs to VRF RED. When an ESP packet arrives from 10.100.0.22, the crypto engine decrypts it and hands the plaintext to RED's routing table, not the global one. A packet inside this tunnel cannot leak into the global table, because the global table is not where it is forwarded.

Two routing tables, one tunnel, cleanly separated. If you only remember one show command from VRF-aware IPsec, make it show crypto session detail and read the fvrf/ivrf field.

Proving It Actually Forwards

A design that looks right and does not pass traffic is not a design. Ping across the tunnel, scoped to the VRF:

GM1#ping vrf RED 10.60.20.1 source Loopback20 repeat 5
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 11/17/25 ms

Note the vrf RED keyword. Without it, the router pings from the global table, finds no route to 10.60.20.1, and fails. The destination does not exist in the global table, because it exists in RED. Forgetting the vrf keyword on a ping is the second most common source of "my VRF is broken" panic, right after the wiped IP address.

And the routing table that made it work:

GM1#show ip route vrf RED
C        10.60.10.0/24 is directly connected, Loopback20
L        10.60.10.1/32 is directly connected, Loopback20
S        10.60.20.0/24 is directly connected, Tunnel5

Three entries and nothing else. RED knows about its own loopback (the local customer LAN) and one static route to the remote LAN via Tunnel5. It does not know about 10.100.0.0/24, the WAN core, or anything else in the global table. It cannot, and that is the isolation working.

The traffic path, end to end: a packet sourced from 10.60.10.1 to 10.60.20.1 is looked up in RED, matches the static route, enters Tunnel5, gets encrypted with the certificate-authenticated IPsec SA, and the resulting ESP packet gets a new outer header of 10.100.0.21 to 10.100.0.22 and is routed in the global table out to the WAN. The far end reverses it. The customer's addresses never appear on the WAN, and the WAN's addresses never appear in RED.

Two Crypto Sessions, Two VRF Contexts, One Router

Here is the detail that makes this concrete. GM1 is also a GETVPN group member, and that crypto session is running on the same box at the same time. Look at the two of them side by side:

Same router. Same physical WAN interface. Same global routing table underneath both. And yet one session's protected traffic lives in the global table and the other's lives in RED, and they cannot see each other. That is not a diagram in a design document, that is two lines of show crypto session detail on a live box.

This is the mental model to keep: the VRF context is a property of the crypto session, not of the router. One box can terminate tunnels for a dozen tenants, each landing in its own VRF, all sharing one underlay.

Why You Would Actually Do This

If you have worked with MPLS L3VPN, all of this will feel familiar, and it should: it is the same VRF machinery, the same route distinguishers, the same per-tenant forwarding tables. The MPLS guide covers VRFs and RDs in depth, and everything you know from there applies here. VRF-aware IPsec is what you reach for when the transport between tenant sites is an encrypted tunnel rather than an MPLS core.

The Front-Door Case, Honestly

Our lab demonstrated the IVRF case: the inside in a VRF, the underlay global. The FVRF case (putting the tunnel source inside a VRF) is the mirror image, and it deserves an honest note rather than fabricated output.

The setup looks like this. The WAN-facing interface goes into a VRF, say INET:

interface GigabitEthernet2
 vrf forwarding INET
 ip address 10.100.0.21 255.255.255.0
interface Tunnel5
 tunnel source GigabitEthernet2
 tunnel vrf INET
 tunnel destination 10.100.0.22

The critical line is tunnel vrf INET. It tells the tunnel: when you go to resolve the tunnel destination and route the encrypted packets, use INET's routing table, not the global one. Without that line the tunnel tries to reach 10.100.0.22 through the global table, finds nothing (because the interface that could reach it now lives in INET), and stays down.

You would then see fvrf: INET in show crypto session detail, with the IVRF being whatever you set on the tunnel interface itself (or none, if the inside is global). The two knobs are genuinely independent: tunnel vrf sets the FVRF, vrf forwarding on the tunnel sets the IVRF, and they can be different VRFs, the same VRF, or one of each with the other global.

The classic FVRF design is an internet edge where the ISP-facing interface sits in an INET VRF holding nothing but a default route to the provider, while the entire corporate network lives in the global table. The tunnel's outer packets ride INET. The decrypted inner packets land in global. The internet's routing table and the corporate routing table share a router and share nothing else, and the same ordering gotcha applies: vrf forwarding on that WAN interface will wipe its IP address too.

Key Takeaways

• FVRF is the front door: the VRF used to route the tunnel's outer, encrypted packets and to resolve the tunnel destination. Set it with tunnel vrf <NAME>. Think underlay.
• IVRF is the inside: the VRF the decrypted inner packets are forwarded in. Set it with vrf forwarding <NAME> on the tunnel interface. Think tenant.
• They are independent. Our lab ran fvrf: (none) ivrf: RED: a global underlay with the protected traffic in a VRF, which is the most common real-world shape.
• show crypto session detail prints fvrf: and ivrf: on the Peer line. That one line tells you the entire VRF design of the tunnel. It is the first thing to check when VRF-aware IPsec misbehaves.
• Moving an interface into a VRF wipes its IP address: % Interface Tunnel5 IPv4 disabled and address(es) removed due to disabling VRF RED. Always configure vrf forwarding BEFORE ip address. Do it from the console if the interface is anywhere near your management path.
• Test with the VRF keyword: ping vrf RED 10.60.20.1 source Loopback20. A plain ping uses the global table, finds no route, and fails, and that is not a fault.
• show ip route vrf RED should contain only the tenant's routes. If you can see the WAN core in there, your isolation is leaking.
• Two crypto sessions on the same router can live in different VRF contexts at once. Our GETVPN session showed ivrf: (none) while the VRF tunnel showed ivrf: RED, on the same box, at the same time.
• Use it for multi-tenant edges, untrusted internet underlays, overlapping customer address space, and keeping management traffic out of customer VRFs.

The tunnel used here is the certificate-authenticated IKEv2 SVTI from certificate authentication for IPsec, and the VRF machinery is the same you already know from MPLS L3VPN. For the full progression from a basic site-to-site tunnel through IKEv2, certificates, group encryption, and now VRF awareness, start at the IPsec VPN pillar.