Microsoft Azure ‘Route Based’ VPN to Cisco ASA

KB ID 0001515


This covers the, (more modern) Route based VPN to a Cisco ASA that’s using a VTI (Virtual Tunnel Interface).


Azure to Cisco ASA VPN

Virtual Network Gateway Options

With VPN’s into Azure you connect to a Virtual Network Gateway, of which there are TWO types Policy Based, and Route Based. This article will deal with Route Based, for the older Policy Based option, see the following link;

Microsoft Azure To Cisco ASA Site to Site VPN

Route Based

These were typically used with routers, because routers used Virtual Tunnel Interfaces to terminate VPN tunnels, that way traffic can be routed down various different tunnels based on a destination, (which can be looked up in a routing table). Cisco ASA now supports Virtual Tunnels Interfaces (After version 9.7(1)).


  • Can be used for VPNs to multiple sites.


  • Requires Cisco ASA OS 9.7(1) So no ASA 5505, 5510, 5520, 5550, 5585 firewalls can use this.

Policy Based

These came first, essentially they work like this, “If traffic is destined for remote network (x) then send the traffic ‘encrypted’ to local security gateway (y).”  Note: Where Local Security Gateway is a firewall at YOUR site, NOT in Azure! This is the way traditionally VPNs have been done in Cisco ASA, in Cisco Firewall speak it’s the same as “If traffic matches the interesting traffic ACL, then send the traffic ‘encrypted’ to the IP address specified in the crypto map”. 


  • Can be used on older Cisco Firewalls (ASA 5505, 5510, 5520, 5550, 5585).
  • Can be used on newer Cisco Firewalls (ASA 5506-x, 5508-X, 5512-x, 5515-x, 5516-x, 5525-X, 5545-X, 5555-x, 5585-X)
  • Can be used with Cisco ASA OS (pre 8.4) IKEv1 only.


  • Can only be used for ONE connection from your Azure Subnet to your local subnet. Note: You could ‘hairpin’ multiple sites over this one tunnel, but that’s not ideal.

Configure Azure for ‘Route Based’ IPSec Site to Site VPN

You may already have Resource Groups and Virtual Networks setup, if so you can skip the first few steps.

Sign int0 Azure > All Services > Resource Groups > Create Resource Group > Give your Resource Group a name, and select a location > Create.

Create Azure Resource Group VPN


OK, if you’re used to networking this can be a little confusing, we are going to create a virtual network, and in it we are going to put a virtual subnet, (yes I know this is odd, bear with me!) It’s the ‘Subnet Name ‘and ‘address range‘ that things will actually connect to, (

All Services > Virtual Networks > Create Virtual Network > Give the Virtual Network a name, a subnet, select your resource group > Then create a Subnet, give it a name and a subnet > Create.

Create Azure Virtual Network and Subnet VPN

To further confuse all the network engineers, we now need to add another subnet, this one will be used by the ‘gateway’. If you are  a ‘networking type’ it’s part of the virtual network, but is more specific than the subnet you already created. 

With your virtual network selected >Subnets > +Gateway Subnet.

Create Azure Gateway Subnet VPN

You can’t change the name, (you could before, then it wouldn’t work, which was strange, but I suppose it’s fixed now) >  put in another network that’s part of the Virtual-Network, but does not overlap with the subnet you created in the previous step > OK.

Create Azure Gateway Subnet VPN

All Services > Virtual Network Gateways > Create Virtual Network Gateway > Name it > Route Based > Create New Public IP > Give it a Name > Create.

Note: This will take a while, go and put the kettle on! Make sure all running tasks and deployments are complete before continuing.

Create Route Based Azure Virtual Network Gateway VPN

You can do the next two steps together, but I prefer to do then separately, or it will error if the first one does not complete!

Now you need to create a Local Security Gateway. (To represent your Cisco ASA). All Services > Local Security Gateway > Create Local Security Gateway > Name it > Supply the public IP > Supply the Subnet(s) ‘behind’ the ASA > Select your Resource Group > Create.

Create Azure Local Security Gateway

Finally create the VPN > Select your Virtual Network Gateway > Connections > Add.

Create Azure VPN Connection

Give the tunnel a name > Site-to-Site IPSec > Select your Local Network Gateway (ASA) > Create a pre-shared-key (you will need this for the ASA config!) > Select your Resource Group > OK.

Create Azure VPN IPSec Connection

Configure the Cisco ASA for ‘Policy Based’ Azure VPN

I’m using 9.9(2)36, VTIs are supported on 9.7, but as with all new things, I’d assume that was buggy and go for 9.8 or above.

To Avoid Emails:

What IP do I put on my Tunnel interface / Where do I get that from? Use whatever you want, NO it does not have to be on the same network as something in Azure, in fact I’m using an APIPA 169.254.x.x. address, and it works fine, (think of it like a local loopback address, though do note the difference to the last octet in the route statement!)

Where’s the Crypto Map? It doesn’t need one.

Do I need to do NAT Exemption? NO (Unless you were hair pinning a traditional VPN from another ASA into this tunnel, or an AnyConnect client VPN session.)

There’s No ACL to Allow the Traffic, or an Interesting Traffic ACL? That’s correct, you don’t need any, (unless you apply an access-list to the the tunnel interface).


Connect to the ASA and create a set of IPSec and IKEv2 proposals

Petes-ASA# configure terminal
Petes-ASA(config)# crypto ipsec ikev2 ipsec-proposal AZURE-PROPOSAL
Petes-ASA(config-ipsec-proposal)# protocol esp encryption aes-256
Petes-ASA(config-ipsec-proposal)# protocol esp integrity sha-384 sha-256 sha-1
Petes-ASA(config-ipsec-proposal)# exit
Petes-ASA(config)# crypto ipsec profile AZURE-PROFILE
Petes-ASA(config-ipsec-profile)# set ikev2 ipsec-proposal AZURE-PROPOSAL
Petes-ASA(config-ipsec-profile)# exit

Now create the VTI (Virtual Tunnel Interface) Note: is the public IP address of the Virtual Network Gateway in Azure.

Petes-ASA(config)# Interface Tunnel1
Petes-ASA(config-if)# no shutdown
Petes-ASA(config-if)# nameif AZURE-VTI01
Petes-ASA(config-if)# ip address
Petes-ASA(config-if)# tunnel destination
Petes-ASA(config-if)# tunnel source interface outside
Petes-ASA(config-if)# tunnel protection ipsec profile AZURE-PROFILE
Petes-ASA(config-if)# tunnel mode ipsec ipv4
Petes-ASA(config-if)# exit

Now create a group-policy and a tunnel-group, this is where you enter the pre-shared-key you created above.

Petes-ASA(config)# group-policy AZURE-GROUP-POLICY internal
Petes-ASA(config)# group-policy AZURE-GROUP-POLICY attributes
Petes-ASA(config-group-policy)# vpn-tunnel-protocol ikev2
Petes-ASA(config-group-policy)# exit
Petes-ASA(config)# tunnel-group type ipsec-l2l
Petes-ASA(config)# tunnel-group general-attributes
Petes-ASA(config-tunnel-general)# default-group-policy AZURE-GROUP-POLICY
Petes-ASA(config-tunnel-general)# tunnel-group ipsec-attributes
Petes-ASA(config-tunnel-ipsec)# peer-id-validate nocheck
Petes-ASA(config-tunnel-ipsec)# ikev2 local-authentication pre-shared-key supersecretpassword
INFO: You must configure ikev2 remote-authentication pre-shared-key
      and/or certificate to complete authentication.
Petes-ASA(config-tunnel-ipsec)# ikev2 remote-authentication pre-shared-key supersecretpassword
Petes-ASA(config-tunnel-ipsec)# isakmp keepalive threshold 10 retry 2
Petes-ASA(config-tunnel-ipsec)# exit

Enable ISAKMP (version 2) on the outside interface, then configure the parameters that it will use.

Note: If your outside interface is called something else like Outside or WAN substitute that!

Petes-ASA(config)# crypto ikev2 enable outside
Petes-ASA(config)# crypto ikev2 notify invalid-selectors
Petes-ASA(config)# crypto ikev2 policy 10
Petes-ASA(config-ikev2-policy)#  encryption aes-256
Petes-ASA(config-ikev2-policy)#  integrity sha256
Petes-ASA(config-ikev2-policy)#  group 2
Petes-ASA(config-ikev2-policy)#  prf sha
Petes-ASA(config-ikev2-policy)#  lifetime seconds 28800
Petes-ASA(config-ikev2-policy)#  exit
Petes-ASA(config)#  crypto ikev2 policy 20
Petes-ASA(config-ikev2-policy)#  encryption aes-256
Petes-ASA(config-ikev2-policy)#  integrity sha
Petes-ASA(config-ikev2-policy)#  group 2
Petes-ASA(config-ikev2-policy)#  prf sha
Petes-ASA(config-ikev2-policy)#  lifetime seconds 28800
Petes-ASA(config-ikev2-policy)#  exit

There are a couple of extra commands you will need, these are sysops commands. Their purpose is to set things globally, and are generally hidden from the config, (i.e ‘show run’ wont show them). These are recommendations from Azure. The first one drops the maximum segment size to 1350.The second command keeps the TCP session information even if the VPN tunnel drops.

Petes-ASA(config)# sysopt connection tcpmss 1350
Petes-ASA(config)# sysopt connection preserve-vpn-flows
Petes-ASA(config)# exit

The last thing to do, is tell the firewall to ‘route’ the traffic for Azure though the VTI. Note: The last octet in the destination IP is different from the VTI IP!

Petes-ASA(config)# route AZURE-VTI01 1

Whole Config For You to Copy and Paste, (I’m good to you guys!)

Take note/change the values in red accordingly;

crypto ipsec ikev2 ipsec-proposal AZURE-PROPOSAL
protocol esp encryption aes-256
protocol esp integrity sha-384 sha-256 sha-1
crypto ipsec profile AZURE-PROFILE
set ikev2 ipsec-proposal AZURE-PROPOSAL
Interface Tunnel1
no shutdown
nameif AZURE-VTI01
ip address
tunnel destination
tunnel source interface outside
tunnel protection ipsec profile AZURE-PROFILE
tunnel mode ipsec ipv4
group-policy AZURE-GROUP-POLICY internal
group-policy AZURE-GROUP-POLICY attributes
vpn-tunnel-protocol ikev2
tunnel-group type ipsec-l2l
tunnel-group general-attributes
default-group-policy AZURE-GROUP-POLICY
tunnel-group ipsec-attributes
peer-id-validate nocheck
ikev2 local-authentication pre-shared-key supersecretpassword
ikev2 remote-authentication pre-shared-key supersecretpassword
isakmp keepalive threshold 10 retry 2
route AZURE-VTI01 1
crypto ikev2 enable outside
crypto ikev2 notify invalid-selectors
sysopt connection tcpmss 1350
sysopt connection preserve-vpn-flows
crypto ikev2 policy 10
  encryption aes-256
  integrity sha256
  group 2
  prf sha
  lifetime seconds 28800
crypto ikev2 policy 20
  encryption aes-256
  integrity sha
  group 2
  prf sha
  lifetime seconds 28800


Testing Azure to Cisco ASA VPN

To test we usually use ‘ping’, the problem with that is, if you are using Windows Servers they will have their Windows firewall on by default, which blocks pings, (bear this in mind when testing). Also your ASA needs to be setup to allow pings, (try pinging that usually responds), if yours doesn’t then configure your ASA to allow ping traffic.

As mentioned above, you might want to turn the firewalls off to test.

Test Azure VPN

On the ASA the first thing to make sure is that the Tunnel Interface is up!

Petes-ASA# show interface tunnel 1
Interface Tunnel1 "AZURE-VTI01", is up, line protocol is up
  Hardware is Virtual Tunnel	MAC address N/A, MTU 1500
	IP address, subnet mask
  Tunnel Interface Information:
	Source interface: outside	IP address:
	Destination IP address:
	Mode: ipsec ipv4	IPsec profile: AZURE-PROFILE

You can also use the following;

Petes-ASA# show crypto ikev2 sa

IKEv2 SAs:

Session-id:2, Status:UP-ACTIVE, IKE count:1, CHILD count:1

Tunnel-id Local                                               Remote                                                  Status         Role
268975001                                                                  READY    INITIATOR
      Encr: AES-CBC, keysize: 256, Hash: SHA96, DH Grp:2, Auth sign: PSK, Auth verify: PSK
      Life/Active Time: 28800/814 sec
Child sa: local selector -
          remote selector -
          ESP spi in/out: 0x7b10e41a/0xfcb4576a

Thats Phase 1 connected, you will also need to check Phase 2

Petes-ASA(config)# show crypto ipsec sa
interface: AZURE-VTI01
    Crypto map tag: __vti-crypto-map-11-0-1, seq num: 65280, local addr:

      local ident (addr/mask/prot/port): (
      remote ident (addr/mask/prot/port): (

      #pkts encaps: 32, #pkts encrypt: 32, #pkts digest: 32
      #pkts decaps: 33, #pkts decrypt: 33, #pkts verify: 33
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 32, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
      #TFC rcvd: 0, #TFC sent: 0
      #Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
      #send errors: 0, #recv errors: 0

      local crypto endpt.: 123.123.123/500, remote crypto endpt.:
      path mtu 1500, ipsec overhead 74(44), media mtu 1500
      PMTU time remaining (sec): 0, DF policy: copy-df
      ICMP error validation: disabled, TFC packets: disabled
      current outbound spi: DA3A1C28
      current inbound spi : B562D9C6

    inbound esp sas:
      spi: 0xB562D9C6 (3043154374)
         SA State: active
         transform: esp-aes-256 esp-sha-hmac no compression
         in use settings ={L2L, Tunnel, IKEv2, VTI, }
         slot: 0, conn_id: 11, crypto-map: __vti-crypto-map-11-0-1
         sa timing: remaining key lifetime (kB/sec): (3962877/28755)
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x000003FF 0xFFFFFFFF
    outbound esp sas:
      spi: 0xDA3A1C28 (3661241384)
         SA State: active
         transform: esp-aes-256 esp-sha-hmac no compression
         in use settings ={L2L, Tunnel, IKEv2, VTI, }
         slot: 0, conn_id: 11, crypto-map: __vti-crypto-map-11-0-1
         sa timing: remaining key lifetime (kB/sec): (4193277/28755)
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x00000001


Related Articles, References, Credits, or External Links

Microsoft Azure To Cisco ASA Site to Site VPN

Microsoft Azure To Cisco ISR Router Site to Site VPN

Azure to Cisco VPN – ‘Failed to allocate PSH from platform’

Author: PeteLong

Share This Post On


  1. Great article as always! I have set few routed VPNs to Azure using other solutions such as Cisco routers and Palo Altos. I attempted using ASA to set it up but ran into issues so reverted it back to policy-based VPN.
    Logic says that Azure VPN Gateway subnet and subnet on which VTI is on should be the same.
    You are using on ASA and on the Azure end. So where is assign to?


    Post a Reply
    • 🙂 I am, If you look at the ISR post elsewhere on the site, I think it also uses a 169.254 address. is not assigned to anything, nor does it have to be. But it is, a valid IP on the subnet that My VTI is in, so the firewall will route traffic ‘Down the Tunnel’ to try and get to it, and the static route statement sends traffic destined to Azure to that address, so it will ’emerge’ within the Azure virtual Network gateway, ready to be routed to the correct destination address, after the packets enter the virtual tunnel 169.254.x.x is not needed any more. It’s like a GRE tunnel, see this post here I’ve got the SAME IP on both ends of the tunnel and it still works.

      Post a Reply
      • It’s so dirty haha. If it works it works, but I wish it had to follow some networking logic. Maybe I just have to shift the way I think about VPN tunnels to Azure. I am curious if you assign IP address on the ASA that is on if the tunnel would work. Of course that Gateway VPN Subnet is a mystery and it is hard to see what is actually taken on that subnet and what is available. Possibly through Azure PowerShell that information could be retrieved.

        Once I catch some time I will test it.


        Post a Reply
        • Yes it would work if you put an address on it also, it’s not really an Azure thing it’s more a VTI/GRE thing. The tunnel is created between the public IPs, not the private VTI ones.

          Post a Reply
  2. Pete these are great articles you have posted. Best I’ve seen!!
    Do you write articles on scripting for cisco hardware using Python?

    Post a Reply
    • Hi, Not yet but Never say Never, it depends what gets thrown at me.

      Post a Reply
  3. Hello Pete!

    Great resource! I have one question…

    If you wanted to allow Anyconnect users access to resources in Azure from the ASA, would your NAT exemption be an “outside,outside” like a traditional hairpin, or would you need to specify the outside to tunnel nameif? I am assuming the latter.

    Post a Reply
  4. It looks like with dual ISP connections on the ASA you could have 2 tunnels to Azure.

    In that case would you still need to use SLA to alter the route or would the interface go down with a loss of connectivity to Azure and fail down to the next higher cost route?

    Post a Reply
    • Personally I’d use an SLA, but you go with what you know!

      Post a Reply

Submit a Comment

Your email address will not be published. Required fields are marked *