VRF-Aware IPSec Tunnels

Man, time is hard to come by of late.  I’ve had so little time to rest that’s it’s hard to get my thoughts together.  It’s a good thing in this case, though, since it’s my fantastic job that’s taking all my time.  It’s great to see new network and learn their internals…especially when they were designed by some long-time CCIEs who actually knew what they were doing.

One of the big things that I’m dealing with lately is VRFs.  I’ve implemented some VRF-lite stuff, but I’ve never had any practical experience with the full force of them.  I’m definitely learning here.  Since the blog here is really about my sharing what I’ve learned, let’s go through something that came up recently – terminating VPNs on one VRF while passing traffic to another.

What I’m talking about is the old-school, static IPSec VPNs that we’ve all configured a million (or so) times.  You know the ones with crypto maps applied to interfaces?  Well, we’re going to configured one of those for the VRF called “CUSTOMER1” terminated on an interface in the “INTERNET” VRF.

There’s some terminology for these VRFs, actually.  The INTERNET VRF, which has the tunnel endpoint is called the front VRF (FVRF); CUSTOMER1 is called the internal VRF (IVRF).  I’ll try to remember to use those terms, but I make no promises.

First, we need to create the VRFs themselves.  Since the endpoints are in two different VRFs, we’ll need to have some routes leaked from the IVRF to the FVRF.  I could write 847829843828 words on route leaking and not cover everything in my limited experience, so you’ll have to look that up on your own if you don’t know what I’m talking about.  Route-target 65000:1 is exported from INTERNET and imported into CUSTOMER1

At this point, we just put the interfaces in the right VRF along with their addresses.  We’ll also configure an ISAKMP policy just like we’ve done a million times.

Next we’ll create a keyring that’s referenced by the FVRF.  This will make the key for the remote end available for use by that VRF.

Now we create and ISAKMP profile, which is really the blood and guts that make all this work.  An ISAKMP profile references some of the important pieces of the tunnel – the IVRF in which to place the traffic, the keyring to use, and tunnel endpoint, and the FVRF where the tunnel terminates.

We’ll then create the ACL for interesting traffic. I’ll save some trees and not go through that since this should be pretty easy by now.

Now we can create the crypto map. This will be just like any other crypto map you’ve ever made with one exception; this is where you include that nifty ISAKMP profile we just made.

Just like in other cases, we need to add a static route to make sure the router sends the packets destined for the remote end of the tunnel out the right interface. Since the FVPN is INTERNET, we’ll add static routes for that VRF. We’ll do the same for the tunnel endpoint just in case the default routes doesn’t go the right way.

Now the tunnel should be up, right? Probably not. If you take a close look, you’ll see that the FVRF has the route to the remote network, but the IVRF – the one that will use the tunnel – doesn’t. We’ll need to use MPBGP to leak those routes from one VRF to another. Did I mention that route leaking can get long-winded and that I’m not going to get into it? Yeah…it can get that bad. Just trust me that this works.

What we’re going to do is to start up BGP for both VRFs. At the same time, we’ll redistribute the static routes that we added above from the FVRF into the IVRF. Since we set up our imported and exported route-targets in the VRF definition, the static routes will magically appear in both VRFs.

If we do a show ip route vrf CUSTOMER1, we’ll see the static routes from the INTERNET VRF. They’re real easy to spot. 🙂

That should do it. Now you should be able to talk from your local network in the CUSTOMER1 VRF and talk through a tunnel that’s established on the INTERNET VRF.

Send any Juniper configs questions my way.

Update : Here’s an embarrassingly-sloppy logical diagram for Andrew.

IPSec-Aware VPN Logical

Aaron Conaway

I shake my head around sometimes and see what falls out. That's what lands on these pages. If you have any questions, the best way to contact me is through Twitter at @aconaway.

More Posts

Follow Me:

11 comments for “VRF-Aware IPSec Tunnels

  1. That1guy15
    December 13, 2011 at 10:19 am

    Interesting concept! Ive been focusing on the use of VRFs latley mostly for MPLS VPNs but ran across this post. Do you mind elaborating a little on the bennifits of this setup or why you would implement? My only though is you would implement this to segragate VPN traffic on a single ingress interface for multiple customers.


  2. December 14, 2011 at 6:04 pm

    Hey, That1. You’re right in your thought there, and your phrase “single ingress interface” is much more eloquent than the way I described it. 🙂

  3. Per Westerlund
    December 16, 2011 at 9:02 am

    Too bad you don’t want any Juniper configs to compare with 🙂

    It looks like it mimics what we do a lot of the time, having IPsec VPNs terminate at an interface in one common routing instance, and then having the customer traffic flow through a tunnel interface (one per VPN) inside each customers own routing instance. We are using what I think is called “VRF light” in Cisco-speak. Makes for clean, elegant and easily understood configurations.

  4. Howie
    March 18, 2014 at 5:52 pm

    “Next we’ll create a keyring that’s referenced by the IVRF. ”

    You mean FVRF, here, I think.

  5. June 12, 2014 at 10:42 pm

    I agree with Howie. Didn’t you mean FVRF?

  6. June 18, 2014 at 8:55 pm

    Sure did, Howie and Swack. Corrected. Thanks for pointing that out.

  7. Andrew
    June 24, 2014 at 4:01 pm

    I would like to see a logical diagram of this – outside device to outside device.
    IP’s would be nice. Can you draw up something?

  8. romuald
    July 3, 2014 at 3:08 am

    Good article !
    I realized the config but the other side of the ipsec tunnel is configured how?

    for the other side I followed and adapted configuration for this tutorial:


    ipsec transform, isakmp policy and password are the same on both sides.
    ACL and route it’s ok too.

    I can not ping the two lan.

    you can help me?

  9. romuald
    July 3, 2014 at 7:43 am

    i found my error 🙂

  10. ilya
    August 12, 2014 at 2:42 pm

    hello, I’ve got a problem, vrfv – SZ0 and ivrf – test_crypto:

    ip vrf SZ0
    description FVRF
    rd 65000:1
    route-target export 65000:1
    ip vrf test_crypto
    rd 65000:101
    route-target import 65000:1

    R1(config-vrf)#do sh run | sec bgp
    router bgp 65000
    no synchronization
    bgp router-id
    bgp log-neighbor-changes
    no auto-summary
    address-family ipv4 vrf SZ0
    redistribute static
    no synchronization

    R1(config-vrf)#do sh ip route vrf test_crypto

    Gateway of last resort is not set

    C is directly connected, Loopback10

    so, I don’t see any leaked routes inside ivrf from fvrf. also, when I configure reverse-route under crypto map, route appears in ivrf, but no traffic is encapsulated to the tunnel…

  11. lubos
    September 19, 2015 at 10:04 am

    Do you really have to use “set isakmp-profile CUSTOMER1-PROFILE” within crypto map ??? I made very similar configuration, but forgot to use above command and all is working fine.

Leave a Reply to That1guy15 Cancel reply

Your email address will not be published. Required fields are marked *