Problems setting up VPN tunnel from Azure to a vendor

VPN
1

I’m tasked with setting up a VPN tunnel from our Azure environment to a vendor’s datacenter. The vendor is using Cisco ASA 9.x on their end, and has a specific set of IKE/IPsec parameters from which they will not deviate. So far we have not gotten the tunnel to establish. It doesn’t help that I’m a server guy, not a networking guy, but I’m the Azure guy in our org, so this is on my plate. So, I’m hoping someone with experience with translating from “Cisco” to “Azure” can help me at least ask the right questions.

The two items I am stuck on are:

  • setting a matching crypto map ACL in Azure - I’m not sure how this translates into Azure terminology and functionality. At present, the vendor is saying that on the Azure end, access is Any-Any rather than matching their ACL.
  • IKE main mode SA lifetime - I’m finding documentation that Azure VPN gateways have IKE main mode SA lifetime fixed at 28800 seconds. see - https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-compliance-crypto

I’ve found some documentation to the effect that this parameter does not need to match in IKEv2 tunnels, including the documentation cited above, but the vendor does not concur.

​

Their parameters:

IKEv2 - PHASE 1

ISAKMP SA IKE Version IKEv2

ISAKMP SA Authentication Method PSK

ISAKMP SA Hash Algorithm SHA-256

ISAKMP SA Encryption Algorithm AES-256

ISAKMP SA Diffie-Hellman Group DH 14

ISAKMP SA Life Duration 86400 seconds

​

ISAKMP SA IKE Phase 1 Mode Main Mode

IPSec - PHASE 2

IPSEC SA – Protocol ESP

IPSEC SA – Hash Algorithm SHA-256

IPSEC SA – Encryption Algorithm AES-256

IPSEC SA – Lifetime Duration 28800 seconds

​

They also have provided the WAN ip for their endpoint, pre-shared key, and the following access list:

access-list vpn-{xxxxxxxxx-yyyy} extended permit ip {xxx.xxx}.141.0 255.255.255.0 host {Azure VPN gateway IP}

​

access-list vpn-{xxxxxxxxx-yyyy} extended permit ip {xxx.xxx}.104.0 255.255.255.0 host {Azure VPN gateway IP}

​

access-list vpn-{xxxxxxxxx-yyyy} extended permit ip {xxx.xxx}.108.0 255.255.255.0 host {Azure VPN gateway IP}

​

(I’ve partially obscured the information and IP addresses - anything in curly brackets is obfuscated info, not actual data)

​

On the Azure end, I’ve created a Local Network Gateway with the vendor’s peer IP as the IP address, and the following address spaces:

{``xxx.xxx``}.141.0/24

{``xxx.xxx``}.104.0/24

{``xxx.xxx``}.108.0/24

​

I created a connection on our existing VPN gateway to the above Local Network Gateway, and set the IPsec policy via powershell, using the following:

​

$newpolicy6 = New-AzureRmIpsecPolicy -IkeEncryption AES256 -IkeIntegrity SHA256 -DhGroup DHGroup14 -IpsecEncryption AES256 -IpsecIntegrity SHA256 -PfsGroup None -SALifeTimeSeconds 28800 -SADataSizeKilobytes 102400000

Set-AzureRmVirtualNetworkGatewayConnection -VirtualNetworkGatewayConnection $connection6 -IpsecPolicies $newpolicy6 -UsePolicyBasedTrafficSelectors $True

​

So, uh, help? And thanks in advance!

​

2

The vendor sees “Any-Any” because the Azure side has been configured as “Route based”. You have to create instead a “Policy based” connection. The other settings I would leave them as default because Azure supports a lot of combinations out of the box.

Carefully read this document on how to create the policy based connection: Connect VPN gateways to multiple on-premises policy-based VPN devices - Azure VPN Gateway | Microsoft Learn

And let us know how it goes :slight_smile:

3

I do not have the exact answer but there is another resource for the Cisco ASA configuration on the Azure site you may want to reference too. They have an Example config:
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-3rdparty-device-config-cisco-asa

4

I’ve had tunnel instability with policy based vpn and cisco asa’s. After debugging we observed that Azure changes phase 2 SPI for ungodly reason, which caused timeouts until phase 1 is torn down. To work around the issue, we set the ASA side to responder only and disabled data rekey. Hopefully this will save you hours of troubleshooting if you run into the same issue.

​

crypto map xxxxxx 110 set peer x.x.x.x

crypto map xxxxxx 110 set ikev2 ipsec-proposal AZURE

crypto map xxxxxx 110 set security-association lifetime seconds 36000

crypto map xxxxxx 110 set security-association lifetime kilobytes unlimited

​

​

5

Thanks everyone for all the feedback! All very helpful.

Now I just have to convince the vendor that our setup should work and wait for their change request process.

6

Sounds silly, but start small. I have seen multiple IPSEC tunnels fail due to isp carrier settings. It depends on your configuration. Assuming your location is trying to establish an IPSEC tunnel over an ISP and not MPLS (as you wouldn’t have this issue if you used and MPLS service).
Get with your security firewall team, and bridge in the isp technical support to a call. Have the isp ensure dchp is disabled, if your site handles network routing on Cisco switches etc (which again is assumed) then you also have a firewall team.
Typical isp setup requests for our team include the provider ensure the modem is in full bridge /pass through, with DCHP disabled. (assuming your location is the same)
Ask if the security /firewall team is observing the packet loss on return. An identifying factor may look like IKE Port 500 is being blocked, but will pass traffic over IKE port 4500. This is a ‘new to me issues’ that I myself have started working with.
My current assumption is security issues with packet encapsulation handled by the isp provided modem. Although packets received on the data center end will show port 500, when dchp on the modem is on, packets are not being received at that point coming back. Forcing over port 4500 will establish a tunnel, but this is not the recommended settings. Disabling dchp has removed all vpn tunnel issues so far in my short experience.
Just a shot, lemme know if this is the right track and may need more clarification , assistance, etc on this possibility theory.
¯_(ツ)_/¯

7

Update:

So close…

The vendor has done the necessary and gone through their change request process, and set up the VPN tunnel on their Cisco(s). I’ve created the VPN connection in our Azure account, and… no connection.

The sticking point appears to be crypto map ACLs not matching. Here is a snippet from their logs

​

IKEv2 Tunnel rejected: Crypto Map Policy not found for remote traffic selector 10.0.0.0/10.0.3.255/0/65535/0 local traffic selector 151.193.xx.0/151.193.xx.255/0/65535/0!

​

They want to see traffic from the Azure VPN gateway IP, not the VPN Gateway subnet or any other internal addresses.

I am not seeing for the life of me how to get the routing and NAT sorted so that the Azure end matches this expectation.

​

Side note: we have (and have had) a VPN tunnel to the end user’s on-premises Sonicwall on the same VPN Gateway, so we have to take that into consideration when implementing changes in Azure networking.

​

8

Ah, yes, thanks - I had been referring to that document, and I think I see what you’ve explained - let me re-state to make sure I’m understanding:

If we specify the IPSec/IKE policy and include the parameter UsePolicyBasedTrafficSelectors, the connection will behave as a policy-based connection. Additionally, the address space(s) defined in the Local Network Gateway object in Azure are the allowed list for the traffic selectors.

So as long as we’ve set up the Local Network Gateway with the right address spaces and match their IPsec/IKE policy, AND use the parameter -UsePolicyBasedTrafficSelectors = $true…

we should be OK

​

Am I missing anything? Or maybe everything, lol?