A common error with Set-AzureVNetGatewayKey

Recently I’ve helped a customer configuring a hub-and-spoke topology where they had one VNET at the ‘Centre’ configured with VPN to their on-premises network which then needed to be connected to multiple ‘satellite’ VNETs using VNET-VNET connectivity.

A very good walkthrough of how to configure advanced topologies and multi-hop networks on Azure can be found here

We’ve taken a step-by-step approach so we first established cross-premises connectivity using the portal UI, we then started to add the satellite networks one by one.

On the satellite sites we never had any issues as we could do everything through the UI. Expanding the connectivity on the central network required editing the configuration XML to link to multiple networks and after the first two, arguably as we were growing overly confident, we got the following error when trying to set the pre-shared key for the VPN gateway on the central network –

Set-AzureVNetGatewayKey -VNetName CentralVnet -LocalNetworkSiteName SatelliteVnet3 -SharedKey A1B2C3

Set-AzureVNetGatewayKey : BadRequest: The specified local network site name SatelliteVnet3′ is not valid or could not be found.

It took us a little while to figure out what we were missing as we didn’t get this every time. Turns out that occasionally we got ahead of ourselves and tried to update the shared key before importing the updated network configuration xml with the added link between the central network and the satellite one. Given that they key is set on the combination of the two, if you try to set it before making the actual link the command, understandably, fails (although the error message could be a bit clearer)

As an aside – we’ve also seen the following error when executing this command –

Set-AzureVNetGatewayKey : An error occurred while sending the request.

This happened when we delayed long enough for the AAD token in the PowerShell session and we could verify that by trying to execute any other command such as Get-AzureVNetGatewayKey or even Get-Azure Subscription. Using Add-AzureAccount to obtain a new token solved that one easily enough.

Windows Azure Private Network behaviour change

I’ve learnt today that IP routing on Windows Azure when a private network (VPN) is configured has changed recently (not quite sure exactly when, but in the last few weeks I suspect) in a way that can be quite dramatic to many –

Previously, as soon as a site-to-site VPN was configured on a virtual network on Windows Azure, all outbound traffic from the network got routed through the VPN.

This surprised me at the time – I assumed that as the range of IP addresses exposed via the VPN is known, only traffic directed at this ranged will  get routed via the VPN and all other traffic will go directly to the internet. This assumption was proven to be wrong, as we’ve learnt at the time.

This, I was told by several people, is more secure given that VMs on Azure only have one NIC. It also provided organisation an opportunity to more tightly control traffic as all traffic got routed through the organisation’s firewall. for example – organisations who needed to present a consistent IP publically when calling remote systems could control that via their on-premises network configuration as I previously blogged about here, a post I now had to correct, see below.

The main downside of this was always that not all traffic was sensitive and routing everything through the VPN and the on-premises network added latency to the requests and load on the network. For example – a virtual machine on a private network with VPN, calling other Azure services such SQL Database, the Service Bus or the Caching Service would see all requests routed to their internal network before going back out to the internet and to, potentially, the same data centre the request originated from.

In conversation today I’ve learnt (and since confirmed, of course!) that this behaviour has changed and that Azure now behaves as I originally expected it to and now only outbound traffic directed at the IP range exposed via the VPN is routed via the VPN and all other traffic goes straight out through the internet.

This makes perfect sense, but is quite a big change and I’m surprised this wasn’t communicated clearly.

There are downsides – some customers, as I eluded earlier, enjoyed the extra level of control that routing all traffic via their network provided – be it firewall configuration or control over the IP they got routed to external services from. This is not possible at the moment, but I’m hoping that in the not too distant future Windows Azure will offer choice to customers.

Cross posted on the Solidsoft blog

%d bloggers like this: