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

[Michael Muenz]

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! :)

[dragon8_uk]

Hi,

I have just set this up on a 5508X failover cluster to Azure. We are using express route as our primary and now have the VPN as a backup.

fairly simple setup now that the ASA supports IKEv2

J.

[Alan Huseyin Kayahan]

@dragon8_uk, did you setup VTI based tunnel using IKEv2?

[Greg Focaccio]

Hi Guys,

This looks promising  9.8.1 Release Notes

"Support for IKEv2, certificate based authentication, and ACL in VTI"

"Virtual Tunnel Interface (VTI) now supports BGP (static VTI). You can now use IKEv2 in standalone and high availability modes. You can use certificate based authentication by setting up a trustpoint in the IPsec profile. You can also apply access lists on VTI using access-group commands to filter ingress traffic."

We are looking for a firewall solution to put at HQ that would have a VPN to Azure West and simultaneously a VPN to Azure East with the ability to dynamically route (BGP?) between East or West [and also to dynamically route between 2 WAN connections at HQ (primary fiber and back-up 4G)]

Given the above (IKEv2 in 9.8.1) and what @dragon8_uk said above - it seems like an ASA running 9.8.1 could provide the solution.

Am I seeing this right?

Thanks,

Greg

[David Burgoyne]

Hi all,

I have set up four IPSEC tunnels using VTI and all is passing traffic fine but I am having issues getting management access through the tunnel, for example ASDM.  Has anyone gotten ASDM working through one of these IPSEC tunnels that use VTIs?  Like mentioned above there seems to be no way to say http (address) (vti interface nameif).  

Thanks for any help.

[David Burgoyne]

So, I was successful in setting up four VTI tunnels to two PA3020s.  It is passing traffic fine.  However, I am having an issue with management.  I have an interface that I am running management-access on.  It works fine for ASDM, SSH w/ TACACS, and SYSlog, but fails to work when using ICMP or SNMP.  Please let me know if anyone else has seen this behavior.  I have tried multiple NATs/Access-lists but it wont work... even the sfr module is returning pings...

Thanks for any help.

[t511820]

Hello david, could you provide med the config you use?

/Hieu

[bryanmullen]

It's now available! ASA 9.8(2)

[ingmariofernandez]

Hi Michael,

I can confirm that multicast support is not complete. I have just set up a L2L VPN using VTIs (ASA-9.8 versus IOS-15.4), unicast traffic is passing through correctly but multicast is not. The ASA sees no neighbor on the tunnel interface and neither PIM settings are available on the interface mode. 

Such a pity! One of the big advantages of using VTI is multicast support :(

Regards.

[Alan Huseyin Kayahan]

Hi Michal,

Were you able to pass traffic between the VTI interface and any other interface of the ASA (e.g. inside interface)? I was also able to establish the tunnel UP/UP, BGP neighborship on VTI IPs comes UP as well, however when I try to configure a NAT exempt between the inside and the VTI interface, the name of the VTI interface does not show up as an available argument for the nat command (i.e. nat(inside, ?)).

I have a strong feeling that this is a bug because when I try to edit an existing NAT rule via ASDM, it allows me to choose the VTI interface and when I preview the commands that ASDM wants to send, I see the nat(inside,VTIname) statement, which is not accepted by the ASAv.

I am using an ASAv (Virtual Appliance) and was wondering if that is the reason. Rebooting the appliance did not help either.

[Jacob-Harris]

Husycisco,

Can you offer any advice on getting the Azure  BGP relationship to form up, i'm seeing BGP advertisement from Azure hitting the ASA, but the ASA isn't picking them up.

The tunnel is up via the VTI method, and i can communicate between inside asa networks and azure vnet hosts, with static routing.. Just can't get BGP to form up.

For the NAT, i just used an any any interface statement, didn't try individual interfaces.  nat (any,any) source static 5506-Local 5506-Local destination static AZURE-LOCAL AZURE-LOCAL

Thanks,

Jake

[Alan Huseyin Kayahan]

Jacob,

Do you have ebgp-multihop command issued?

[d.lachapelle]

I am also running into an issue with 9.8(1) where I need to nat exempt traffic from inside to a VTI tunnel interface and did exactly like you did.  Verified you cant select the tunnel interface via the CLI, went to the ASDM and once created as inside/outside, i was able to double click outside and select the tunnel, great right?  Wrong, it errored out when I went to save it.

Does anyone have a successful config for doing nat exempt for the new VTI tunnels?  Seems like a big oversight here by Cisco, unless we're both doing something wrong here.

[d.lachapelle]

Husycisco, I just got off the phone with TAC and we came up with a workaround for this. He eventually agreed that it's an enhancement needed at the very least to select the VTI as an ingress/egress interface for identity NAT. What we were able to do is come up with the solution that works: in ASDM, you have to select the box that says "lookup route table to locate egress interface" AND select ANY as the destination interface, not outside(outside will not work).  Any seems to be the key as it lets the system eventually see the VTI as the egress.

CLI looks like this: nat (inside,any) source static phsps02 phsps02 destination static SMM_172.25.210.0 SMM_172.25.210.0 route-lookup

I can confirm it works now, the packet tracer is showing the right results:

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: Tunnel11(XXXXXXX)
output-status: up
output-line-status: up
Action: allow

Hope this helps you.

[You Xu]

Hi

may I ask you some questions?

I config VTI peers without ipsec protection,but the VTI is down，what's the problem？

[Alan Huseyin Kayahan]

Perhaps you forgot to remove the ipsec keyword in the tunnel mode at either end?