Configuring IKEv2 IPsec VPN for Microsoft Azure Environment

by EmmaF on ‎06-15-2015 10:55 AM - edited on ‎05-04-2017 10:53 AM by (68,815 Views)

Microsoft Azure requires IKEv2 for dynamic routing, also known as route-based VPN. IKEv1 is restricted to static routing only.  For more information on Microsoft Azure VPN requirements and supported crypto parameters for both IKEv1 and IKEv2, reference:

https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpn-devices

 

Microsoft’s Dynamic Routing only requires you to have IP address ranges for each of the local network sites that you’ll be connecting to Azure.  It is a route-based VPN connection that uses IP address ranges defined on both gateways and IKEv2 to automatically negotiate the supported routing prefixes.  This is known as “traffic selector negotiation” under the IKEv2 RFC and PAN-OS uses Proxy IDs to configure the IP address ranges.

 

For an example of how to create a multi-site topology, reference:

https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpngateways

 

image004.pngimage005.png

 

IKEv2 is supported in PAN-OS 7.1.4 and newer versions, and fully supports the necessary route-based VPN and crypto profiles to connect to MS Azure’s dynamic VPN architecture. This document discusses the basic configuration on a Palo Alto Networks firewall for the same. Configuration of the Microsoft Azure Environment is not discussed in this document and you should refer Microsoft’s documentation to set up VPN gateway in the Azure environment.

Note: Palo Alto Networks recommends to upgrade PAN-OS to 7.1.4 or above FIRST before proceeding.

 

Configuring the Microsoft Azure Portal

For instructions on configuring the Azure VPN through the Azure portal, please visit Microsoft's site here:

Create a VNet with a Site-to-Site connection using the Azure portal

 

If you need instructions using PowerShell, see here:

Create a VNet with a Site-to-Site VPN connection using PowerShell

 

If you need instructions using the Classic portal, see here:

Create a VNet with a Site-to-Site connection using the classic portal

 

Configuring the Palo Alto Networks Firewall

Here’ is a step by step guide on how to set up the VPN for a Palo Alto Networks firewall.

For this example, the following topology was used to connect a PA-200 running PAN-OS 7.1.4 to a MS Azure VPN Gateway.

 

For the PAN-OS IKEv2 Crypto Profile, you must select a combination of Microsoft Azure supported crypto parameters as stated in Microsoft’s IPSec Parameters (see first reference link above).  Our example used the following IKE, IPSec, and crypto profile parameters.  Note: Public IP addresses were changed for the purpose of this example.

 

Tunnel Interface

  1. Inside the WebGUI in Network > Interfaces > Tunnel, Add a new tunnel interface.  Select a virtual router and appropriate security zone.
  2. Optional: Assign an IP on same subnet as the Azure Gateway for dynamic routing and/or tunnel monitoring inside the IPv4 tab.
    Tunnel Interface windowTunnel Interface window

 

IKE Gateway

  1. Add an IKE Gateway (Network > Network Profiles >IKE Gateway). The following values are to be configured:
    1. Version: Set to ‘IKEv2 Only mode’ OR ‘IKEv2 preferred mode
      IKE Gateway windowIKE Gateway window
    2. Interface: Set to the public(internet) facing interface of the firewall used to connect to Azure.
    3. Local IP Address: IP address of the external interface of the firewall. If not behind a NAT device, this will be the VPN Gateway Address as configured in Azure.
    4. Peer IP Address: IP address of the Azure VPN Gateway. This can be obtained from the Azure Virtual Network dashboard. Note: Make sure you use the NAT-ed IP on Azure to define the peer IP.
    5. Pre-shared Key: Azure uses a Pre-shared key(PSK or Pre-Shared Secret) for authentication. The Key should be configured as the same value on Azure VPN settings and Palo Alto Networks’ firewall.
      (Note: See links above for Azure configuration information)
    6. On the Advanced Options tab, leave the Enable Passive Mode (Set as responder) unchecked, and in the IKEv2 section leave Liveness Check enabled. Note: Enable NAT traversal if the firewall is behind a NAT device.
      IKE Gateway window - advanced optionsIKE Gateway window - advanced options

    7. IKE Crypto Profile’ is set to default. A new crypto profile can be defined to match the IKE crypto settings of Azure VPN.
      DH Group: group2

      Encryption: aes-256-cbc, 3des

      Authentication: sha1, sha256

      Note: Set lifespans longer than Azure settings to ensure that Azure renews the keys during re-keying. Set phase 1 lifetime to 28800 seconds.
      PAN-OS IKEv2 Crypto Profile window.PAN-OS IKEv2 Crypto Profile window.

 

IPSec Tunnel

Add a new IPSec tunnel (Network->IPSec Tunnels). The following values are to be configured:
  1. Tunnel Interface: Select the configured Tunnel Interface in Step 1. above.
    (Optional: Use the ‘Show Advanced Options’ to configure tunnel monitoring, if desired.)
    IPSec Tunnel windowIPSec Tunnel window
  2. IKE Gateway: Select the IKE Gateway configured in Step 2. above.
  3. IPSec Crypto Profile:(Network > Network Profiles > IPSec Crypto) Select an ‘IPSec Crypto Profile’. This can be default if it matches the Azure settings, otherwise create a new one with Add at the bottom of the IPSec Crypto window.

    Encryption: aes256-cbc

    Authentication: sha1

    DH Group: no-pfs

    Note: Set lifespans longer than Azure settings to ensure that Azure renews the keys during re-keying. Set IPSec (phase 2) lifetime to 8400 seconds
    IPSec Crypto Profile windowIPSec Crypto Profile window

  

Network Reachability

In ‘route based VPNs’, the routing engine of the device(s) is used to determine reachability even for any VPN networks.

  1. Use the ‘Virtual Router’ settings (Network->Virtual Router-><VR Name>) to add a Static Route for the remote network with the Interface set to being the Tunnel Interface configured in Step 1. This should match the local network settings on Azure.
    Virtual Router window - Static Route - IPv4Virtual Router window - Static Route - IPv4

 

IPSec Tunnel Configuration

You can optionally configure “Tunnel Monitor” to ping an IP address on the Microsoft Azure side.  You will also need to configure the necessary Proxy IDs (IP address ranges) for the local and remote networks using the Proxy ID tab.  This is how route-based VPNs are configured for “dynamic routing” in the Microsoft Azure environment.

image003.png

 

Checking the Connection

On the PAN-OS firewall under the IPSec Tunnels menu option, check the UI to ensure that the tunnel you created is up and running. The status columns for the IKE Gateway and the Tunnel Interface should be green if IKEv2 negotiated correctly and the IPSec Phase 2 tunnel was brought up.

 

You can also filter on the system log for the “vpn” type to see the IKE negotiation messages.  For Microsoft Azure’s VPN connection status, please refer to the Microsoft references stated above.

 

A general check you can use is:

> show vpn tunnel

TnID Name(Gateway) Local Proxy IP Ptl:Port Remote Proxy IP Ptl:Port Proposals
---- ------------- -------------- -------- ------------ --- -------- ---------

 

For more commands to help troubleshoot VPN connections, please see:

How to Troubleshoot IPSec VPN connectivity issues

 

 

 

Comments
by bscottfernald
on ‎08-05-2015 04:08 PM

We could only get this to work if only 3DES was used as Encryption for Phase II .  Any other mix of Encryption options resulted in the tunnel coming up,  but no traffic passing.   We were also successful not having the PA in passive mode.

by vsys_remo
on ‎08-06-2015 02:21 PM

This is a bug which will be fixed with 7.0.2. Then it shoul also be possible to use AES128 and AES256

by michaelbloom
on ‎08-14-2015 08:06 AM

Is there a tentative release data for 7.0.2? Same issue; tunnel comes up but no traffic is being passed through.

by vsys_remo
on ‎08-14-2015 08:55 AM

PaloAlto Support told me it should be released around mid september

by devere
on ‎11-26-2015 10:46 AM

We have successfully managed to connect to Azure Vnets. However throughput is horribly slow. When using a Windows RRAS server we can achieve 10MB/s upload but when using the PA we achieve an average of 700KB/s which is very dissapointing.

 

The PA doesn't seem loaded in any way and we have a Site to Site to another location (Static) and performance is stellar. It would seem as if the PA is not yet fully compatible on Azure, at least from Microsoft it's not yet officially supported. 

by wmatt
on ‎12-11-2015 10:28 AM

 Had the same issue.  Tunnel came up but was not passing traffic.  Upgraded PA from 7.0.1 to 7.0.3.  Works now.

by MohammedAS
on ‎02-15-2016 12:23 AM

dead links, can you please update the links

by pulukas
on ‎03-27-2016 08:32 AM
by soporteseguridad
on ‎05-06-2016 03:25 PM

Hi have the same slow transfer. How can i solve it?

 

We have successfully managed to connect to Azure Vnets. However throughput is horribly slow. When using a Windows RRAS server we can achieve 10MB/s upload but when using the PA we achieve an average of 700KB/s which is very dissapointing.

 

The PA doesn't seem loaded in any way and we have a Site to Site to another location (Static) and performance is stellar. It would seem as if the PA is not yet fully compatible on Azure, at least from Microsoft it's not yet officially supported. 

 

by Mandar.Kulkarni
on ‎06-16-2016 11:11 PM

I am seeing tunnel intermittently going down when I check see below error.

 

'IKEv2 child SA negotiation is failed as initiator, non-rekey. Failed SA: X.X.X.X[500]-X.X.X.X[500] message id:0x00000089. Error code 111

by msocher
on ‎07-06-2016 12:12 PM

Has anyone experienced VPN tunnels going down with azure every hour even as traffic is actively passing? Specifically when using route based VPNs with IKEv2.

 

Also it seems phase 1 and phase 2 are limited to the following on the PAs.

 

IKE: 3DES – SHA1 – DH group2 – 28800 seconds (also tested 10,800 seconds)

IPSEC: AES128 – SHA1 – NOPFS – 3600 seconds

 

On the gateway: IKEv2 ONLY, NO passive mode, NO NATT (I'm not behind a NAT device), NO liveness Check

On the tunnel: Proxy IDs matching the local and remote IP space

by msocher
on ‎07-15-2016 11:42 AM

Here's an update that has stablized my tunnels for IKEv2 and Azure:

 

Disable liveness check for on-prem VPN peer.

Set phase 1 to 28800 seconds. Azure varies slightly depending on the gateway to ~7 hours.

Set phase 2 to 8400 seconds. Azure varies slightly depending on the gateway to ~2 hours.

Set on-prem VPN peer gateway as passive so that it will always be the responder.

Remove proxy ID specific network ranges. This forces the use of only a single child SA as the following:

TS local:   Proto:any, 0.0.0.0-255.255.255.255, Ports:any

TS remote:  Proto:any, 0.0.0.0-255.255.255.255, Ports:any

 

Once I was able to determine a value that was outside of the Azure phase 1 and 2 life timers, my side of the tunnel was able to  stay as the responder. Once the Azure timers run out, the SPI on both the Azure side and the on-prem side will simultaneously update. Conversely, if the on-prem VPN peer timers are inside of the Azure life timers, the Azure SPI will not update with the on-prem peer SPI. This in turn causes client connectivity to be lost.

 

As long as the on-prem peer is able to stay as the responder in the VPN session, the issue seems to resolve with the exception of an occasional drop of 1 to 3 pings as phase 2 refreshes and the SPIs sync up on both sides.

by Fengrui
‎09-16-2016 02:40 AM - edited ‎09-28-2016 01:01 AM

I have recently configured a route based site to site VPN between Palo (7.0.8) and Azure, followed this article and it did not work for me.

 

After configuration, the VPN tunnel showed up on both phases at both sides, and you can even see traffic in log monitor being allowed, however no traffic is being received at the Azure end, when running command "show vpn flow tunnel-id xx", both encryption and authentcation algorithm are showing "not established" (tunnel-id can be found by command "show vpn ipsec-sa tunnel tunnel_name").

Also the phase 2/IPsec tunnel get re-negotiated every 5 minutes.

 

After logging a ticket with Azure, they confirmed that they have seen similar issue with other Palo customers, and this is what they recommended on configuration:

 

Phase 1:

 

Encryption: aes-256-cbc, 3des

Authentication: sha1, sha256

DH Group: group2

Lifetime: 11000 seconds

IKEv2 Authentication Multiple: 3 (new setting, was set at 0 which means disabled)

 

Phase 2:

 

Encryption: aes256-cbc

Authentication: sha1

DH Group: no-pfs

Lifetime: 7600 seconds

 

Gateway:

 

Passive Mode: Enabled

NAT Traversal: Enabled (not necessary)

 

In my case I had to consolidate proxy-id at my side from 10 specific ones into one 0.0.0.0/0 (because it is route based VPN, all the encryption domain will be determined by the route to the tunnel interface), and leave Azure side to a /24 network, this has since stablised our VPN.

 

 

by AmericanApparel
on ‎09-27-2016 04:49 PM

I second Fengrui's configuration. This also worked for us as well.

by woolp4
on ‎11-16-2016 07:06 AM

Hi Fengrui,

 

Hope you can shed some light on something - Can I ask what the significance of selecting both aes-256-cbc and 3des for encryption at Phase 1? Does a combination of CBC and 3DES result in something "different" ie. AES GCM or AES CCM - I had thought it would only chose one option when negotiating the VPN.

 

I've been somewhat baffled as to why Palo Alto have other AES options at Phase 1 to Phase 2.

 

Encryption: aes-256-cbc, 3des

Authentication: sha1, sha256

DH Group: group2

Lifetime: 11000 seconds

IKEv2 Authentication Multiple: 3 (new setting, was set at 0 which means disabled)

 

Thanks

 

Paul

by Fengrui
on ‎11-16-2016 07:47 AM

 

aes-256-cbc and 3des serve as a list for Palo to choose from when negotiating with VPN peer on phase 1 as responder, it's either or - so whichever the other side presenting, Palo will be happily using it. Same for authentication.

by CATSatIDS
‎01-31-2017 01:23 AM - edited ‎01-31-2017 01:25 AM

This article needs reauthoring...

 

Symptom: tunnel drops after SA expires.

Azure support advice:

 

initiated the rekeyed SA SHOULD delete the replaced SA after the new one is established – But in this specific case I don’t see Pala Alto sending Informational Delete Payload to delete the old SA instead Azure continues to use the old SA and since there is no incoming traffic which we have seen on remote session.

 

The responder can be assured that the initiator is prepared to receive messages on an SA if either (1) it has received a cryptographically valid message on the new SA, or (2) the new SA rekeys an existing SA and it receives an IKE request to close the replaced SA.  When rekeying an SA, the responder SHOULD continue to send messages on the old SA until one of those events occurs.

 

Issue/ Bug:

IKEv2 process did not send CHILD_SA delete message to the peer before deleting the SA, Palo issue 96415

https://live.paloaltonetworks.com/t5/Management-Articles/Critical-Issues-Addressed-in-PAN-OS-Release...

 

Instructions from PA Support:

 

Upgrade firmware to v7.1.4 or above

Set as responder (enable passive mode)

Turn off liveness check

Set lifespans longer than Azure settings to ensure that Azure renews the keys

Set phase 1 lifetime to 28800 seconds

Set phase 2 lifetime to 8400 seconds

 

Result: tunnel now stable

by
on ‎02-22-2017 10:24 PM

This article has been updated.
Please review and comment if there are any other changes needed or would be helpful.

by SShnap
on ‎02-27-2017 01:57 PM

Hi

for me the it works with the configuration:

IPSEC crypto: ESP / AES-256-cbc / sha1 / no-pfs / 3600 sec.

IKE crypto: 3des / sha1 / group2 / 28800 sec.

IKE Gateway: IKEv1 only mode.

 

Good Luck

 

by etoscano
on ‎03-22-2017 07:53 AM

I have to uncheck "enable passive mode" on my PA3020 - 7.1.6. 

If i enable the passive mode, the vpn tunnel is up and running, but no traffic passing. 

 

Microsoft itself (microsoft ticket) says to change to a SA Liftime in Phase 2 to 8 hours and also enable the passive mode. 

 

For me still works withouth enable passive mode.... a few weeks ago, it has working with enable passive mode....really strange.. 

 

regards, 

 

etoscano

 

 

by Tyler_Daple
on ‎05-11-2017 10:35 AM

I've got this same issue.  Microsoft is telling me to change Phase 2 timer to 27000s per their docs.  

We're seeing keys go stale at just over 6.5 hours, though the timer is set in P1 to 28800 per docs and P2 to 8400 per same docs.

 

"Please follow the document below, those are the latest requirement from our side.

Thank you.

 

https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpn-devices#ipsec-parameters "

 

 ms_ike_params.jpg

by adrili
on ‎10-03-2017 10:55 AM

From the Microsoft document

:https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpn-devices#ipsec-parameters

There is an addition at the bottom. Anybody used the 28,800 seconds for Phase 2?

 

Feb. 16, 2017

Palo Alto Networks devices with version prior to 7.1.4 for Azure route-based VPN: If you are using VPN devices from Palo Alto Networks with PAN-OS version prior to 7.1.4 and are experiencing connectivity issues to Azure route-based VPN gateways, perform the following steps:

1. Check the firmware version of your Palo Alto Networks device. If your PAN-OS version is older than 7.1.4, upgrade to 7.1.4.

2. On the Palo Alto Networks device, change the Phase 2 SA (or Quick Mode SA) lifetime to 28,800 seconds (8 hours) when connecting to the Azure VPN gateway.

3. If you are still experiencing connectivity issues, open a support request from the Azure portal.

Ask Questions Get Answers Join the Live Community