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
Setup IKEv2 only mode, bind to interface . Static ip for Azure GW, and preshared key (provided by azure setup)
I found out that not enabling passive mode worked best for this VPN.
Create new IKE Crypto profile,
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:
Since we use static routing we simply route the whole /16 net to the tunnelinterface we created
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.