Showing results for 
Search instead for 
Did you mean: 

Migrating ASA CryptoMap Ipsec to VTI

Level 3
Level 3

Hi Eveyone,

I've noticed (via the release notes) some improvements to VTI in ASA v9.19/9.20 and have decided it's time for a CryptoMap -> VTI migration.

Could I ask a few questions please?

1. To get RRI working with an ASA VTI, do we need to attach a tunnel protection ipsec policy ?


access-list CACL-THIRDPARTYA extended permit ip
interface Tunnel 1
  tunnel protection ipsec policy CACL-THIRDPARTYA
crypto ipsec profile PR-THIRDPARTYA
 set reverse-route


The config guide explains that without the above it will use traffic selectors of "any/any" so I suspect the protection ipsec policy is needed to generate those routes which show up "V" with "show route".


2. The VPN Config Guide mentions ACLs can be attached to the VTI


! Old - Cryto Map filtering with VPN Filter List:
group-policy GP_L2L_170.0.0.1 attributes
 vpn-filter value VFL-THIRDPARTY-INOUT
! New - VTI Filtering
access-group VCL-THIRDPARTY-INOUT in  interface vti-name
access-group VCL-THIRDPARTY-INOUT out interface vti-name


Exciting stuff! I would like to be rid of those of those old filter lists with the odd syntax. Has anyone tried filtering the VTI?

Thanks in advance for any insights.


19 Replies 19

@j.a.m.e.s a more elegant solution (IMO) if you configure a dVTI on the hub and sVTI on the spokes and use a routing protocol over the tunnel, therefore you don't need RRI, ACL or a policy and you have a "any any" for the traffic selectors. You would need to set "ikev2 route set interface" under the tunnel group, this enables unicast reachability between the VTI interfaces for BGP to work over the tunnel. Example:-


@Rob Ingram Thank you Rob, I completely agree but these tunnels are towards third parties. VPN is often stretching their knowledge, I just don't think I'm going to get agreement for BGP, OSPF etc.

@j.a.m.e.s ok then the method you propose creates multi SAs (as per the ACL) not a normal VTI, this is used when the peer is still using a policy based VPN. RRI will advertise the routes once the tunnel is established or just define a static route on the ASA to the remote tunnel.

No need RRI in VTI (and I think it not work also)

You need static route toward tunnel'

If tunnel is UP then this static route will appear in RIB if tunnel down the static route will disappear.


Level 3
Level 3

@MHM Cisco World I see, so the static route will go down anyway if the IPSec negotiation fails, for example? Assuming that's the case, what brings up the VTI initially incidentally? I can see a chicken-and-egg problem here...


The staitc route for tunnel destination is different than static route use for Subnet reachable via tunnel.

Note:- For tunnel destination you can use defualt route.


Level 3
Level 3

@MHM Cisco World I understand that the underlay route to the tunnel destination route would be different from the overlay route, but what is concerning me is what brings and keeps the tunnel (i.e. the VTI) in the "UP" state in order to make the overlay route stable?

Presumably this the correct way to configure the overlay route on the ASA?

route <vti-ifname> <far-end-tunnel-ip>



route <vti-ifname> <far-end-tunnel-ip>

This is totally correct' use the far end tunnel IP as next-hop IP.


@j.a.m.e.s Unlike with crypto map policy based VPN, the Multi SA VTI tunnels come up automatically regardless of whether interesting traffic is generated and the tunnels stay up all the time, even if there is no interesting traffic.

Level 3
Level 3

Thank you @MHM Cisco World . I just realised you helped me in a previous post and I can see that if the "tunnel destination" is in the RIB, then the VTI will be UP => hence the static route will be injected. This is good news because I'm going to redistribute that static into my LAN using BGP to bring traffic to the ASA.

Level 3
Level 3

My only concern with this is that if the VTI will be UP (pretty much always) and hence the static route is UP pretty much always, a failover to the ASA at the other datacentre may not take place when needed. Perhaps RRI + Tunnel Selectors might be a better choice considering failover requirements...I will do some testing.

One other thought...since these VTIs will have static routes, do I really need an "IP Address" on the VTI Tunnel interface?


interface Tunnel 1
 nameif vti-thirdparty
 ip address <- Do we really need this for STATIC routes only
 tunnel source interface outside
 tunnel destination
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile PR-THIRDPARTY


 This would mean specifying a static route without a far-end-ip, i.e.

route <vti-ifname>


share topolgy' let me check best solution here.



@j.a.m.e.s the VTI still needs an IP address, but it is irrelevant when the peer is still a policy based VPN, but it must be configured with some value. You can use ip unnumbered to borrow the IP address from the physical interface (or use a loopback).

If you want failover to another DC then use RRI to advertise those specific traffic selectors and use a dynamic routing protocol within your network.

Your example above does not include tunnel protection ipsec policy so the traffic selectors will be any any and therefore cause a problem when the third party VPN is a policy based VPN.


The VTI Down Issue 
when the VTI tunnel will be Down 
1- tunnel UP even if the IPSec is not form between two Peers (this point is show in lab below, I wait until I check to reply you)
2- tunnel Down when the Tunnel destination is unreachable 
what I meaning 

interface tunnel x 
ip add x.x.x.x <<- this can be IP or can use LO as unnumbered (not all ASA support LO) and I prefer IP to monitor and check the health of tunnel  
tunnel source 
tunnel destination <<- this is unreachable 

Screenshot (98).png

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: