How to – Use a Public IP Address Prefix with a Virtual Network Gateway

On a recent project, a client had a requirement for all Public IP addresses to be part of a Pubic IP Address Prefix. This ensured they could both re-use and predict their IPs. Greatly simplifying Governance requirements and white-listing with partners.

However, once the Prefix was active, I went to create a Virtual Network Gateway to test some connectivity options. Being a simple test, I was using the Portal for deployment. I realised that the parameter defaults prevent you from using a Prefix IP as they are on the Standard SKU by default. If you’re creating a single VNG that is not linked to an Availability Zone, the Portal looks for a Basic SKU and you receive this error:

Now a quick fix was to simply select one the AZ SKUs, but I didn’t want that. Thankfully, Cloud Shell was my answer. Out of curiosity, I then tried the same process, but via Powershell. Using the exact same resources and parameters.

And…success! My guess is the flag that prevents you from using a Standard SKU Public IP address for a VpnGw1 SKU VNG is a parameter limitation rather than a technical one. The VNG works exactly as expected.

Hopefully this can save you some time if you find yourself in the same situation!

Bonus tip! When working in Cloud Shell, if there is a parameter you are unfamiliar with and not sure what it expects as input, type out the parameter and hit tab, it will list all allowed inputs:

How to – Troubleshoot your Azure Virtual Network Gateway

One of the most popular methods of connecting to Azure privately is via VPN. This can be a relatively simple process and is well documented by both Microsoft and 3rd party blogs. However, if you encounter problems, it can be difficult to get the data you need to troubleshoot efficiently. Especially if you don’t have access to both Azure and the local connection appliance.

In this post, I’m going to show you how to troubleshoot a Virtual Network Gateway and its VPN connection. As part of this, there are some required specifics:

If the above lines up with your environment, then let’s get started! (If not, get in touch and I might be able to help)

Troubleshoot a Virtual Network Gateway

Login to the Azure Portal, then click the search bar at the top, type “Network Watcher” and click on it to open your resource.

In the Network Watcher blade, under ‘Network Diagnostic Tools” select ‘VPN Diagnostics’.

You’ll have to choose a Storage Account and a Container within to run the tests. If you don’t have one, you can create one from Network Watcher. The Storage Account doesn’t have to be in the same location as your VNG.

Click the checkbox for the VNG you want to troubleshoot, then click ‘Start Troubleshooting’

Once complete, you will see your ‘Troubleshooting Status’, you can see that for mine above it is shown as ‘Unhealthy’. To get more details, there is a Details pane just below with a ‘Status’ blade giving you more information about the problem and an ‘Action’ blade which gives suggestions on how to resolve the issue.

In this instance, the VNG as a resource is healthy, but the Connection it’s facilitating is not, so we need to dig further.

Troubleshooting a Virtual Network Gateway Connection (VPN)

In the same location we ran troubleshooting for the VNG, we will repeat the steps and select the Connection instead of the VNG this time. Select your Storage Account etc. as before and then click the Connection to troubleshoot. Then click ‘Start Troubleshooting’

Once complete, you will again see a ‘Troubleshooting Status’ and can get more information from the ‘Details’ pane.

As you can see from the above, I have a very simple fix to make, as my pre-shared keys do not match.

Hopefully this helps you out when trying to figure out why those VPN tunnels aren’t working.

As always, if you have any questions, get in touch!