Microsoft Azure ‘Route Based’ VPN to Cisco ASA

KB ID 0001515

Problem

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

Advantages

  • Can be used for VPNs to multiple sites.

Disadvantages

  • 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”. 

Advantages:

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

Disadvantages

  • 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, (10.0.0.0/24).

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

Config

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
Petes-ASA(config)#

Now create the VTI (Virtual Tunnel Interface) Note: 40.115.49.202 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  169.254.225.1 255.255.255.252
Petes-ASA(config-if)# tunnel destination 40.115.49.202
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 40.115.49.202 type ipsec-l2l
Petes-ASA(config)# tunnel-group 40.115.49.202 general-attributes
Petes-ASA(config-tunnel-general)# default-group-policy AZURE-GROUP-POLICY
Petes-ASA(config-tunnel-general)# tunnel-group 40.115.49.202 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
Petes-ASA(config)#

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
Petes-ASA(config)#

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 10.0.0.0 255.255.255.0 169.254.225.2 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  169.254.225.1 255.255.255.252
tunnel destination 40.115.49.202
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 40.115.49.202 type ipsec-l2l
tunnel-group 40.115.49.202 general-attributes
default-group-policy AZURE-GROUP-POLICY
tunnel-group 40.115.49.202 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 10.0.0.0 255.255.255.0 169.254.225.2 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 8.8.8.8 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 169.254.225.1, subnet mask 255.255.255.252
  Tunnel Interface Information:
	Source interface: outside	IP address: 126.63.123.43
	Destination IP address: 40.115.49.202
	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 123.123.12.1/500                                    40.115.49.202/500                                        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  0.0.0.0/0 - 255.255.255.255/65535
          remote selector 0.0.0.0/0 - 255.255.255.255/65535
          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: 82.21.58.194

      local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
      remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
      current_peer: 40.115.49.202


      #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.: 40.115.49.202/500
      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

Petes-ASA(config)#

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

4 Comments

  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 169.254.225.0/30 on ASA and 10.0.200.0/29 on the Azure end. So where is 169.254.225.2 assign to?

    Thanks!

    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.169.254.225.2 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 https://www.petenetlive.com/KB/Article/0000951 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 10.0.200.0/29 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.

        Thanks!

        Post a Reply
        • Yes it would work if you put an 10.0.200.0/29 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

Submit a Comment

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