Hi, below are my notes I wrote on the subject of VRF Aware IPSEC. They are not really ready for publishing as they are written for me personally but they may still help you. The general idea is that when using VRF with IPSec, there are certain things that need to be done to get it to work such as using keyrings and mentioning the VRF name in various commands. On top of this, the are some different combinations you can use which allow more than one VRF to be used when doing such a setup which adds additional flexibility. When using IPSec with VRF the combinations are:
- Single VRF used to both source the tunnel traffic and terminate the tunnel - Global routing table to terminate the tunnel and a VRF to source the tunnel traffic - Unique VRF to terminate the tunnel (known as front door VRF) and another unique VRF (known as the inside VRF) to source the tunnel traffic When using IPSec/VRF you cannot use a VRF to terminate the tunnel and then source the traffic from the global routing table though as mentioned above this can be done the other way around terminate the tunnel on an interface in the global routing table but source traffic to encrypt from an otherwise isolated VRF. The thing that confused me initially when understanding this was getting around the idea that with VRF comes routing isolation so how does a tunnel terminate on one VRF but source its traffic from the other. Basically, by referencing the different VRFs as outlined below in the ISAKMP profiles you can bind two otherwise isolated routing tables to achieve this. I hope my notes below help and also hope they are correct but please feel free to comment: - Supported in two forms o Crypto Map § If using different inside and front VRF does not support uPRF § Cannot use global VRF as IVRF and non global VRF as FVRF o VTI - Defines two VRF objects in use o Front Door VRF (FVRF) § VRF that terminates the encapsulated tunnel of the VPN o Inside VRF (IVRF) § VRF from which the source and destination networks for packets which are to be encrypted reside - Multiple tunnels can terminate on the same interface which is bound to a VRF used as the FVRF - Each of these tunnel can then have a unique IVRF based on that VRF designated within the ISAKMP profile which is then attached to a crypto map entry - As requires the use of ISAKMP profiles, crypto keyring must be defined to be used - The keyrings can define both PSK and RSA attributes depending on the type of authentication used and need to define the FVRF used to terminate the tunnel otherwise they are bound to the global routing instance R4(config)# crypto keyring kring1 *vrf fvrf* R4(conf-keyring)# pre-shared-key address 150.1.3.3 key cisco - If defining RSA authentication the keyring defines the IP or name of the peer and then inputs the public key of that peer directly into the keyring R4(config)#crypto keyring kring2 *vrf fvrf* R4(conf-keyring)# rsa-pubkey address 150.1.3.3 R4(config-pubkey-key)# address 150.1.3.3 R4(config-pubkey-key)# key-string Enter a public key as a hexidecimal number .... R4(config-pubkey)# A0030201 02020101 300D0609 2A864886 F70D0101 04050030 R4(config-pubkey)# quit - ISAKMP profiles are then created to define Phase 1 and 1.5 settings including the keying to use as previously configured - When defining an ISAKMP profile the IVRF is defined and the match statement that includes the FVRF R4(config)# crypto isakmp profile isaprof1 R4(conf-isa-prof)# keyring kring1 R4(conf-isa-prof)# self-identity address R4(conf-isa-prof)# match identity address 150.1.3.3 255.255.255.255 *fvrf* R4(conf-isa-prof)# *vrf ivrf* - If a VRF is not defined in the ISAKMP profile to designate a IVRF then the IVRF will be equal to the FVRF - There are peculiarities when using RSA for authentication with VRF that requires them to have symmetrical trustpoint configuration where either both define a trustpoint at the ISAKMP profile level or do not and try all defined globally R4(config)#crypto isakmp profile isaprof1 R4(conf-isa-prof)# ca trust-point *tp_name* - If traffic to a CA or LDAP server needs to be routed via a VRF then the vrf command must be used in its configuration R4(config)#crypto pki trustpoint tpname R4(ca-trustpoint)# vrf vrfname - The crypto map then needs to be defined with the ISAKMP profile in two places as below R4(config)# crypto map cmap1 isakmp-profile isaprof1 R4(config)# crypto map cmap1 10 ipsec-isakmp R4(config-crypto-map)# set isakmp-profile isaprof1 - So when performing VRF Aware IPSec there are two scenarios o Using single VRF to source traffic and terminate tunnel o Using to VRFs § FVRF for tunnel termination § IVRF for source of encrypted traffic - Regardless of using the first or second scenarios, IPSEC must use a keyring with ISAKMP profiles and reference the VRF is the following three locations R4(config)# crypto keyring kring1 vrf *fvrf* R4(conf-keyring)# pre-shared-key address 150.1.3.3 key cisco R4(config)# crypto isakmp profile isaprof1 R4(conf-isa-prof)# vrf *ivrf* R4(conf-isa-prof)# keyring kring1 R4(conf-isa-prof)# match identity address 150.1.3.3 255.255.255.255 *fvrf* - The ISAKMP profile is then referenced in the crypto map R4(config)# crypto map cmap1* isakmp-profile isaprof1* R4(config)# crypto map cmap1 10 ipsec-isakmp R4(config-crypto-map)# set peer 150.1.3.3 R4(config-crypto-map)# set transform-set aes-sha R4(config-crypto-map)# set pfs group1 R4(config-crypto-map)# *set isakmp-profile isaprof1* R4(config-crypto-map)# match address crypto1 - If one one VRF is being used then the same VRF name is used in all three commands above otherwise when using FVRF/IVRF the follow is required o Keyring = FVRF o ISAKMP VRF Statement = IVRF o ISAKMP Match Statement = FVRF - The easiest way to remember this is o Keyring and match statements referencing a peer which is reachable via the Front Door VRF o ISAKMP VRF statement binds the profile to the Inside VRF statement - The following scenarios are supported o FVRF = IVRF = VRF1 § All commands referencing the VRF above use the same VRF ID o FVRF = VRF1, IVRF = VRF2 § The IVRF and FVRF must be specifically referenced in the commands above § RRI is required to be enabled on the crypto map so a route to the remote network exists in the routing table via tunnel as it may not exist in the routing table of the transit network due to the segmentation of routes at each end via VRF R4(config)#crypto map cmap1 10 ipsec-isakmp R4(config-crypto-map)# reverse-route static § A special static route is required on the IVRF at each end for the remote protected network via the VRF interface and next hop R4(config)# ip route vrf *ivrf remote_prot_net fvrf_egress_int fvrf_next_hop * R4(config)# ip route vrf vrf2 136.1.100.0 255.255.255.0 Serial0/0.1245 136.1.0.5 o FVRF = Global, IVRF = VRF1 § Also requires RRI injection on crypyto map due to separation of transit and protected router instances at each end R4(config)#crypto map cmap1 10 ipsec-isakmp R4(config-crypto-map)# reverse-route static § A special route is also required in the VRF but instead referenced the global routing table to send traffic from the IVRF being encrypted out the FVRF R4(config)#ip route vrf *ivrf remote_prot_net fvrf_next_hop **global* R4(config)#ip route vrf vrf2 136.1.100.0 255.255.255.0 136.1.0.4 *global* Regards Ben On Wed, Oct 10, 2012 at 3:54 AM, Mike Rojas <[email protected]> wrote: > Courtesy of Piotr Matusuiak, > > http://www.ccie1.com/ > > You will find the topics there. > > Mike Rojas. > > > > > From: [email protected] > > Date: Tue, 9 Oct 2012 12:19:15 -0400 > > To: [email protected] > > Subject: [OSL | CCIE_Security] Help on Some Topics > > > > > > > > > All, > > I was reviewing some of my weaknesses and have two specifically that I > was looking for some guidance and direction. > > > > 1. GETVPN with multicast rekeying through a Multicontext ASA. > > > > 2. Basic VRF Aware IPsec. > > > > I have very little to no knowledge or experience on multicast and VRF > and was hoping that there some members of this list > > who can point me to some documentation or even books to review this > concept. > > > > I know this might be very late but I am not comfortable not knowing and > would like to atleast try everything I can. > > > > Please let me know. > > > > -Srikant > > > > > > _______________________________________________ > > For more information regarding industry leading CCIE Lab training, > please visit www.ipexpert.com > > > > Are you a CCNP or CCIE and looking for a job? Check out > www.PlatinumPlacement.com > > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com > > Are you a CCNP or CCIE and looking for a job? Check out > www.PlatinumPlacement.com >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
