Table of Contents
Overview:
In this post, we are going to link an Azure Virtual Network to an on-premise network via a Cisco ASA. We will be creating a route-based connection using IKEv2 and a VTI interface.
We are also going to focus on how to achieve this using ASDM.
Prerequisites
- I am going to assume you are already using Azure and you already have a Virtual Network in place.
- You ASA needs to be running at least 9.7 but 9.8 or higher is preferred. I will be using 9.8
- You will need ASDM, I will be using 7.9
The Azure Side
Virtual network gateway
If your Virtual Network already has a “Virtual network gateway” check your settings match then you can skip this section.
- Under “Create a resource” in the top left search for and select “Virtual network gateways”
- Click Create
- Complete the form;
- Name: Whatever matches your naming convention.
- Gateway Type: VPN
- VPN Type: Route based
- SKU: VpnGW1 (or higher, basic doesn’t support IKEv2)
- Virtual Network: Whatever Azure network we are joining over the VPN.
- Public IP: Create new unless you already have a space and give it a name.
- Subscription: Your subscription
- Location: Typically your virtual networks location.
- Click Create
Local Network Gateway
Next, we need a Local Network Gateway to define our ASA public IP address and the list of on-premise network(s) we want over the VPN.
- Under “Create a resource” in the top left search for and select “Local network gateway”
- Click the Add button
- Complete the form:
- Name: Whatever matches your naming convention.
- IP Address: This is the outside public IP address of your ASA
- Address space: This where you add you om premise subnets/vlan’s using the networks CIDR for example 10.0.100.0/24
- Subscription: Your subscription
- Resource Group: Your desired resource group
- Location: Typically your virtual networks location.
- Click Create
A Connection
- Navigate back into your previously created Virtual network gateway and click Connections
- Click Add
- Complete the form:
- Name: Whatever matches your naming convention.
- Connection Type: Site-to-Site (IPSec)
- Virtual network gateway: Should be pre-filled with you Virtual network gateway
- Local network gateway: Select the previously created local network gateway
- Shared key (PSK): Pick as suitably complex string and make a note of it for later
- Click OK
The ASA Side
Connect to your ASA using ASDM.
IKE v2 IPSEC Proposal
- Navigate to Configuration -> Site-to-Site-VPN -> Advanced -> IPSEC Proposals (Transformation Sets)
- Add a net proposal in the IKE v2 section
- Name: AZURE-PROPOSAL (Or whatever matches your naming convention)
- Encryption: aes-256
- Integrity Hash: sha-256
- Click OK
- Click Apply
Or the CLI would be:
crypto ipsec ikev2 ipsec-proposal AZURE-PROPOSAL
protocol esp encryption aes-256
protocol esp integrity sha-256
IPSec Profile
- Still under Configuration -> Site-to-Site-VPN -> Advanced -> IPSEC Proposals (Transformation Sets)
- Add a new IPSec Profile
- Name: AZURE-PROFILE (Or whatever matches your naming convention)
- IKE v2 IPSEC Proposal: AZURE-PROPOSAL (what we just created)
- Click OK
- Click Apply
Or the CLI would be:
crypto ipsec profile AZURE-PROFILE
set ikev2 ipsec-proposal AZURE-PROPOSAL
VTI Interface
- Navigate to Configuration -> Device Setup -> Interface Settings -> Interfaces
- Click Add on the right and select “VTI Interface” from the drop down
- On the General tab:
- VTI ID: Any number you like that isn’t already in use 1-100
- Interface Name: AZURE-VTI01 (Or whatever matches your naming convention)
- Enable Interface: Checked
- IP Address: 169.254.225.1 (Or whatever you like)
- This is the IP of the VTI interface so it can’t be used anywhere else in your ASA’s configuration.
- I have gone with an APPIPA address as I don’t use them anywhere else.
- It only needs to be a private address.
- Later when we get into routing .2 will be our next hop to Azure.
- Subnet Mask: 255.255.255.252 (we only need two addresses)
- On the Advanced tab
- Destination IP: The public IP address of your Azure Virtual Network Gateway, which on be found on the overview pane for the gateway.
- Source Interface: outside (typically)
- Tunnel protection with Ipsec profile: AZURE-PROFILE (what we previously created)
- Enable Tunnel Mode IPv4 Ipsec: Checked
- Click OK
- Click Apply
Or the CLI would be:
Interface Tunnel20
no shutdown
nameif AZURE-VTI01
ip address 169.254.225.1 255.255.255.252
tunnel destination 51.143.xxx.xxx
tunnel source interface outside
tunnel protection ipsec profile AZURE-PROFILE
tunnel mode ipsec ipv4
Group Policy
- Navigate to Configuration -> Site-to-Site VPN -> Group Policies
- Click Add
- Name: AZURE-GROUP-POLICY
- Tunneling Protocols: Un-check inherit and check IPSec IKEv2
- Click OK
- Click Apply
Or the CLI would be:
group-policy AZURE-GROUP-POLICY internal
group-policy AZURE-GROUP-POLICY attributes
vpn-tunnel-protocol ikev2
exit
Tunnel Group
- Navigate to Configuration -> Site-to-Site VPN -> Advanced -> Tunnel Groups
- Click Add
- Name: The public IP address of your Azure Virtual Network Gateway. As we used on the Advanced tab when setting up the VTI interface.
- Group Policy Name: AZURE-GROUP-POLICY (what we just created)
- Local and Remote Pre-Shared Keys: The PSK we set when creating the connection on the Azure Virtual Gateway.
- IKE Peer ID Validation: Do Not Check
- Click OK
- Click Apply
Or the CLI would be:
tunnel-group 51.143.xxx.xxx type ipsec-l2l
tunnel-group 51.143.xxx.xxx general-attributes
default-group-policy AZURE-GROUP-POLICY
tunnel-group 51.143.xxx.xxx ipsec-attributes
peer-id-validate nocheck
ikev2 local-authentication pre-shared-key MyVerySecureKey
ikev2 remote-authentication pre-shared-key MyVerySecureKey
isakmp keepalive threshold 10 retry 2
The Route(s)
The last step is to define what destination(s) we will be routed over the VPN. In this example with will use a static route, but if you have a more complex setup BGP is an option.
- Navigate to Configuration -> Device Setup -> Routing -> Static Routes
- Click Add
- Interface: AZURE-VTI01 (as we created in the VTI Interface section)
- Network: The Azure Virtual Network or virtual network gateway is on, or you could add a subnet from that network if you don’t want the whole network.
- Gateway IP: 169.254.225.2 (Our next hop is one up from the IP we set on the VTP Interface)
- Click OK
- Add additional routes to any other subnets
- Click Apply
- Click Save
- Give it a test by trying to RDP onto one of your Azure servers from a client on a network defined in you Azure local network’s address spaces.
Or the CLI would be:
route AZURE-VTI01 10.xx.xx.xx 255.255.0.0 169.254.225.2 1
Other Microsoft Recommend ASA Tweaks
Microsoft recommends setting the MSS to 1350 bytes, and enabling preserving VPN flows during tunnel rekeys
MSS
- Navigate to Configuration -> Firewall -> Advanced -> TCP Options
- Under Other options tick “Force maximum segment size for TCP connection to be” and set it to 1350
Or the CLI would be:
sysopt connection tcpmss 1350
Preserving VPN Flows
- Navigate to Configuration -> Site-to-Site VPN Advanced -> System Options
- Check “Preserve stateful VPN flows when the tunnel drops”
- Click Apply
- Click Save
Or the CLI would be:
sysopt connection preserve-vpn-flows
Phil! Thanks for this. I spent way too much time trying to get S2S working between Azure and ASA. This tutorial finally worked, I think I prefer VTI to Crypto Maps, always found those confusing 😉
Glad it helped.
I know what you mean. VTI is easier for me to get easy for me to get my head around too. As it is just another interface it is also much easier to monitor and control bandwidth too.
Phil
Phil, informative document ,
However i have created the s2s vpn in azure & ASA using this document, but its still not working.
while checking hte configuration from azure and yours , There is a different in one point , the route gateway which you have given was VTI interface remote 169.254.225.2 however in azure document gw is vpn peer IP.
After configuring the vpn tunnel is up ut traffic is not going , IKEV2 is up
Status :
ASAv# show crypto ikev2 sa
IKEv2 SAs:
Session-id:45, Status:UP-IDLE, IKE count:1, CHILD count:0
Tunnel-id Local Remote Status Role
113469553 xx.xx.34.95/500 xx.xx.5.223/500 READY RESPONDER
Encr: AES-CBC, keysize: 256, Hash: SHA96, DH Grp:2, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 28800/42 sec
any idea .
My understanding of this is that the IP address 169.254.225.2 (used for the static route) should exist on the Azure side of the tunnel, but there is no where to configure this on the Azure side. How does it know where to send this traffic to?
Hi,
It is a bit weird coming from the world of physical interfaces but 169.254.225.2 (or whatever range you choose to use) doesn’t need to exist on the Azure side.
.1 is assigned to the firewall so all the route is doing is saying you will find the network (10.x.x.x/16) on the VTI interfaces network.
The tunnel destination IP 51.143.x.x (in the case of this post) of the VTI interface is what you will need from your Azure Gateway.
Sending to .2 sends the traffic over the VTI interface which creates a tunnel to the Azure Gateway.
I hope this helps?
Thanks
Phil
Hello Phil, Great job putting together this document, I was struggling with the MS documentation, We recently upgraded to 9.8 and have used crypto maps till now, no VTI config, so I was hesitant to use the VTI configuration moreover the VTI ip and the gateway were confusing too, after going through your doc and the comment to John plus some side reading on VTI gave me a confidence to use them… My tunnel is finally up after spending quiet sometime, Glad I found your documents
Thanks
Hi Phil
I am trying to set one of these tunnels up – route-based with no BGP on an ASA 9.8(2). I read through the Azure configuration documents and yours. My Azure document was generated last week (Dec 27 2018). It has me setting up several different things and does not work. I am curious to know if your tunnels would have had the same recommended settings from azure such as the /31 VTI IP address, several ACLs allowing any to any traffic, multiple encryption and integrity protocols for phase 1 and 2 and many global changes for MTU, crypto ipsec parameters.
I have not tried your method yet and have the other all configured (albeit failing). Before trying your setup I am curious to know if it came from a previous Azure config recommendation or if you made several tweaks from the Azure recommendation.
Hi,
I was having similar issues to yourself at first. The Azure template gave me a sense of what Microsoft wanted me to do but it didn’t quite mesh with my existing config and there were some bits that didn’t make sense to me. It probably would have been fine for a new out the box ASA but not an ASA in production.
I created this post based on trial and error, and from a mixture of a few other blog posts that give me different bits of the puzzle.
I haven’t looked at the Azure template in a couple of months so things may have changed, but I have a couple of tunnels into different Azure regions using the config in the post and they are running fine.
Let me know how you get on, feel free to reply with any logs or queries and I will help where I can 🙂
Thanks
Phil
Thanks you so much! I spent hours yesterday on trial and error. This is the easiest set of instructions to follow for an S2S between an ASA and Azure for a route based vpn on the whole net. MS and Cisco should just link to this page.
Hi Chris,
I’m glad you found the post of use and thanks for the great feedback.
Phil
Hello Phil,
Please, I have an older ASA which does not support VTI. Please, do you have another article that demonstrates Azure Site-to-Site VPN via a Policy Based connection?
Thanks.
Tom
Hello,
I’ve gone through your steps on both the Azure side and the ASA side. I’m getting the following log entry:
4 Jan 25 2019 10:44:51 750003 Local: :500 Remote::500 Username:Unknown IKEv2 Negotiation aborted due to ERROR: Failed to locate an item in the database
I’ve verified that I used the correct shared key on both ends of the tunnel. Any idea what it is looking for? I’m don’t have a ton of ASA experience but I see that our other tunnels have connection profiles and this one does not. Is that correct?
Thanks,
Mike
Hi Help I tried everything here to the letter.. My VTI interface is down down – ?? ASA 9.9 (2) not sure what else to try to get up ?
maybe viagra? cialis?
also adding you need to apply policy azure end
To create the policy based settings against azure:
https://docs.microsoft.com/bs-latn-ba/azure/vpn-gateway/vpn-gateway-connect-multiple-policybased-rm-ps
2 need ensure no nat for the 10.0.0.0 axure network
3. need a global acl or acl on the vti on the asa to allow 10.0.0.0 network back in to on prem
Hey Phil, For the VTI interface the doc advises the following:”VTI INTERFACE SETUP FOR AZURE
!
! NOTE: “Tunnel1” is used as the name of the VTI interface. [REPLACE AS NEEDED]
! IMPORTANT:
! 1) We are using a /30 to define the VTI interface. This is important when setting up the static VTI route at the end of this script
! 2) This same exact /30 VTI network range must be defined in Azure as a separate address space under the “Local Network Gateway > Configuration” Blade ”
I have just configured the VTI like above and haven’t added the the /30 in the address space for LNG config and it works just fine… did you add the /30 in azure for LNG address space config?
I appreciate the scree shots. Well done!
What version of asmd are you using?
I am using 7.9 with asa 9.6 and the steps do not follow your example.
Your screen shot shows: Click Add on the right and select “VTI Interface” from the drop down
But my interface lists “Interfaces, redundant interface, etherchannel int, and vni int only.
Thanks
I have tried this but ASA to ASA (9.8) I still have the tunnel down, down. I double checked each step. In audition i used packet tracer and traffic is permitted.
Regarding to NAT i have make sure I would bypass it:
nat (inside,outside) source static obj-inside obj-inside destination static (destination-network) (destination-network) no-proxy-arp route-lookup
Still not sure what can be and internet does not have much information available for ASA vti. Help please
Thank you for this excellent guide!
When setting up through ASDM, I also ran into the issue that the connection was not established / the VTI interface stayed down down.
After investigating the logs on the ASA and using the Troubleshooting VPN component on the Azure Virtual Network Gateway, I discovered I needed to enable IKE v2 on our ASA outside interface and create an IKEv2 Policy.
For anyone who experienced the same issue:
IKE v2 is enabled in ASDM:
Configuration > Site-to-Site VPN > Connection Profiles > Access Interfaces > Check “Allow IKE v2 Access” on “outside”
The IKE v2 Policy is created in ASDM:
Configuration > Site-to-Site VPN > Advanced > IKE Policies > [IKEv2 Policies] > Add
Priority : Whatever you decide (1 in my case)
D-H Group : 2
Encryption : aes-256
Integrity Hash : sha256
PRF Hash : sha256
Lifetime : 27000 seconds
(policy derived from connection attempts and scattered documentation from Azure – other options available if required)
At the risk of being redundant:
I also had to create the Access Rule under Firewall for the VTI interface to allow the desired traffic to flow.
In ASDM: Configuration > Firewall > Access Rules > “xxx VTI01 (incoming rule)
Source : any (or whatever fits your needs)
Destination : any (or whatever fits your needs)
Action : permit
Hi,
I have following this tutorial, but for some reason I am getting this message.
5 Mar 28 2022 17:24:49 750001 Local:xx.xx.xx.xx:500 Remote:yy.yy.yy.yy:500 Username:Unknown IKEv2 Received request to establish an IPsec tunnel; local traffic selector = Address Range: 172.23.225.1-172.23.225.1 Protocol: 0 Port Range: 0-65535; remote traffic selector = Address Range: 172.126.219.12-172.126.219.12 Protocol: 0 Port Range: 0-65535
The Site to site is stablished, but I can’t reach the other side
any thought?
When configuring the static route, I’m unable to select the VTI from the drop-down, and just get the options of: Outside, Inside and Null0.