Migrating ASA CryptoMap Ipsec to VTI

[j.a.m.e.s]

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 10.0.0.0 255.255.255.248 10.1.0.0 255.255.255.248
interface Tunnel 1
  tunnel protection ipsec policy CACL-THIRDPARTYA
exit
!
crypto ipsec profile PR-THIRDPARTYA
 [...]
 set reverse-route
exit

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
exit
! 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.

[j.a.m.e.s]

@MHM Cisco World Thank you very much for taking the time to lab this up. In my tests though on the ASAv v9.20 code, invalid PSK was also brining the tun if status down. It's possible that ASA and IOS-XE behave differently.

[MHM Cisco World]

I will make double check

Thanks 

MHM

[MHM Cisco World]

hi friend 
you are correct 
the tunnel mode I was use is IPsec over GRE so the tunnel not effect by IPSec
so 
I add 
tunnel mode ipsec ipv4 
change the tunnel to IPsec SVTI and then tunnel UP when IPsec is ON 
so ASA and IOS for sVTI is same the tunnel depend on status of IPsec 
thanks 
MHM
and the tunnel is UP imm

[j.a.m.e.s]

Thank you @Rob Ingram . I think this is the answer I'm looking for. Give me a couple of days to test RRI/tunnel protection ipsec policy and the static routes. I will also test the ACLs and VPNFilters and report back here.

[j.a.m.e.s]

So the results are in...and there is some good news for v9.20 code.

• The VTI (show interface tunX) showed down either when the tunnel destination was unavailable or when I entered an invalid PSK under the tunnel-group
• To get RRI working I needed to attach the traffic selector (tunnel protection ipsec profile xxx) on the vti. Without this, the RRI ('V' route) was not present in the RIB.
• A VPN filter list in the group-policy was working, with it's unusual ACE syntax (vpn-filter value xxx)
• Access lists applied on the vti were working with the normal ACE syntax. They certainly were filtering outgoing traffic.
• After changing paramters on the group-policy and tunnel-group it was necessary to shut/no shut the vti

The only other thing to call out is that I needed to apply "next-hop-self" on my iBGP neighbors following the upgrade to v9.20 - presumably the introduction of loopback support has led to some changes in the BGP implementation.