IPSEC VPN with VRF?

FrankGuthrie

Hi guys,

In our network we have IPSEC VPN connections with our customer. We have hosted server n our network which the customer reaches by the means of a VPNc connection.

We use a Cisco 7206 To peer wiht our customer. Now I'm digging through the configurations and i see the following components configured for the customers:
- VRF
- Crypto Keyring
- Cryptomap
- Access list (To identify interesting traffic going out to the customer)
- sub-Interface (Traffic is come in on the router and is then separated further into our network)

Now on the sub interface I see that the VRF is defined, but not the Cryptomap, the Cryptokeyring and Crypto Profile. I'm wondering, don't these need to be applied to the VRF???

Or does the traffic come in from a peer, and that peer address is used to identify all the policies, Cryptomap, the Cryptokeyring and Crypto Profile?

Thanks.

EMcCaleb

Hello Frank

The crypto-map does not have to be under the VRF enabled sub-interface. Just make sure you specify the VRF under the isakmp profile. I'm not sure if this is supported on ALL platforms however. If not (and if you have the option), you may want to use VTI. With VTI you dont haveto bother with crypto maps nor defining interesting traffic.

HTH

FrankGuthrie

Hi Caleb,


What is VTI? And I always thought that the cryptomap needs to be applied to an interface. However how do you apply it when you have mutiple customers peering to your device?

It look like tis configured in the running config, byt if it's not applied, how is it then used by the IPSEC VPN?

EMcCaleb

EMcCaleb wrote: »

Hello Frank

The crypto-map does not have to be under the VRF enabled sub-interface. Just make sure you specify the VRF under the isakmp profile. I'm not sure if this is supported on ALL platforms however. If not (and if you have the option), you may want to use VTI. With VTI you dont haveto bother with crypto maps nor defining interesting traffic.

HTH

Hello Frank,

VTI = Virtual Tunnel Interface.

VTI uses straight ESP encapsulation (no GRE required) and requires no crypto-map. It looks and feels like GRE with the exception that you have changed the tunnel mode and added a profile:

EX:
interface Tunnel0

ip vrf forwarding Franks_VRF
ip address 10.0.0.1 255.255.255.0
tunnel source 1.1.1.1
tunnel mode ipsec ipv4
tunnel destination 2.2.2.2
tunnel protection ipsec profile Franks_Profile

crypto ipsec transform-set Franks_Transform_Set ah-sha-hmac

crypto ipsec profile Franks_Profile
set transform-set Franks_Transform_Set

---

Those commands plus your ISAKMP policy are all you need. No crypto-map or having to define interesting traffic. You can then route over those VTI interfaces. VTI isn't one size fits all, but it eases complexity and makes troubleshooting a lot easier.

For your current solution, you do not need to have the crypto-map on the subinterface if you have the crypto-map on the main interface and the VRF is defined in the profile:

crypto isakmp profile FRANKS_PROFILE
vrf FRANKS_VRF
match identity address 10.0.0.2

HTH

FrankGuthrie

Hi Caleb,

Just to clarify,

We habe an outside interface to where out customers are peering to. When the traffic hits our VPN Router, it is split into VRF's.

However we have multiple customers peering to the outside interface. I thought we might have to apply all the cryptomaps to the physical outside interface?

As this is not the case i'm inclined to think that traffic is automatically linked to the crypotomaps, when it hits the ACL, or when traffic is generated from a certain peer.

EMcCaleb

Greetings Frank,

Yes, as long as the crypto profile specifies the VRF it can simply be applied to the main interface and NOT the sub-interface. However, I will acknowledge that this may be platform specific behavior. I would strongly recommend you lab this up in GNS3 to confirm and explore capabilities.