Configure Multi-SA Virtual Tunnel Interface on IOS-XE router

Introduction

This document describes how to configure multi security association Virtual Tunnel Interface on IOS-XE router. Migration process is also described. Multi-SA VTI is a replacement for crypto map based (policy based) virtual private network configuration. It is backwards compatible with crypto map based and other policy based implementations. Support for this features is available since IOS-XE 16.12 release.

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

• IPsec Virtual Private Network configuration on IOS-XE routers

Components Used

The information in this document is based on ISR 4351 routers running IOS-XE 16.12.01a software version.

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.

Advantages of Virtual Tunnel Interfaces over Crypto maps

Crypto map is an output feature of physical interface. Tunnels to different peers are configured under the same crypto map. Access-list entries specify to which peer traffic should be sent to. This type of configuration is also called policy-based VPN.

If Virtual Tunnel Interfaces are utilized, each VPN tunnel is represented by a separate logical tunnel interface. Routing table decides to which peer traffic should be sent to. This type of configuration is also called route-based VPN.

Prior to IOS-XE 16.12 release, the VTI configuration was not compatible with crypto map configuration. Both ends of the tunnel had to be configured with the same type of VPN to interoperate.

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

The advantages of VTI over crypto map include:

• Easier to determine tunnel up/down status
• Easier to troubleshoot
• Ability to apply features like QoS, ZBF, NAT, Netflow on a per-tunnel basis
• Streamlined configuration for all types of VPN tunnels

Configure

Network Diagram

Configurations

IKEv1

Both routers are preconfigured with 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 the Router A to a multi-SA VTI configuration, the following must be configured. Router B can remain with old configuraion or can be reconfigured similarly:

1. Remove the crypto map from the interface:

interface GigabitEthernet0/0/0
 no crypto map

2. Create 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 tunnel interface. Crypto access-list is attached to the tunnel configuration as ipsec policy. IP address configured on the tunnel interface is irrelevant but it must be configured with some value. IP address can be borrowed from physical interface using "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. Crypto map 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

IKEv2

Both routers are preconfigured with 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 the Router A to a multi-SA VTI configuration, the following must be configured. Router B can remain with old configuraion or can be reconfigured similarly:

1. Remove the crypto map from the interface:

interface GigabitEthernet0/0/0
 no crypto map

2. Create 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 
 set ikev2-profile PROF
 reverse-route

3. Configure tunnel interface. Crypto access-list is attached to the tunnel configuration as ipsec policy. IP address configured on the tunnel interface is irrelevant but it must be configured with some value. IP address can be borrowed from physical interface using "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. Crypto map can be removed 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

Routing considerations

Administrator must ensure that the routing for remote networks is pointing towards the tunnel interface. "Reverse-route" option under ipsec profile can be used to automatically create static routes for networks specified in the crypto ACL. Such routes can also be added manually. If there were preexisting more specific routes pointing towards physical interface instead of tunnel interface, these must be removed.

VRF-aware configuration

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

In order to migrate to multi-SA VTI, the following steps must be performed:

! 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

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" columns - should indicated "up" status:

RouterA#show ip interface brief | i Tunnel0
Tunnel0 192.0.2.1 YES TFTP up up

More details about current crypto session status can be found in "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

Frequently Asked Questions

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

A: Unlike with crypto maps, the multi-SA VTI tunnels come up automatically regardless of whether data traffic matching the crypto ACL is currently being routed. The tunnels stay up all the time even if the traffic stops flowing.

Q: 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 ipsec policy for this tunnel?

A: Such traffic will be dropped. Each packet is checked against the configured ipsec policy and must match the crypto ACL. The reason for such drop is registered as "Ipv4RoutingErr". Statistics for such drops can be found through the following command:

RouterA#show platform hardware qfp active statistics drop 
Last clearing of QFP drops statistics : never

-------------------------------------------------------------------------
Global Drop Stats Packets Octets 
-------------------------------------------------------------------------
Ipv4RoutingErr    5       500

Q: Are features like VRF, NAT, QoS etc. supported on multi-SA VTI?

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

Troubleshoot

In order to troubleshoot the IKE protocol negotiation, the following debugs can be used:

! For IKEv1-based scenarios:
debug crypto isakmp
debug crypto ipsec

! For IKEv2-based scenarios:
debug crypto ikev2
debug crypto ipsec