Contents

Introduction

Prerequisites

Requirements

Components Used

Background Information

Advantages of VTIs over Crypto Maps

Configure

Network Diagram

Routing Considerations

Configuration Examples

Migration of a Crypto Map-Based IKEv1 Tunnel to a Multi-SA sVTI

Migration of a Crypto Map Based IKEv2 Tunnel to a Multi-SA sVTI

Migration of a VRF-Aware Crypto Map to a Multi-SA VTI

Verify

Troubleshoot

Frequently Asked Questions

Introduction

This document describes how to configure a multi-security association (Multi-SA) Virtual Tunnel Interface (VTI) on Cisco routers with Cisco IOS® XE software. The migration process is also described. Multi-SA VTI is a replacement for the crypto map-based (policy-based) VPN configuration. It is backwards compatible with crypto map-based and other policy-based implementations. Support for this feature is available in Cisco IOS XE Release 16.12 and later.

Prerequisites

Requirements

Cisco recommends that you have knowledge of an IPsec VPN configuration on Cisco IOS XE routers.

Components Used

The information in this document is based on an Integrated Services Router (ISR) 4351 with Cisco IOS XE Release 16.12.01a .

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

Background Information

Advantages of VTIs over Crypto Maps

A crypto map is an output feature of the physical interface. Tunnels to different peers are configured under the same crypto map. The crypto map Access Control List (ACL) entries are used to match the traffic to be sent to a specific VPN peer. This type of configuration is also called a policy-based VPN.

In the case of VTIs, each VPN tunnel is represented by a separate logical tunnel interface. The routing table decides to which VPN peer the traffic is sent. This type of configuration is also called a route-based VPN.

In releases earlier than Cisco IOS XE Release 16.12, the VTI configuration was not compatible with the crypto map configuration. Both ends of the tunnel had to be configured with the same type of VPN in order to interoperate.

In Cisco IOS XE Release 16.12, new configuration options have been added that allow the tunnel interface to act as a policy-based VPN on the protocol level, but have all properties of the tunnel interface.

Cisco announced the end-of-life dates for the Cisco IPsec Static Crypto Map and Dynamic Crypto Map feature in Cisco IOS XE Release 17.6.

The advantages of VTI over crypto map include:

- It is easier to determine the tunnel up/down status.

- It is easier to troubleshoot.

- It has the ability to apply features like Quality of Service (QoS), Zone-Based Firewall (ZBF), Network Address Translation (NAT), and Netflow on a per-tunnel basis.

- It has a streamlined configuration for all types of VPN tunnels.

Configure

Network Diagram

Routing Considerations

The administrator must ensure that the routing for remote networks points towards the tunnel interface. The reverse-route option under the IPsec profile can be used to automatically create static routes for the networks specified in the crypto ACL. Such routes can also be added manually. If there are previously configured more specific routes, that point towards a physical interface instead of the tunnel interface, these must be removed.

Configuration Examples

Migration of a Crypto Map-Based IKEv1 Tunnel to a Multi-SA sVTI

Both routers are preconfigured with the Internet Key Exchange Version 1 (IKEv1) crypto map-based solution:

Router A

crypto isakmp policy 10

encryption aes

hash sha256

authentication pre-share

group 14

!

crypto isakmp key cisco123 address 192.0.2.2

!

crypto ipsec transform-set TSET esp-aes 256 esp-sha256-hmac

!

crypto map CMAP 10 ipsec-isakmp

set peer 192.0.2.2

set transform-set TSET

match address CACL

!

ip access-list extended CACL

permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

permit ip 172.16.1.0 0.0.0.255 172.16.2.0 0.0.0.255

!

interface GigabitEthernet0/0/0

ip address 192.0.2.1 255.255.255.0

crypto map CMAP

Router B

crypto isakmp policy 10

encryption aes

hash sha256

authentication pre-share

group 14

!

crypto isakmp key cisco123 address 192.0.2.1

!

crypto ipsec transform-set TSET esp-aes 256 esp-sha256-hmac

!

crypto map CMAP 10 ipsec-isakmp

set peer 192.0.2.1

set transform-set TSET

match address CACL

!

ip access-list extended CACL

permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255

permit ip 172.16.2.0 0.0.0.255 172.16.1.0 0.0.0.255

!

interface GigabitEthernet0/0/0

ip address 192.0.2.2 255.255.255.0

crypto map CMAP

In order to migrate Router A to a multi-SA VTI configuration, complete these steps. Router B can remain with the old configuration or it can be reconfigured similarly:

1. Remove the crypto map from the interface:
interface GigabitEthernet0/0/0

no crypto map

2. Create the IPsec profile. Reverse-route is optionally configured to have the static routes for remote networks automatically added to the routing table:
crypto ipsec profile PROF

set transform-set TSET

reverse-route

3. Configure the tunnel interface. The crypto ACL is attached to the tunnel configuration as an IPsec policy. The IP address configured on the tunnel interface is irrelevant, but it must be configured with some value. The IP address can be borrowed from the physical interface with the ip unnumbered command:
interface Tunnel0

ip unnumbered GigabitEthernet0/0/0

tunnel source GigabitEthernet0/0/0

tunnel mode ipsec ipv4

tunnel destination 192.0.2.2

tunnel protection ipsec policy ipv4 CACL

tunnel protection ipsec profile PROF

4. The crypto map entry can be removed completely afterwards:
no crypto map CMAP 10

Final Router A Configuration

crypto isakmp policy 10

encryption aes

hash sha256

authentication pre-share

group 14

!

crypto isakmp key cisco123 address 192.0.2.2

!

crypto ipsec transform-set TSET esp-aes 256 esp-sha256-hmac

!

crypto ipsec profile PROF

set transform-set TSET

reverse-route

!

ip access-list extended CACL

permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

permit ip 172.16.1.0 0.0.0.255 172.16.2.0 0.0.0.255

!

interface GigabitEthernet0/0/0

ip address 192.0.2.1 255.255.255.0

!

interface Tunnel0

ip unnumbered GigabitEthernet0/0/0

tunnel source GigabitEthernet0/0/0

tunnel mode ipsec ipv4

tunnel destination 192.0.2.2

tunnel protection ipsec policy ipv4 CACL

tunnel protection ipsec profile PROF

Migration of a Crypto Map Based IKEv2 Tunnel to a Multi-SA sVTI

Both routers are preconfigured with the Internet Key Exchange Version 2 (IKEv2) crypto map-based solution:

Router A

crypto ipsec transform-set TSET esp-aes 256 esp-sha256-hmac

!

crypto ikev2 profile PROF

match identity remote address 192.0.2.2 255.255.255.255

authentication remote pre-share key cisco123

authentication local pre-share key cisco123

!

crypto map CMAP 10 ipsec-isakmp

set peer 192.0.2.2

set transform-set TSET

set ikev2-profile PROF

match address CACL

!

ip access-list extended CACL

permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

permit ip 172.16.1.0 0.0.0.255 172.16.2.0 0.0.0.255

!

interface GigabitEthernet0/0/0

ip address 192.0.2.1 255.255.255.0

crypto map CMAP

Router B

crypto ipsec transform-set TSET esp-aes 256 esp-sha256-hmac

!

crypto ikev2 profile PROF

match identity remote address 192.0.2.1 255.255.255.255

authentication remote pre-share key cisco123

authentication local pre-share key cisco123

!

crypto map CMAP 10 ipsec-isakmp

set peer 192.0.2.1

set transform-set TSET

set ikev2-profile PROF

match address CACL

!

ip access-list extended CACL

permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255

permit ip 172.16.2.0 0.0.0.255 172.16.1.0 0.0.0.255

!

interface GigabitEthernet0/0/0

ip address 192.0.2.2 255.255.255.0

crypto map CMAP

In order to migrate Router A to a multi-SA VTI configuration, complete these steps. Router B can remain with the old configuration or it can be reconfigured similarly.

1. Remove the crypto map from the interface:
interface GigabitEthernet0/0/0

no crypto map

2. Create the IPsec profile. The reverse-route command is optionally configured to have the static routes for remote networks automatically added to the routing table:
crypto ipsec profile PROF

set transform-set TSET

set ikev2-profile PROF

reverse-route

3. Configure the tunnel interface. The crypto ACL is attached to the tunnel configuration as an IPsec policy. The IP address configured on the tunnel interface is irrelevant, but it must be configured with some value. The IP address can be borrowed from the physical interface with the ip unnumbered command:
interface Tunnel0

ip unnumbered GigabitEthernet0/0/0

tunnel source GigabitEthernet0/0/0

tunnel mode ipsec ipv4

tunnel destination 192.0.2.2

tunnel protection ipsec policy ipv4 CACL

tunnel protection ipsec profile PROF

4. Remove the crypto map completely afterwards:
no crypto map CMAP 10

Final Router A Configuration

crypto ipsec transform-set TSET esp-aes 256 esp-sha256-hmac

!

crypto ikev2 profile PROF

match identity remote address 192.0.2.2 255.255.255.255

authentication remote pre-share key cisco123

authentication local pre-share key cisco123

!

crypto ipsec profile PROF

set transform-set TSET

set ikev2-profile PROF

reverse-route

!

ip access-list extended CACL

permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

permit ip 172.16.1.0 0.0.0.255 172.16.2.0 0.0.0.255

!

interface GigabitEthernet0/0/0

ip address 192.0.2.1 255.255.255.0

!

interface Tunnel0

ip unnumbered GigabitEthernet0/0/0

tunnel source GigabitEthernet0/0/0

tunnel mode ipsec ipv4

tunnel destination 192.0.2.2

tunnel protection ipsec policy ipv4 CACL

tunnel protection ipsec profile PROF

Migration of a VRF-Aware Crypto Map to a Multi-SA VTI

This example shows how to migrate the VRF-aware crypto map configuration.

Topology

Crypto Map Configuration

ip vrf fvrf

ip vrf ivrf

!

crypto keyring KEY vrf fvrf

pre-shared-key address 192.0.2.2 key cisco123

!

crypto isakmp policy 10

encryption aes

hash sha256

authentication pre-share

group 14

!

crypto isakmp profile PROF

vrf ivrf

keyring KEY

match identity address 192.0.2.2 255.255.255.255 fvrf

!

crypto ipsec transform-set TSET esp-aes 256 esp-sha256-hmac

!

crypto map CMAP 10 ipsec-isakmp

set peer 192.0.2.2

set transform-set TSET

set isakmp-profile PROF

match address CACL

!

interface GigabitEthernet0/0/0

ip vrf forwarding fvrf

ip address 192.0.2.1 255.255.255.0

crypto map CMAP

!

interface GigabitEthernet0/0/1

ip vrf forwarding ivrf

ip address 192.168.1.1 255.255.255.0

!

ip route vrf ivrf 172.16.2.0 255.255.255.0 GigabitEthernet0/0/0 192.0.2.2

ip route vrf ivrf 192.168.2.0 255.255.255.0 GigabitEthernet0/0/0 192.0.2.2

!

ip access-list extended CACL

permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

permit ip 172.16.1.0 0.0.0.255 172.16.2.0 0.0.0.255

These are the steps required to migrate to multi-SA VTI:

! vrf configuration under isakmp profile is only for crypto map based configuration

!

crypto isakmp profile PROF

no vrf ivrf

!

interface GigabitEthernet0/0/0

no crypto map

!

no crypto map CMAP 10

!

no ip route vrf ivrf 172.16.2.0 255.255.255.0 GigabitEthernet0/0/0 192.0.2.2

no ip route vrf ivrf 192.168.2.0 255.255.255.0 GigabitEthernet0/0/0 192.0.2.2

!

crypto ipsec profile PROF

set transform-set TSET

set isakmp-profile PROF

reverse-route

!

interface tunnel0

ip vrf forwarding ivrf

ip unnumbered GigabitEthernet0/0/0

tunnel source GigabitEthernet0/0/0

tunnel mode ipsec ipv4

tunnel destination 192.0.2.2

tunnel vrf fvrf

tunnel protection ipsec policy ipv4 CACL

tunnel protection ipsec profile PROF

Final VRF-Aware Configuration

ip vrf fvrf

ip vrf ivrf

!

crypto keyring KEY vrf fvrf

pre-shared-key address 192.0.2.2 key cisco123

!

crypto isakmp policy 10

encryption aes

hash sha256

authentication pre-share

group 14

!

crypto isakmp profile PROF

keyring KEY

match identity address 192.0.2.2 255.255.255.255 fvrf

!

crypto ipsec transform-set TSET esp-aes 256 esp-sha256-hmac

!

interface GigabitEthernet0/0/0

ip vrf forwarding fvrf

ip address 192.0.2.1 255.255.255.0

!

interface GigabitEthernet0/0/1

ip vrf forwarding ivrf

ip address 192.168.1.1 255.255.255.0

!

ip access-list extended CACL

permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

permit ip 172.16.1.0 0.0.0.255 172.16.2.0 0.0.0.255

!

crypto ipsec profile PROF

set transform-set TSET

set isakmp-profile PROF

reverse-route

!

interface tunnel0

ip vrf forwarding ivrf

ip unnumbered GigabitEthernet0/0/0

tunnel source GigabitEthernet0/0/0

tunnel mode ipsec ipv4

tunnel destination 192.0.2.2

tunnel vrf fvrf

tunnel protection ipsec policy ipv4 CACL

tunnel protection ipsec profile PROF

Verify

Use this section in order to confirm that your configuration works properly.

The Cisco CLI Analyzer (registered customers only) supports certain show commands. Use the Cisco CLI Analyzer in order to view an analysis of show command output.

In order to verify if the tunnel has been negotiated successfully, the tunnel interface status can be checked. The last two columns - Status and Protocol - show a status of up when the tunnel is operational:

RouterA#show ip interface brief | include Interface|Tunnel0

Interface              IP-Address      OK? Method Status                Protocol

Tunnel0                192.0.2.1       YES TFTP   up                    up

More details about the current crypto session status can be found in the show crypto session output. The Session status of UP-ACTIVE indicates that the IKE session has been negotiated properly:

RouterA#show crypto session interface tunnel0

Crypto session current status

Interface: Tunnel0

Profile: PROF

Session status: UP-ACTIVE

Peer: 192.0.2.2 port 500

Session ID: 2

IKEv2 SA: local 192.0.2.1/500 remote 192.0.2.2/500 Active

IPSEC FLOW: permit ip 172.16.1.0/255.255.255.0 172.16.2.0/255.255.255.0

Active SAs: 2, origin: crypto map

IPSEC FLOW: permit ip 192.168.1.0/255.255.255.0 192.168.2.0/255.255.255.0

Active SAs: 2, origin: crypto map

Verify that the routing to the remote network points over the correct tunnel interface:

RouterA#show ip route 192.168.2.0

Routing entry for 192.168.2.0/24

Known via "static", distance 1, metric 0 (connected)

Routing Descriptor Blocks:

* directly connected, via Tunnel0

Route metric is 0, traffic share count is 1

RouterA#show ip cef 192.168.2.100

192.168.2.0/24

attached to Tunnel0

Troubleshoot

This section provides information you can use in order to troubleshoot your configuration.

In order to troubleshoot the IKE protocol negotiation, use these debugs:

Note: Refer to Important Information on Debug Commands before you use debug commands.

! For IKEv1-based scenarios:

debug crypto isakmp

debug crypto ipsec

! For IKEv2-based scenarios:

debug crypto ikev2

debug crypto ipsec

Frequently Asked Questions

Does the tunnel come up automatically or is traffic needed to bring up the tunnel?

Unlike with crypto maps, the multi-SA VTI tunnels come up automatically regardless of whether data traffic that matches the crypto ACL flows over the router or not. The tunnels stay up all the time, even if there is no interesting traffic.

What happens if traffic is routed through the VTI, but the source or destination of the traffic does not match the crypto ACL configured as an IPsec policy for this tunnel?

Such a scenario is not supported. Only the traffic intended to be encrypted must be routed to the tunnel interface. Policy-based routing (PBR) can be used to route only specific traffic to the VTI. PBR can use the IPsec policy ACL to match the traffic to be routed to the VTI.

Each packet is checked against the configured IPsec policy and must match the crypto ACL. If it does not match, it is not encrypted and is sent in clear text out of the tunnel source interface.

In case the same internal VRF (iVRF) and front VRF (fVRF) is used (iVRF = fVRF), this results in a routing loop and the packets are dropped with a reason Ipv4RoutingErr. Statistics for such drops can be seen with the show platform hardware qfp active statistics drop command:

RouterA#show platform hardware qfp active statistics drop

Last clearing of QFP drops statistics : never

-------------------------------------------------------------------------

Global Drop Stats Packets Octets

-------------------------------------------------------------------------

Ipv4RoutingErr    5       500

In case iVRF is different than fVRF, the packets that enter the tunnel in iVRF, and do not match the IPsec policy, exit the tunnel source interface in fVRF in clear text. They are not dropped, as there is no routing loop between the VRFs.

Are features like VRF, NAT, QoS, and so on, supported on multi-SA VTI?

Yes, all of those features are supported the same way as on regular VTI tunnels.