IPsec Virtual Tunnel Interface

First Published: October 18, 2004 Last Updated: November 24, 2010

IP security (IPsec) virtual tunnel interfaces (VTIs) provide a routable interface type for terminating IPsec tunnels and an easy way to define protection between sites to form an overlay network. IPsec VTIs simplify configuration of IPsec for protection of remote links, support multicast, and simplify network management and load balancing.

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for IPsec Virtual Tunnel Interface" section.

Use Cisco Feature Navigator to find information about platform support and Cisco IOS XE software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.

The shared keyword is not required and must not be configured when using the tunnel mode ipsec ipv4 command for IPsec IPv4 mode.

Static VTIs Versus GRE Tunnels

The IPsec VTI is limited to IP unicast and multicast traffic only, as opposed to generic routing encapsulation (GRE) tunnels, which have a wider application for IPsec implementation.

VRF-Aware IPsec Configuration

In VRF-aware IPsec configurations with either SVTIs or Dynamic VTIs (DVTIs), the VRF must not be configured in the Internet Security Association and Key Management Protocol (ISAKMP) profile. Instead, the VRF must be configured on the tunnel interface for SVTIs. For DVTIs, you must apply VRF to the virtual template using the ip vrf forwarding command.

Information About IPsec Virtual Tunnel Interface

The use of IPsec VTIs both greatly simplifies the configuration process when you need to provide protection for remote access and provides a simpler alternative to using a generic routing encapsulation (GRE) tunnel for encapsulation and crypto maps with IPsec. A major benefit associated with IPsec VTIs is that the configuration does not require a static mapping of IPsec sessions to a physical interface. The IPsec tunnel endpoint is associated with an actual (virtual) interface. Because there is a routable interface at the tunnel endpoint, many common interface capabilities can be applied to the IPsec tunnel.

The IPsec VTI allows for the flexibility of sending and receiving both IP unicast and multicast encrypted traffic on any physical interface, such as in the case of multiple paths. Traffic is encrypted or decrypted when it is forwarded from or to the tunnel interface and is managed by the IP routing table. Using IP routing to forward the traffic to the tunnel interface simplifies the IPsec VPN configuration compared to the more complex process of using access control lists (ACLs) with the crypto map in native IPsec configurations. DVTIs function like any other real interface so that you can apply quality of service (QoS), firewall, and other security services as soon as the tunnel is active.

Without Virtual Private Network (VPN) Acceleration Module2+ (VAM2+) accelerating virtual interfaces, the packet traversing an IPsec virtual interface is directed to the router processor (RP) for encapsulation. This method tends to be slow and has limited scalability. In hardware crypto mode, all the IPsec VTIs are accelerated by the VAM2+ crypto engine, and all traffic going through the tunnel is encrypted and decrypted by the VAM2+.

Benefits of Using IPsec Virtual Tunnel Interfaces

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).

Static Virtual Tunnel Interfaces

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 XE 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.

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 XE 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 XE 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 (VPN) 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 in Easy VPNs. That is, the DVTI end must be configured as an Easy VPN server. DVTI can also be used in site-to-site scenarios.

Dynamic Virtual Tunnel Interface Life Cycle

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.

Routing with IPsec Virtual Tunnel Interfaces

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, andNetFlow statistics as you would to any other interface. You can monitor the interface, route to it, and it has an advantage over crypto maps because it is a real interface and provides the benefits of any other regular Cisco IOS XE interface.

Traffic Encryption with the IPsec Virtual Tunnel 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.

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.

Example: Static Virtual Tunnel Interface with IPsec

The following example configuration uses a preshared key for authentication between peers. VPN traffic is forwarded to the IPsec VTI for encryption and then sent out the physical interface. The tunnel on subnet 10 checks packets for IPsec policy and passes them to the Crypto Engine (CE) for IPsec encapsulation. Figure 6 illustrates the IPsec VTI configuration.

This section provides information that you can use to confirm that your configuration is working properly. In this display, Tunnel 0 is "up," and the line protocol is "up." If the line protocol is "down," the session is not active.

Example: VRF-Aware Static Virtual Tunnel Interface

To add VRF to the static VTI example, include the ip vrf and ip vrf forwarding commands to the configuration as shown in the following example:

Router Configuration

hostname ASR 1000-1

.

.

.

ip vrf sample-vti1

rd 1:1

route-target export 1:1

route-target import 1:1

!

.

.

.

interface Tunnel0

ip vrf forwarding sample-vti1

ip address 10.0.51.217 255.255.255.0

tunnel source 10.0.149.217

tunnel destination 10.0.149.203

tunnel mode ipsec ipv4

tunnel protection ipsec profile P1

.

.

.

!

end

Example: Static Virtual Tunnel Interface with QoS

You can apply any QoS policy to the tunnel endpoint by including the service-policy statement under the tunnel interface. The following example is policing traffic out the tunnelinterface:

Router Configuration

hostname router1

.

.

.

class-map match-all VTI

match any

!

policy-map VTI

class VTI

police cir 2000000

conform-action transmit

exceed-action drop

!

.

.

.

interface Tunnel0

ip address 10.0.51.217 255.255.255.0

tunnel source 10.0.149.217

tunnel destination 10.0.149.203

tunnel mode ipsec ipv4

tunnel protection ipsec profile P1

service-policy output VTI

!

.

.

.

!

end

Example: Static Virtual Tunnel Interface with Virtual Firewall

Applying the virtual firewall to the SVTI tunnel allows traffic from the spoke to pass through the hub to reach the Internet. Figure 7 illustrates a SVTI with the spoke protected inherently by the corporate firewall.

Figure 7 Static VTI with Virtual Firewall

The basic SVTI configuration has been modified to include the virtual firewall definition.

Router 1 Configuration

hostname ASR 1000-1

.

.

ip inspect max-incomplete high 1000000

ip inspect max-incomplete low 800000

ip inspect one-minute high 1000000

ip inspect one-minute low 800000

ip inspect tcp synwait-time 60

ip inspect tcp max-incomplete host 100000 block-time 2

ip inspect name IOSFW1 tcp timeout 300

ip inspect name IOSFW1 udp

!

.

.

.

interface GigabitEthernet0/1

description Internet Connection

ip address 172.18.143.246 255.255.255.0

ip access-group 100 in

ip nat outside

!

interface Tunnel0

ip address 10.0.51.217 255.255.255.0

ip nat inside

ip inspect IOSFW1 in

tunnel source 10.0.149.217

tunnel destination 10.0.149.203

tunnel mode ipsec ipv4

tunnel protection ipsec profile P1

!

ip classless

ip route 0.0.0.0 0.0.0.0 172.18.143.1

!

ip nat translation timeout 120

ip nat translation finrst-timeout 2

ip nat translation max-entries 300000

ip nat pool test1 10.2.100.1 10.2.100.50 netmask 255.255.255.0

ip nat inside source list 110 pool test1 vrf test-vti1 overload

!

access-list 100 permit esp any any

access-list 100 permit udp any eq isakmp any

access-list 100 permit udp any eq non500-isakmp any

access-list 100 permit icmp any any

access-list 110 deny esp any any

access-list 110 deny udp any eq isakmp any

access-list 110 permit ip any any

access-list 110 deny udp any eq non500-isakmp any

!

end

Example: Dynamic Virtual Tunnel Interface Easy VPN Server

The following example illustrates the use of the DVTI Easy VPN server, which serves as an IPsec remote access aggregator. The client can be a home user running a Cisco VPN client or it can be a Cisco IOS XE router configured as an Easy VPN client.

Example: Dynamic Virtual Tunnel Interface Easy VPN Client

The following example shows how you can set up a router as the Easy VPN client. This example uses basically the same idea as the Easy VPN client that you can run from a PC to connect. In fact, the configuration of the Easy VPN server works for the software client or the Cisco IOS XE client.

hostname ASR 1000

!

no aaa new-model

!

ip cef

!

username cisco password 0 cisco123

!

crypto ipsec client ezvpn CLIENT

connect manual

group group1 key cisco123

mode client

peer 172.18.143.246

virtual-interface 1

username cisco password cisco123

xauth userid mode local

!

interface Loopback0

ip address 10.1.1.1 255.255.255.255

!

interface FastEthernet0/0

description Internet Connection

ip address 172.18.143.208 255.255.255.0

crypto ipsec client ezvpn CLIENT

!

interface FastEthernet0/1

ip address 10.1.1.252 255.255.255.0

crypto ipsec client ezvpn CLIENT inside

!

interface Virtual-Template1 type tunnel

ip unnumbered Loopback0

!

ip route 0.0.0.0 0.0.0.0 172.18.143.1 254

!

end

The client definition can be set up in many different ways. The mode specified with the connect command can be automatic or manual. If the connect mode is set to manual, then the IPsec tunnel has to be initiated manually by a user.

Also note use of the mode command. The mode can be client, network-extension, or network-extension-plus. This example indicates client mode, which means that the client is given a private address from the server. Network-extension mode is different from client mode in that the client specifies for the server its attached private subnet. Depending on the mode, the routing table on either end is slightly different. The basic operation of the IPSec tunnel remains the same, regardless of the specified mode.

Example: VRF-Aware IPsec with Dynamic VTI When VRF Is Configured Under a Virtual Template

The following example shows how to configure VRF-Aware IPsec to take advantage of the DVTI:

hostname ASR 1000

.

.

.

ip vrf test-vti1

rd 1:1

route-target export 1:1

route-target import 1:1

!

.

.

.

interface Virtual-Template1 type tunnel

ip vrf forwarding test-vti1

ip unnumbered Loopback0

ip virtual-reassembly

tunnel mode ipsec ipv4

tunnel protection ipsec profile test-vti1

!

.

.

.

end

Example: VRF-Aware IPsec with Dynamic VTI When VRF Is Configured Under an ISAKMP Profile

The following example shows how to configure VRF-Aware IPsec to take advantage of the DVTI when VRF is configured under an ISAKMP profile:

hostname ASR 1000

.

.

.

ip vrf test-vti1

rd 1:1

route-target export 1:1

route-target import 1:1

!

.

.

.

crypto isakmp profile cisco-isakmp-profile

vrf test-vti1

keyring key

match identity address 4.0.0.22 255.255.255.255

!

.

.

.

interface Virtual-Template1 type tunnel

ip unnumbered Loopback0

ip virtual-reassembly

tunnel mode ipsec ipv4

tunnel protection ipsec profile test-vti1

!

.

.

end

Example: VRF-Aware IPsec with Dynamic VTI When VRF Is Configured Under Both a Virtual Template and an ISAKMP Profile

Note When separate VRFs are configured under isakmp profile and virtual-template, the VRF configured under virtual template takes precedence.

The following example shows how to configure VRF-Aware IPsec to take advantage of the DVTI when VRF is configured under both a virtual-template and an ISAKMP profile:

hostname ASR 1000

.

.

.

ip vrf test-vti2

rd 1:2

route-target export 1:1

route-target import 1:1

!

.

.

.

ip vrf test-vti1

rd 1:1

route-target export 1:1

route-target import 1:1

!

.

.

.

crypto isakmp profile cisco-isakmp-profile

vrf test-vti2

keyring key

match identity address 4.0.0.22 255.255.255.255

!

.

.

.

interface Virtual-Template1 type tunnel

ip vrf forwarding test-vti1

ip unnumbered Loopback0

ip virtual-reassembly

tunnel mode ipsec ipv4

tunnel protection ipsec profile test-vti1

!

.

.

.

end

Example: Dynamic Virtual Tunnel Interface with a Virtual Firewall

The DVTI Easy VPN server can be configured behind a virtual firewall. Behind-the-firewall configuration allows users to enter the network, while the network firewall is protected from unauthorized access. The virtual firewall uses Context-Based Access Control (CBAC) and NAT applied to the Internet interface as well as to the virtual template.

hostname ASR 1000

.

.

.

ip inspect max-incomplete high 1000000

ip inspect max-incomplete low 800000

ip inspect one-minute high 1000000

ip inspect one-minute low 800000

ip inspect tcp synwait-time 60

ip inspect tcp max-incomplete host 100000 block-time 2

ip inspect name IOSFW1 tcp timeout 300

ip inspect name IOSFW1 udp

!

.

.

.

interface GigabitEthernet0/1

description Internet Connection

ip address 172.18.143.246 255.255.255.0

ip access-group 100 in

ip nat outside

!

interface GigabitEthernet0/2

description Internal Network

ip address 10.2.1.1 255.255.255.0

!

interface Virtual-Template1 type tunnel

ip unnumbered Loopback0

ip nat inside

ip inspect IOSFW1 in

tunnel mode ipsec ipv4

tunnel protection ipsec profile test-vti1

!

ip classless

ip route 0.0.0.0 0.0.0.0 172.18.143.1

!

ip nat translation timeout 120

ip nat translation finrst-timeout 2

ip nat translation max-entries 300000

ip nat pool test1 10.2.100.1 10.2.100.50 netmask 255.255.255.0

ip nat inside source list 110 pool test1 vrf test-vti1 overload

!

access-list 100 permit esp any any

access-list 100 permit udp any eq isakmp any

access-list 100 permit udp any eq non500-isakmp any

access-list 100 permit icmp any any

access-list 110 deny esp any any

access-list 110 deny udp any eq isakmp any

access-list 110 permit ip any any

access-list 110 deny udp any eq non500-isakmp any

!

end

Example: Dynamic Virtual Tunnel Interface with QoS

You can add QoS to the DVTI tunnel by applying the service policy to the virtual template. When the template is cloned to make the virtual-access interface, the service policy is applied there. The following example shows the basic DVTI configuration with QoS added:

RFCs

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

Feature Information for IPsec Virtual Tunnel Interface

Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.

Note lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Table 1 Feature Information for IPsec Virtual Tunnel Interface

Feature Name

Releases

Feature Configuration Information

Static IPsec VTIs

Cisco IOS XE Release 2.1

IPsec VTIs provide a routable interface type for terminating IPsec tunnels and an easy way to define protection between sites to form an overlay network. IPsec VTIs simplify configuration of IPsec for protection of remote links, support multicast, and simplify network management and load balancing.

The following commands were introduced or modified: crypto isakmp profile, interface virtual-template, show vtemplate, tunnel mode.

Dynamic IPsec VTIs

Cisco IOS XE Release 2.1

Dynamic VTIs provide efficiency in the use of IP addresses and provide secure connectivity. Dynamic VTIs 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 Xauth User or Unity group, or it can be derived from a certificate. Dynamic VTIs are standards based, so interoperability in a multiple-vendor environment is supported. IPsec dynamic VTIs allow you to create highly secure connectivity for remote access VPNs and can be combined with Cisco AVVID to deliver converged voice, video, and data over IP networks. The dynamic VTI simplifies VRF-aware IPsec deployment. The VRF is configured on the interface.

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

The following commands were introduced or modified: set security-policy limit, set reverse-route.

Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)

Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.