02-11-2024 08:35 AM - edited 02-11-2024 08:37 AM
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.
02-11-2024 08:44 AM - edited 02-11-2024 08:45 AM
@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/
02-11-2024 09:00 AM
@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.
02-11-2024 09:26 AM
@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.
02-11-2024 08:52 AM
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
02-11-2024 09:04 AM
@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...
02-11-2024 09:07 AM
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
02-11-2024 09:19 AM - edited 02-11-2024 09:20 AM
@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>
02-11-2024 09:27 AM
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
02-11-2024 09:46 AM
@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.
02-11-2024 09:48 AM
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.
02-11-2024 09:58 AM
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
02-11-2024 10:02 AM
share topolgy' let me check best solution here.
Thanks
MHM
02-11-2024 10:09 AM
@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.
02-12-2024 06:45 AM - edited 02-12-2024 06:45 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide