Best practice: Use health alerts with Azure Site-to-Site VPN connections

I wrote about how I built a Site-to-Site VPN between my home network and Azure more than a year ago. It’s a neat solution and something that I see many companies utilizing in their environments. The idea is that you can tunnel traffic from the office network to Azure Virtual Networks (VNETs) through a common IPSec tunnel. These tunnels are often configured once and then forgotten – “it just works,” as they say.

But sometimes, the VPN connection is having issues. The connection drops, thus deteriorating the tunnel – and no traffic passes between the two realms. Users might start asking what’s happening, and it usually takes a while for someone with credentials to log in to Azure and drill down to the perhaps numerous gateways to see what the issue might be.

So, as a best practice: Configure your Azure VPN Gateway (the virtual device in Azure that connects to your On-Premises endpoint to establish the IPSec tunnel) for health alerts. Here is how:

Open Azure Portal, and type vpn in the search bar, and select Virtual Network Gateways. Click any gateways you have, and click Resource health on the side navigation (under Support + troubleshooting). Here you’ll see the health history for each day. You might also see errors, such as this:

Once you’ve reviewed the recent history, click on Add resource health alert from the top menu. From here, you can configure a regular Azure Monitor-based alert. The key here is that the alert is now prepopulated with the VPN resource – and you add more resources. I usually add the VPN gateway and the Site-to-Site connection item:

This way, if anything happens with the connection or the gateway, I can trigger an alert. This could be an email or perhaps a process that will fix the connection (while alerting the support team). There is also an option to include all future resources (that map to these resource types) that you might configure in the future to be covered by this alert!

You can also script these settings with Azure CLI or PowerShell.

It’s a simple task but something I rarely see having been implemented. I’ve added this to my uber checklist of things to ensure are configured when I review a customer Azure setup.