KB ID 0001515
Problem
This covers the, (more modern) Route based VPN to a Cisco ASA that’s using a VTI (Virtual Tunnel Interface).
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.
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.
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.
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.
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.
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.
Finally create the VPN > Select your Virtual Network Gateway > Connections > Add.
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.
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.
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’
20/02/2019
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!
20/02/2019
🙂 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.
20/02/2019
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!
20/02/2019
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.
10/02/2021
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 ?
11/02/2021
No the VTI just terminates the GRE end in the ASA, the other end of the tunnel is in the cloud security gateway.
P
10/04/2020
Worked perfectly as expected. Great article.
17/05/2019
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
20/05/2019
Hi, Not yet but Never say Never, it depends what gets thrown at me.
29/05/2019
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.
29/05/2019
Yes it’s just a standard ‘Hairpin’ from one to the other https://www.petenetlive.com/KB/Article/0000040
Regards,
Pete
03/10/2019
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?
03/10/2019
Personally I’d use an SLA, but you go with what you know!
11/11/2019
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,
11/11/2019
No, I’ve never attempted to do what you propose, though I can see the obvious requirement for doing so.
P
11/12/2019
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
13/01/2020
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.
15/01/2020
Thank you – updated
10/02/2020
thank you it works perfectly
05/03/2020
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?
19/04/2020
yes same problem here!
21/04/2020
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.
08/04/2020
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
08/04/2020
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!
08/05/2020
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”.
16/05/2020
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?
18/05/2020
Mmm I’d typically ‘hairpin’ a remote site onto another site to site VPN?
23/05/2020
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!
29/05/2020
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.
29/05/2020
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!
23/06/2020
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”
25/06/2020
Hi Dave, no in the next sentence, I mention VTIs and tunnel groups.
06/07/2020
Hi,
Can you please share how to add/update ike and ipsec parameters like AES, SHA and DH group via ‘resource.azure.com’ portal?
10/09/2020
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.
25/09/2020
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”?
28/09/2020
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.
21/01/2021
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.
21/01/2021
I’ve not set this up so I can’t comment, but I’ll open it up……
21/01/2021
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 🙂
21/01/2021
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!)).
03/11/2021
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.
21/11/2021
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.
05/12/2023
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!
01/08/2024
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.