Author: raymond

So, lately I’ve setup a lot of vpn tunnels to Azure. With different results. Seems to me that it’s easy to setup the vpn itself, but when it comes to getting the vpn to maintain up and stable you have to tweek back and forth a bit. But heres a example that seems to be working excellent.

Scenario: Two locations, >7 local subnets, one BIG azure subnet.

IKEv2 static routing or policy based as Microsoft calls it: https://azure.microsoft.com/nb-no/documentation/articles/vpn-gateway-about-vpn-devices/

“Static Routing = Policy-based

Dynamic Routing = Route-based”

Palo Alto PA500, using software PANos 7.1.2

 

Azureside setup as IKEv2 policy based, routing each spesific net to each location (gw), seperate PSK keys for each site.

Step 1, create tunnel interface, assign interface to correct vr and sec zone

Step 2 create IP sec tunnel

bind to tunnel, create new IKE gateway

Step 3,

Setup IKEv2 only mode, bind to interface . Static ip for Azure GW, and preshared key (provided by azure setup)

step 4

I found out that not enabling passive mode worked best for this VPN.

Create new IKE Crypto profile,

Step 5

Azure allows a lot of IKE ciphers, but this one seems to be stable

DHgroup 2, AES-256-cbc, SHA1, keylife 28800 secs

Step 6 Create IPsec crypto profile

Here’s where it gets interesting, according to the samples you should use ESP DHgrp2 AES-252cbc and sha1

And that works. For a while… then the tunnel goes down and never comes up again by itself.

Using this setup

ESP, NO-PFS, aes-256cbc,3des,aes-128-cbc, sha1 and lifetime 3600secs

seems to work the best.

Then the result should look something like this:

step 7

Since we use static routing we  simply route the whole /16 net to the tunnelinterface we created

step 8

Create rules to match the traffic (Yes i know this rule is an any-any-rule, but i used that for testing, and migration tool afterwards to convert to lay 7 rules.)

And boom the vpn is up and running

A recommended troubleshooting command if you need it

tail follow yes mp-log ikemgr.log

Provides a good realtime view of the ipsec tunnel. That’s how i found out what was going wrong with the intial setup using the samples provided by azure. The error i got was that the tunnel had missing KE. (proxy id or in this case ciphers and no-fps)

 

Using  the same setup on both locations worked perfectly.