IPsec Virtual Tunnel Interface

IPsec VTIs allow you to configure a virtual interface to which you can apply features. Features for clear-text packets are configured on the VTI. Features for encrypted packets are applied on the physical outside interface. When IPsec VTIs are used, you can separate the application of features such as NAT, ACLs, and QoS and apply them to clear-text or encrypted text, or both. When crypto maps are used, there is no simple way to apply encryption features to the IPsec tunnel.

There are two types of VTI interfaces: static VTIs (SVTIs) and dynamic VTIs (DVTIs).

SVTI configurations can be used for site-to-site connectivity in which a tunnel provides always-on access between two sites. The advantage of using SVTIs as opposed to crypto map configurations is that users can enable dynamic routing protocols on the tunnel interface without the extra 24 bytes required for GRE headers, thus reducing the bandwidth for sending encrypted data.

Additionally, multiple Cisco IOS software features can be configured directly on the tunnel interface and on the physical egress interface of the tunnel interface. This direct configuration allows users to have solid control on the application of the features in the pre- or post-encryption path.

The figure below illustrates how a SVTI is used.

Figure 1

IPsec SVTI

The IPsec VTI supports native IPsec tunneling and exhibits most of the properties of a physical interface.

DVTIs can provide highly secure and scalable connectivity for remote-access VPNs. The DVTI technology replaces dynamic crypto maps and the dynamic hub-and-spoke method for establishing tunnels.

DVTIs can be used for both the server and remote configuration. The tunnels provide an on-demand separate virtual access interface for each VPN session. The configuration of the virtual access interfaces is cloned from a virtual template configuration, which includes the IPsec configuration and any Cisco IOS software feature configured on the virtual template interface, such as QoS, NetFlow, or ACLs.

DVTIs function like any other real interface so that you can apply QoS, firewall, other security services as soon as the tunnel is active. QoS features can be used to improve the performance of various applications across the network. Any combination of QoS features offered in Cisco IOS software can be used to support voice, video, or data applications.

DVTIs provide efficiency in the use of IP addresses and provide secure connectivity. DVTIs allow dynamically downloadable per-group and per-user policies to be configured on a RADIUS server. The per-group or per-user definition can be created using extended authentication (Xauth) User or Unity group, or it can be derived from a certificate. DVTIs are standards based, so interoperability in a multiple-vendor environment is supported. IPsec DVTIs allow you to create highly secure connectivity for remote access VPNs and can be combined with Cisco Architecture for Voice, Video, and Integrated Data (AVVID) to deliver converged voice, video, and data over IP networks. The DVTI simplifies Virtual Private Network (VRF) routing and forwarding- (VRF-) aware IPsec deployment. The VRF is configured on the interface.

A DVTI requires minimal configuration on the router. A single virtual template can be configured and cloned.

The DVTI creates an interface for IPsec sessions and uses the virtual template infrastructure for dynamic instantiation and management of dynamic IPsec VTIs. The virtual template infrastructure is extended to create dynamic virtual-access tunnel interfaces. DVTIs are used in hub-and-spoke configurations. A single DVTI can support several static VTIs.

Note	DVTI is supported only in Easy VPNs. That is, the DVTI end must be configured as an Easy VPN server.

figure below illustrates the DVTI authentication path.

Figure 2

Dynamic IPsec VTI

The authentication shown in the figure above follows this path:

1. User 1 calls the router.
2. Router 1 authenticates User 1.
3. IPsec clones virtual access interface from virtual template interface.

When an IPsec VTI is configured, encryption occurs in the tunnel. Traffic is encrypted when it is forwarded to the tunnel interface. Traffic forwarding is handled by the IP routing table, and dynamic or static routing can be used to route traffic to the SVTI. DVTI uses reverse route injection to further simplify the routing configurations. Using IP routing to forward the traffic to encryption simplifies the IPsec VPN configuration because the use of ACLs with a crypto map in native IPsec configurations is not required. The IPsec virtual tunnel also allows you to encrypt multicast traffic with IPsec.

IPsec packet flow into the IPsec tunnel is illustrated in the figure below.

Figure 3

Packet Flow into the IPsec Tunnel

After packets arrive on the inside interface, the forwarding engine switches the packets to the VTI, where they are encrypted. The encrypted packets are handed back to the forwarding engine, where they are switched through the outside interface.

The figue below shows the packet flow out of the IPsec tunnel.

Figure 4

Packet Flow out of the IPsec Tunnel

DVTI supports multiple IPsec SAs. The DVTI can accept multiple IPsec selectors that are proposed by the initiator.

The DVTIs allow per peer features to be applied on a dedicated interface. You can order features in such way that all features that are applied on the virtual access interfaces are applied before applying crypto. Additionally, all the features that are applied on the physical interfaces are applied after applying crypto. Clean routing is available across all VRFs so that there are no traffic leaks from one VRF to another before encrypting.

Multi-SA VTIs ensure interoperation with third-party devices and provide a flexible, clean, and modular feature set.

Multi-SA VTIs enable a clean Cisco IOS infrastructure, even when the Cisco IOS software interoperates with third-party devices that implement only crypto maps.

VRF and Scalability of the Baseline Configuration for IKEv1

Virtual access instances inherit the Inside-VRF (IVRF) from the template configuration. Users must configure several templates to enforce an appropriate IVRF for each customer. The number of templates must be equal to the number of customers connecting to the headend. Such a configuration is cumbersome and undesirable.

This complication can be avoided by allowing the IKE profile to override the virtual access VRF with the VRF configured on the IKE profile. An even better solution will be to allow the IKE profile to override the virtual access VRF using AAA, but this method is supported only for IKEv2.

This complication can be avoided by allowing the IKE profile to override the virtual access VRF with the VRF configured on the IKE profile. A better solution is to allow the IKE profile to override the virtual access VRF using AAA, but this method is supported only for IKEv2.

The VRF configured in the ISAKMP profile is applied to the virtual access first. Then the configuration from virtual template is applied to the virtual access. If your virtual template contains ip vrf forwarding command configuration, the VRF from the template overrides the VRF from the ISAKMP profile.

Rules for Initial Configuration of a VRF

The following rules must be applied during the initial configuration of VRF:

• If you configure IVRF in the IKE profile without configuring it in the virtual template, then you must apply the VRF from the IKE profile on each virtual access derived from this IKE profile.
• If you configure VRF in an IKE profile and virtual template, then the virtual template IVRF gets precedence.

Rules for Changing the VRF

If you change the VRF configured in an IKE profile, all the IKE SAs, IPsec SAs, and the virtual access identifier derived from this profile will get deleted. The same rule applies when the VRF is configured on the IKE profile for the first time.

The configuration of an IKEv2 profile in an IPsec profile on an IKEv2 responder is not mandatory. The IPSec DVTI sessions using the same virtual template can use different IKEv2 profiles, thus avoiding the need for a separate virtual template for each DVTI session that needs a different IKEv2 profile. Such an arrangement helps reduce the configuration size and save virtual template Interface Descriptor Block (IDB).

The IKEv2 authorization policy, which is a container of IKEv2 local AAA group authorization parameters, contains an AAA attribute AAA_AT_IPSEC_FLOW_LIMIT and theipsec flow- limit command. This attribute limits the number of IPsec flows that can terminate on an IPSec DVTI virtual access interface.

The value specified by the ipsec flow- limit command from the AAA overrides the value set by the set security-policy limit command from the IPSec profile. Any change to the value set by the set security-policy limit command in the IPSec profile is not applied to the current session but is applied to subsequent sessions.

If the value set by the set security-policy limit command is overridden by AAA, then the value from the IPSec profile is ignored, and any change to the value set by the set security-policy limit command in the IPSec profile does not affect the virtual access.

VRF and Scalability of Baseline Configuration for IKEv2

The IKEv2 multi-SA does not allow simultaneous configuration of a VRF and a template on the IKEv2 profile. Instead, the VRF can be configured on AAA and applied to the virtual access interface at the time of its creation.

You can use the AAA attribute INTERFACE_CONFIG to specify the ip vrf forwarding, ip unnumbered commands, and other interface configuration mode commands that are applied on the virtual access interface.

Note	If you override VRF using AAA, you must also specify the ip unnumbered command using AAA because the ip vrf forwarding command removes the ip unnumbered command configuration from the interface.

IPsec profiles define policy for DVTIs. The dynamic interface is created at the end of IKE Phase 1 and IKE Phase 1.5. The interface is deleted when the IPsec session to the peer is closed. The IPsec session is closed when both IKE and IPsec SAs to the peer are deleted.

Because VTIs are routable interfaces, routing plays an important role in the encryption process. Traffic is encrypted only if it is forwarded out of the VTI, and traffic arriving on the VTI is decrypted and routed accordingly. VTIs allow you to establish an encryption tunnel using a real interface as the tunnel endpoint. You can route to the interface or apply services such as QoS, firewalls, network address translation, and NetFlow statistics as you would to any other interface. You can monitor the interface and route to it, and it has an advantage over crypto maps because it is a real interface and provides the benefits of any other Cisco IOS interface.

1.    enable

2.    configure terminal

3.    crypto IPsec profile profile-name

4.    set transform-set transform-set-name [transform-set-name2...transform-set-name6]

5.   exit

6.    interface type number

7.    ip address address mask

8.    tunnel mode ipsec ipv4

9.    tunnel source interface-type interface-type

10.    tunnel destination ip-address

11.    tunnel protection IPsec profile profile-name [shared]

12.   end

1.    enable

2.    configure terminal

3.    crypto ipsec profile profile-name

4.    set transform-set transform-set-name [transform-set-name2...transform-set-name6]

5.    exit

6.    interface virtual-template number

7.    tunnel mode ipsec ipv4

8.    tunnel protection IPsec profile profile-name [shared]

9.    exit

10.    crypto isakamp profile profile-name

11.   match identity addressip-addressmask

12.    virtual template template-number

13.   end

1.    enable

2.   configure terminal

3.   ip vrf vrf-name

4.   rd route-distinguisher

5.   exit

6.   crypto keyring keyring-name

7.   pre-shared-keyaddress key key

8.   exit

9.   crypto isakmp profile profile-name

10.    keyring keyring-name

11.   match identity address mask

12.   virtual-template template-number

13.    exit

14.   crypto ipsec transform-set transform-set-name transform1 [transform2] [transform3]

15.   exit

16.   crypto ipsec profilename

17.   set security-policy limitmaximum-limit

18.   set transform-settransform-set-name [transform-set-name2 .... transform-set-name6]

19.   exit

20.   interface virtual-template number type tunnel

21.    ipvrfforwardingvrf-name

22.   ip unnumberedtype number

23.   tunnel modeipsec ipv4ipv4

24.   tunnelprotectionprofileipsec profile-name [shared]

25.   end

Router> enable  

Router# configure terminal

Router(config)# ip vrf VRF-100-1

Router(config-vrf)# rd 100:21

Router(config-vrf)# exit

Router(config)# crypto keyring cisco-100-1

Router(config-keyring)# pre-shared-key address
10.1.1.1 key cisco-100-1

Router(config-keyring)# exit

Router(config)# crypto isakmp profile
cisco-isakmp-profile-100-1

Router(conf-isa-prof)# keyring cisco-100-1

Router(conf-isa-prof)# match identity address
10.1.1.0 255.255.255.0

Router(conf-isa-prof)# virtual-template 101

Router(conf-isa-prof)# exit

Router(config)# crypto ipsec transform-set cisco
esp-3des esp-sha-hmac

Router(conf-crypto-trans)# exit

Router(config)# crypto ipsec profile
cisco-ipsec-profile-101

Router(ipsec-profile)# set security-policy
limit 3

Router(ipsec-profile)# set transform-set cisco

Router(ipsec-profile)# exit

Router(config)# interface virtual-template 101 type tunnel

Router(config-if)# ip vrf forwarding VRF-100-1

Router(config-if)# ip unnumbered GigabitEthernet 0.0

Router(config-if)# tunnel mode ipsec ipv4

Router(config-if)# tunnel protection ipsec
profile PROF

Router(config-if)# end

Perform the following tasks to configure Multi-SA for DVTIs using IKEv2

• Defining an AAA Attribute List
  
• Configuring the VRF
  
• Configuring Internet Key Exchange Version 2 (IKEv2)
  
• Configuring an IPsec Profile and a Virtual Template
  

• Example: Verifying the Results for the IPsec Static Virtual Tunnel Interface
  

• Verifying the Results for the Dynamic Virtual Tunnel Interface Easy VPN Server Example
  

• Verifying the Results for the Dynamic Virtual Tunnel Interface Easy VPN Client Example