Route-based VPN (VTI) for ASA finally here! - Page 3

Michael Muenz · ‎01-24-2017

I just read over the release notes for the new 9.7.1 release and stumbled upon this:

Virtual Tunnel Interface (VTI) support for ASA VPN module

The ASA VPN module is enhanced with a new logical interface called Virtual Tunnel Interface (VTI), used to represent a VPN tunnel to a peer. This supports route based VPN with IPsec profiles attached to each end of the tunnel. Using VTI does away with the need to configure static crypto map access lists and map them to interfaces.

We introduced the following commands: crypto ipsec profile, interface tunnel, responder-only, set ikev1 transform-set, set pfs, set security-association lifetime, tunnel destination, tunnel mode ipsec, tunnel protection ipsec profile, tunnel source interface.

Finally a dream becomes true! Thank you Cisco! :)

Michael Please rate all helpful posts

You Xu · ‎05-30-2017

Hi,husycisco

thank you!

actually,i didn’t add any protection for VTI,I only define the IP\nameif\tunnel source\tunnel destination. No ipsec profile.

BR

ICTInfra1 · ‎03-01-2017

This is a great feature to be added to ASA but it really needs to support IKEv2, which has been around for some time. I hope this will be available for ASA VTIs interfaces in future.

ssawant · ‎03-16-2017

Please pardon my ignorance about Cisco ASA licensing...

If one has a previous software version of ASA, and wishes to use VTI feature by upgrading their box to 9.7.1 version, will they be required to purchase any additional license?

Thanks,

Sandesh

maurgonz · ‎03-28-2017

Can be configured under a clustered-multicontext environment?

e.pedersen · ‎04-24-2017

Great news! A really useful feature that was needed long time ago on ASA platform.

The only question I have if anyone know if this feature will be implemented soon on FTD images?, considering the actual migration from ASA image to FTD, one example is the Firepower 2000 appliances that doesn't support ASA image.

Service Desk · ‎04-28-2017

Does ASA use the transform set parameters for phase 1 and phase 2 of the IPSEC?
Does that mean one is forced to use same parameters for both ipsec stages ?

It is also clear that crypto config for phase 1 can be used as before , does it worth mentioning ?

Federico Olivieri · ‎05-07-2017

Hi All,

I am trying to set-up ipsec route-base between Juniper SRX and Virtual ASA but I cannot make it work. I have also another vpn policy based between them and is working fine. Since I am more juniper expert, can you please help me to identify the issue (see conf and logs below). Also, would be nice if ou can share your config whit me.

ASAv# May 07 21:47:45 [IKEv1]IP = 192.168.253.1, IKE Initiator: New Phase 1, Intf NP Identity Ifc, IKE Peer 192.168.253.1 local Proxy Address 0.0.0.0, remote Proxy Address 0.0.0.0, Crypto map (__vti-crypto-map-7-0-1)
May 07 21:47:45 [IKEv1 DEBUG]IP = 192.168.253.1, constructing ISAKMP SA payload
May 07 21:47:45 [IKEv1 DEBUG]IP = 192.168.253.1, constructing NAT-Traversal VID ver 02 payload
May 07 21:47:45 [IKEv1 DEBUG]IP = 192.168.253.1, constructing NAT-Traversal VID ver 03 payload
May 07 21:47:45 [IKEv1 DEBUG]IP = 192.168.253.1, constructing NAT-Traversal VID ver RFC payload
May 07 21:47:45 [IKEv1 DEBUG]IP = 192.168.253.1, constructing Fragmentation VID + extended capabilities payload
May 07 21:47:45 [IKEv1]IP = 192.168.253.1, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 208
May 07 21:47:53 [IKEv1]IP = 192.168.253.1, IKE_DECODE RESENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 208
May 07 21:48:01 [IKEv1]IP = 192.168.253.1, IKE_DECODE RESENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 208
May 07 21:48:09 [IKEv1]IP = 192.168.253.1, IKE_DECODE RESENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 208
May 07 21:48:17 [IKEv1 DEBUG]IP = 192.168.253.1, IKE MM Initiator FSM error history (struct &0x00007ff5715eb2a0) <state>, <event>: MM_DONE, EV_ERROR-->MM_WAIT_MSG2, EV_RETRY-->MM_WAIT_MSG2, EV_TIMEOUT-->MM_WAIT_MSG2, NullEvent-->MM_SND_MSG1, EV_SND_MSG-->MM_SND_MSG1, EV_START_TMR-->MM_SND_MSG1, EV_RESEND_MSG-->MM_WAIT_MSG2, EV_RETRY
May 07 21:48:17 [IKEv1 DEBUG]IP = 192.168.253.1, IKE SA MM:6dd11861 terminating: flags 0x01000022, refcnt 0, tuncnt 0
May 07 21:48:17 [IKEv1 DEBUG]IP = 192.168.253.1, sending delete/delete with reason message
May 07 21:48:45 [IKEv1]IP = 192.168.253.1, IKE Initiator: New Phase 1, Intf NP Identity Ifc, IKE Peer 192.168.253.1 local Proxy Address 0.0.0.0, remote Proxy Address 0.0.0.0, Crypto map (__vti-crypto-map-7-0-1)
May 07 21:48:45 [IKEv1 DEBUG]IP = 192.168.253.1, constructing ISAKMP SA payload
May 07 21:48:45 [IKEv1 DEBUG]IP = 192.168.253.1, constructing NAT-Traversal VID ver 02 payload
May 07 21:48:45 [IKEv1 DEBUG]IP = 192.168.253.1, constructing NAT-Traversal VID ver 03 payload
May 07 21:48:45 [IKEv1 DEBUG]IP = 192.168.253.1, constructing NAT-Traversal VID ver RFC payload
May 07 21:48:45 [IKEv1 DEBUG]IP = 192.168.253.1, constructing Fragmentation VID + extended capabilities payload
May 07 21:48:45 [IKEv1]IP = 192.168.253.1, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 208
May 07 21:48:53 [IKEv1]IP = 192.168.253.1, IKE_DECODE RESENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 208
May 07 21:49:01 [IKEv1]IP = 192.168.253.1, IKE_DECODE RESENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 208
May 07 21:49:09 [IKEv1]IP = 192.168.253.1, IKE_DECODE RESENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 208
May 07 21:49:17 [IKEv1 DEBUG]IP = 192.168.253.1, IKE MM Initiator FSM error history (struct &0x00007ff57163c560) <state>, <event>: MM_DONE, EV_ERROR-->MM_WAIT_MSG2, EV_RETRY-->MM_WAIT_MSG2, EV_TIMEOUT-->MM_WAIT_MSG2, NullEvent-->MM_SND_MSG1, EV_SND_MSG-->MM_SND_MSG1, EV_START_TMR-->MM_SND_MSG1, EV_RESEND_MSG-->MM_WAIT_MSG2, EV_RETRY
May 07 21:49:17 [IKEv1 DEBUG]IP = 192.168.253.1, IKE SA MM:f4ad8a55 terminating: flags 0x01000022, refcnt 0, tuncnt 0
May 07 21:49:17 [IKEv1 DEBUG]IP = 192.168.253.1, sending delete/delete with reason message
May 07 21:49:45 [IKEv1]IP = 192.168.253.1, IKE Initiator: New Phase 1, Intf NP Identity Ifc, IKE Peer 192.168.253.1 local Proxy Address 0.0.0.0, remote Proxy Address 0.0.0.0, Crypto map (__vti-crypto-map-7-0-1)
May 07 21:49:45 [IKEv1 DEBUG]IP = 192.168.253.1, constructing ISAKMP SA payload
May 07 21:49:45 [IKEv1 DEBUG]IP = 192.168.253.1, constructing NAT-Traversal VID ver 02 payload
May 07 21:49:45 [IKEv1 DEBUG]IP = 192.168.253.1, constructing NAT-Traversal VID ver 03 payload
May 07 21:49:45 [IKEv1 DEBUG]IP = 192.168.253.1, constructing NAT-Traversal VID ver RFC payload
May 07 21:49:45 [IKEv1 DEBUG]IP = 192.168.253.1, constructing Fragmentation VID + extended capabilities payload
May 07 21:49:45 [IKEv1]IP = 192.168.253.1, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 208
May 07 21:49:53 [IKEv1]IP = 192.168.253.1, IKE_DECODE RESENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 208
May 07 21:50:01 [IKEv1]IP = 192.168.253.1, IKE_DECODE RESENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 208
May 07 21:50:09 [IKEv1]IP = 192.168.253.1, IKE_DECODE RESENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 208
May 07 21:50:17 [IKEv1 DEBUG]IP = 192.168.253.1, IKE MM Initiator FSM error history (struct &0x00007ff574a9c950) <state>, <event>: MM_DONE, EV_ERROR-->MM_WAIT_MSG2, EV_RETRY-->MM_WAIT_MSG2, EV_TIMEOUT-->MM_WAIT_MSG2, NullEvent-->MM_SND_MSG1, EV_SND_MSG-->MM_SND_MSG1, EV_START_TMR-->MM_SND_MSG1, EV_RESEND_MSG-->MM_WAIT_MSG2, EV_RETRY
May 07 21:50:17 [IKEv1 DEBUG]IP = 192.168.253.1, IKE SA MM:7d42e110 terminating: flags 0x01000022, refcnt 0, tuncnt 0
May 07 21:50:17 [IKEv1 DEBUG]IP = 192.168.253.1, sending delete/delete with reason message

interface GigabitEthernet0/2
description //--BR253--//
nameif outside.253
security-level 0
ip address 192.168.253.25 255.255.255.0

!
interface Tunnel1
nameif ipsec
ip address 172.16.0.2 255.255.255.252
tunnel source interface outside.253
tunnel destination 192.168.253.1
tunnel mode ipsec ipv4
tunnel protection ipsec profile SRX-RB

crypto ipsec profile SRX-RB
set ikev1 transform-set SRX
set pfs group5
set security-association lifetime seconds 3600

crypto ikev1 enable outside
crypto ikev1 enable outside.253
crypto ikev1 policy 1
authentication pre-share
encryption aes-256
hash sha
group 5
lifetime 3600
crypto ikev1 policy 2
authentication pre-share
encryption des
hash sha
group 2
lifetime 28800

tunnel-group 192.168.253.1 type ipsec-l2l
tunnel-group 192.168.253.1 ipsec-attributes
ikev1 pre-shared-key *****

Report Inappropriate Content · ‎05-16-2017

If i try to pass traffic through the vti-tunnel, from a bridge-group interface, the asa actually crashes. When I disable bridge-groups and use a physical interface, it works just fine.

Anyoene else seen this?

Alan Huseyin Kayahan · ‎05-16-2017

Did you try with version 9.8.1?

Jeferson Ravate · ‎05-24-2017

Has anyone tried to use IKEv2 and VTI in 9.8.1? Eg: To connect to Azure Gateway (Route-Based).

Thomas Pike · ‎06-01-2017

Yes, we have just updated our ASAs tonight to 9.8.1 and successfully connected using IKEv2 and VTI to Azure:

crypto ikev2 policy 3
encryption aes-256
integrity sha
group 2
prf sha
lifetime seconds 10800

crypto ipsec ikev2 ipsec-proposal PROP-AZURE
protocol esp encryption aes-256
protocol esp integrity sha-1

crypto ipsec profile PROF-AZURE
set ikev2 ipsec-proposal PROP-AZURE
set pfs group2
set security-association lifetime kilobytes 102400000
set security-association lifetime seconds 10800

interface Tunnel1
nameif VPN-AZURE
ip address 169.254.2.1 255.255.255.0 standby 169.254.2.2
tunnel source interface outside
tunnel destination xx.xx.xx.xx
tunnel mode ipsec ipv4
tunnel protection ipsec profile PROF-AZURE

tunnel-group xx.xx.xx.xx type ipsec-l2l
tunnel-group xx.xx.xx.xx ipsec-attributes
ikev2 remote-authentication pre-shared-key *****
ikev2 local-authentication pre-shared-key *****

route VPN-AZURE xx.xx.xx.xx 255.255.0.0 xx.xx.xx.xx 1

Jeferson Ravate · ‎06-01-2017

Hi Thomas

Thank you very much for your reply.

This is a very expected feature by those who work with Azure.

Nathan Brock · ‎06-07-2017

route VPN-AZURE xx.xx.xx.xx 255.255.0.0 xx.xx.xx.xx 1

I asume the network would be the AzureSubnet like 10.0.0.0/16 and the next hop would be the public ip of the Azure VPN Gateway? Like

route VPN-AZURE 10.0.0.0 255.255.0.0 47.33.192.2 1

47.33.192.2 = Azure's Dynamically assigned public

Having trouble getting traffic to pass after tunnel is established.

Thomas Pike · ‎06-07-2017

Yes that is correct, we use the following where 104.x.x.x is the public IP of the gateway and 10.0.0.0/16 is our Azure private networks:

route VPN-AZURE 10.0.0.0 255.255.0.0 104.x.x.x 1

Nathan Brock · ‎06-07-2017

Interesting. I tried the BGP Peering IP address of 10.0.0.30 as the next hop and it works.

I wonder which is best to use.

Public IP of Azure VPN Gateway or the INNER Tunnel BGP Peering IP

route VPN-AZURE 10.0.0.0 255.255.0.0 10.0.0.30