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.

[Rob Ingram]

@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:- https://integratingit.wordpress.com/2023/03/07/asa-dynamic-vti/

[j.a.m.e.s]

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

[Rob Ingram]

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

[MHM Cisco World]

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.

MHM

[j.a.m.e.s]

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

[MHM Cisco World]

No 

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.

MHM

[j.a.m.e.s]

@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> 10.1.0.0 255.255.255.248 <far-end-tunnel-ip>

[MHM Cisco World]

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

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

MHM

[Rob Ingram]

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

[j.a.m.e.s]

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.

[j.a.m.e.s]

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 192.168.0.0 255.255.255.254 <- Do we really need this for STATIC routes only
 tunnel source interface outside
 tunnel destination 170.0.0.1
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile PR-THIRDPARTY
exit

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

route <vti-ifname> 10.1.0.0 255.255.255.248

[MHM Cisco World]

share topolgy' let me check best solution here.

Thanks 

MHM

[Rob Ingram]

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

[MHM Cisco World]

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