IPsec and VRFs. So who's doing the VRF handoff anyway?

VRF aware IPsec - complicated topic? Not really.

So what are the the options that we need to configured
1) what will be the front (FVRF) and back (IVRF) VRF?
2) Which VRF will we be matching a given identity on?
3) Post encapsulation which VRF will we be putting the packets on?
You can read all this in the configuration guide:
http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_vrf_aware_ipsec_ps10591_TSD_Products_Configuration_Guide_Chapter.html
Check out the excellent examples.

So let's consider something more advanced. GRE over IPsec with VRFs.
Very often people will not know what should happen with IVRF, should it be specified under isakmp profile or not?
How does FVRF behave?
Following also applied to SVTI tunnels, and to some extent DVTI, note that VRF integration with L2TP(/with IPsec) is a whole new world.

Consider this example.
I have VRF BB linking both sides of GRE tunnel. One side has VRF BLUE and the other RED.
I will configure one side using tunnel protection (TP) other using crypto maps.
Certificate authentication is easier (no keyring needed) but let have a look.
Note that I do not need to go to my CA server via any VRF so I do not specify VRF in trustpoints.

TP side:
------------------------------
crypto pki trustpoint cisco2
 enrollment url http://10.0.0.3:80
 serial-number
 revocation-check crl
crypto isakmp policy 10
 encr aes
 group 2
crypto ipsec transform-set ITS esp-3des esp-sha-hmac
crypto ipsec profile PRO
 set transform-set ITS
interface Tunnel0
 ip vrf forwarding BLUE
 ip address 172.16.0.1 255.255.255.252
 tunnel source Ethernet0/0.100
 tunnel destination 10.0.0.101
 tunnel vrf BB
 tunnel protection ipsec profile PRO
------------------------------
And yes, it's GRE/VTI that is doing the handoff. Not convinced? Let's have a look at crypto maps.

------------------------------
crypto isakmp policy 10
 encr aes
 group 2
crypto isakmp identity dn
crypto isakmp profile IPSEC_VRF
   ca trust-point cisco
   match identity address 10.0.0.100 255.255.255.255 BB
 crypto map MAP 100 ipsec-isakmp
 set peer 10.0.0.100
 set transform-set ITS
 match address GRE
interface Tunnel0
 ip vrf forwarding RED
 ip address 172.16.0.2 255.255.255.252
 tunnel source Ethernet0/0.100
 tunnel destination 10.0.0.100
 tunnel vrf BB
interface Ethernet0/0.100
 encapsulation dot1Q 100
 ip vrf forwarding BB
 ip address 10.0.0.101 255.255.255.0
 crypto map MAP
------------------------------

Is it working? And what are the main differences... Let's have a look at show crypto ipsec sa output.

TP side:
------------------------------
interface: Tunnel0
    Crypto map tag: Tunnel0-head-0, local addr 10.0.0.100
   protected vrf: BLUE
------------------------------

Crypto map side:
------------------------------
interface: Ethernet0/0.100
    Crypto map tag: MAP, local addr 10.0.0.101
   protected vrf: BB
------------------------------

Is that at all correct? Well check "show crypto map". All I can say "It's pinging!"