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

44 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
          • Pete……are you saying a GRE tunnel is created between the vti and the outside inteface ? If so, how does that relate to the behavior of “flooding” the traffic to a non-existent next hop of 169.254.1.2 ?

          • No the VTI just terminates the GRE end in the ASA, the other end of the tunnel is in the cloud security gateway.

            P

      • Worked perfectly as expected. Great article.

        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?
    Regards,
    Tom

    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
  5. does this solve the problem on having Azure use On-Prem network for the internet? Reason being we want servers to go through our network to log in/outgg traffic to the internet.

    Thank you,

    Post a Reply
    • No, I’ve never attempted to do what you propose, though I can see the obvious requirement for doing so.

      P

      Post a Reply
  6. Thank you for this article, one question.

    You mentioned that cryto maps are no longer needed, If you have multiple VPN Route-based ikev2 tunnels are is it ok to see, local and remote selector as 0.0.0.0/0

    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

    Post a Reply
  7. Thanks for guide!

    Under your copy and paste config you have all the changes highlighted in red. The “default-group-policy AZURE-GROUP-POLICY” under the tunnel-group config part should be highlight red in case you change your group-policy name in the lines before.

    Post a Reply
  8. thank you it works perfectly

    Post a Reply
  9. Thank you for the information. I have a question though. The cloud vendor is not able to reach us when they initiate the connection? Everything works when we initiate from inside the ASA, but when they initiate from outside the ASA in the Azure environment they are not able to reach the inside hosts? I did a packet input tracer (using their assigned private IPs) and it says blocked by implicit rule? Thoughts?

    Post a Reply
      • access-list AZURE-VTI01_access_in extended permit ip object Azure object 192.168.100.0
        access-group AZURE-VTI01_access_in in interface AZURE-VTI01

        These 2 Commands has to be executed to allow inbound traffic.

        Post a Reply
  10. Wow man, after a hard night you saved me from doing something bad… Thanks a lot, perfect!

    backgroud: my tunnel was working without tunnel interface with a different internet link. after reconfiguring Azure… all broken…

    BR
    Axel

    Post a Reply
    • Pete, one more thing… your solution is very flexible!

      For some reason my ASA needs to talk into the tunnel. I used a /30 subnet from within the local network. Following your example, if you need to use 192.168.100.0/24, you can set as local encryption domain 192.168.100/23 and use 192.168.101.253/30 for your tunnel interface, routing to 192.168.101.254. Works!

      Post a Reply
  11. I had an issue with encaps (=0) and decaps(=..) packets.
    NAT exempt does not match when I choose outside physical interface as outgoing interface.
    It was resolved by choosing “any”.

    Post a Reply
  12. Pete, thanks for this great article. I successfully set up my first ASA to Azure.

    I do have a question to you. We have five locations which are connected using site-to-site IPsec VPN via ASA5506-X. Can I use the same 169.254.225.0/30 subnet on the the VTI interface of my 2nd, 3rd and 4th ASAs when setting up the route-based VPN to the same Azure VNet?

    Post a Reply
    • Mmm I’d typically ‘hairpin’ a remote site onto another site to site VPN?

      Post a Reply
  13. Hi Pete. Great article. Thanks!
    I have a slightly complex challenge scenario I would like to ask you about.

    Currently I have a main office connected through WAN links with five branches. Each site has its own Internet connection. Also, from the main office I have a policy-based VPN tunnel with Azure from an ASA. All branches can reach the Azure subnet since the encryption domain has the on-prem networks summarized with a /16 prefix.

    I would like to give a direct link from each branch to the Azure subnet, which I could do by following your article. This way all the branches would not have to go through the WAN link with the main office to reach the Azure subnet. The complex part is that I would like to maintain the current route through the WAN link as a backup path in case the tunnel from the branch fails, keeping in mind that the tunnel with the main office would still have the same summarized networks for the branches subnets, and that the tunnel with a specific branch would have just the subnet for that branch in its encryption domain. At on-prem level it would be no trouble avoiding routing loops… the trick part is to accomplish this at the Azure routing level.

    Any thoughts?

    Thanks!

    Post a Reply
    • That is a good question, I would use reverse route injection on all the smaller sites, so if the tunnel is up, they will use their WAN connection, then have static routes at each site with a higher metric/cost pointing to the WAN connection at the main site.

      Post a Reply
      • Hi Pete. Thanks for your reply.
        I thought about using RRI at some point, the thing is that I found that this is not possible when using route-based VPN tunnels.

        So, I managed to accomplish this y enabling BGP in all branch tunnels. Then distributing BGP into EIGRP, applying appropriate distribution filters and metrics where needed, and it works pretty good.

        Thanks again!

        Post a Reply
  14. I think there is a wrong title just before the phrase “I’m using 9.9(2)36, VTIs are supported on 9.7”

    The title reads “Configure the Cisco ASA for ‘Policy Based’ Azure VPN” but it should be “Route Based”

    Post a Reply
    • Hi Dave, no in the next sentence, I mention VTIs and tunnel groups.

      Post a Reply
  15. Hi,

    Can you please share how to add/update ike and ipsec parameters like AES, SHA and DH group via ‘resource.azure.com’ portal?

    Post a Reply
  16. I’m using a route based VPN from ASA 9.8(4) to Azure. In the Azure portal. I used your guide for assistance. The tunnel works great, so long as the ASA is the Initiator. In Azure, I have two networks (on-prem) defined in the local network gateway. The problem is that when Azure happens to Initiate the tunnel, traffic selectors get defined that only permit the first of the two address spaces to traverse the tunnel. I can switch the order of the address spaces, the first one in the list will get generated with the traffic selectors for the tunnel. When this happens, I have to bounce the tunnel until the ASA is once again the Initiator. When the ASA is the initiator, the traffic selectors are 0.0.0.0 and everything works fine.

    Post a Reply
  17. Hello,
    amazing article.
    Just one question. What about using NAT directly on ASA?
    If there are no Subnets ‘behind’ the ASA (everything is NATed), what should I enter on Azure side to “address space field”?

    Post a Reply
    • No your thinking like a Firewall Engineer who never worked on networks pre-nat 🙂 The traffics going over a GRE tunnel over a routed interface. You are ‘routing’ the traffic to Azure, the fact you are encrypting it is neither here nor there.

      Post a Reply
  18. Hi Pete,
    Great article!

    About this method, is there any chance to connect with Radius in Azure using Route based VPN? (Radius is installed on VM in Azure). I have connection to this machine from on-premise LAN.
    When i’ll try set up AAA Radius server in ASA, in ‘interface’ section is no VTI interface on list.
    Is there any walkaroud or should I just reconfigure tunnel for Policy Based? Then i should choose ‘outside’ interface.

    Post a Reply
    • I’ve not set this up so I can’t comment, but I’ll open it up……

      Post a Reply
      • I’ve heard that this is possible and Outside interface should be choosen. Also i should add ’management-access outside’ command. This command allow for Outside interface talk to net resources in Azure but this won’t work for me. Many small offices moves their serwers to cloud. This can be a good topic for new article 🙂

        Post a Reply
        • I am doubtful about that management-access is a command thats reserved for certain things, and I’ve never had tones it to the outside interface?

          >>This can be a good topic for new article

          Im sure! But my articles are made from the stuff I’m working on. (And I work for a cloud provider, (that isn’t Azure!)).

          Post a Reply
  19. As always great article – quick question?

    Is it possible to setup an active-active azure vpn gateway with a single on-prem ASA? Have you had a chance to test or know if this is feasible?

    Thanks.

    Post a Reply
    • I’ve not tested, but I have had some feedback where it’s suggested the ASA needs two outside IPs? I don’t know how true that is.

      Post a Reply
  20. Great Article Pete!

    Do you have any section of this same using but using BGP and using the APIPA Addressing?

    I have setup this solution using static routing and using APIPA addressing on the tunnel interface (169.254.0.1/30) and it works fine, but now I need to replace the static routing with BGP, because we plan to add an express route link as a primary and use the Ipsec S2S as a backup. And for this we need BGP running on Both express route and IPSec S2S tunnels.

    For the IPSEC S2S tunnel, the tunnel interface is the following

    interface Tunnel1
    nameif vti-azvpn
    ip address 169.254.0.1 255.255.255.252
    tunnel source interface outside
    tunnel destination x.x.x.x (x.x.x.x is the public IP of the Azure VPN GW)
    tunnel mode ipsec ipv4
    tunnel protection ipsec profile Azure-Ipsec-PROF

    route vti-azvpn 10.0.0.0 255.255.255.255 169.254.0.2 (10.0.0.0/24 is as Azure VNET Subnet)

    On Azure according to the following link, there is a reserved range for BGP when the On premise is using APIPA Addressing. On Azure, the APIPA range for BGP is 169.254.21.0 to 169.254.22.255.

    https://learn.microsoft.com/en-us/azure/vpn-gateway/bgp-howto

    So, per my understanding, the migration procedure for moving from static routing to BGP when using APIPA addressing should be as follows? Do you agree?

    1. On Azure VPN GW, enable BGP, Local AS (65115 default), and Set the “Custom Azure APIPA BGP IP Address” field, set to: 169.254.21.1″

    2. On ASA, add a static route to reach the Azure BGP PEER IP 169.254.21.1 with next hop the tunnel interface towards azure: 169.254.0.2

    route vti-azvpn 169.254.21.1 255.255.255.255 169.254.0.2

    4. On ASA enable BGP with multihop to build and ebgp session with the Azure VPN GW APIPA Addressing 169.254.21.2

    router bgp 65010
    address-family ipv4 unicast
    neighbor 169.254.21.1 remote-as 65515
    neighbor 169.254.21.1 ebgp-multihop 255
    neighbor 169.254.21.1 activate
    network 169.254.0.0 mask 255.255.255.252
    no auto-summary
    no synchronization
    exit-address-family

    After this, we should see the BGP Session is UP, but routing is still static because on the local network gateway “ASA” is still configured with the address space that represents the on premise networks behind the ASA, and on the ASA we still have the routes towards the Azure VNETS configured as static routes with next hop the tunnel interface 169.254.0.2

    5. On the ASA to move from static to dynamic bgp learned routes, we remove the static routes to the Azure VNETs, so they are learned over BGP.

    NO route vti-azvpn 10.0.0.0 255.255.255.255 169.254.0.2 (10.0.0.0/24 is as Azure VNET Subnet)

    6. On Azure VPN GW to move from static to dynamic bgp learned routes, we remove the Address space configured (so on premise networks are now learned dynamically over bgp).

    And I think that should be all? Any thoughts?

    Dont have a change to test it yet, but I think this should work.

    So finally, the design of using BGP with APIPA Addressing is based on that the ASA is using the tunnel interface ip address “169.254.0.1” to establish a ebgp multihop peering with Azure VPN GW “169.254.21.1”.

    Thanks!

    Post a Reply
    • Carlos What did you end up doing for this? I stumbled upon your comment with the same issue but using Firepower and trying to go to BGP from static routing.

      Post a Reply

Submit a Comment

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