A while ago I read about how to connect VMs between two VNets and it was nasty: before we could create a VPN tunnel we had to open Endpoints (punch holes through firewalls) and hope for the best!
Since TechEd NA 2014, we have had new functionality where we can connect two VNets, in the same or different data centers, in the same or different regions, or in the same or different subscriptions, via an encrypted & secure VPN tunnel.
As usual, this stuff is announced normally via blogs (it was mentioned in the TechEd keynote I think) and finding instructions can be fun. The first few guides I found were messy, involving exporting VNet configs, editing XML files, and importing configs.
You do not need to do this to set up a simple configuration to connect two VNets. I looked at the instructions, used by experience from site-to-site VPNs with Azure, and tried out a method that uses a temporary local network to enable you to create the VPN gateway and gateway VIPs for each vNet – these are required to create a local network for each VNet. We use local networks to define the details (public VPN IP address and routable private network IP address) of the network that will connect to a VNet.
I tried my method and it worked. And then I found instructions on MSDN that are similar to the method that I used. My method:
- Create the two VNets
- Create a temporary local network with made up gateway IP address (public VPN IP) and address space (private network address that will route to the VNet subnets)
- Configure each VNet to allow site-to-site VPN connections from the temporary local network
- Enable the gateway with dynamic routing on each VNet. This can take 15-20+ minutes for Azure to do for you. Plan other work or a break for this step.
- Record the address space and gateway IP address of both VNets
- Create a local network for each VNet – use the Gateway IP Address and Address Space of the VNet for the details of its local network
- Modify the site-to-site VPN configuration of each VNet to dump the temporary local network and use the local network of the other VNet – you’re telling the VNet the details of the other VNet for connection and routing
- Use Azure PowerShell cmdlets to run Set-AzureVNetGatewayKey. This will be used to configure a common VPN shared key for both VNets.
- Wait … the VPN connection will start automatically … there might be a failure before or just after you st the shared key. Be patient, and one VNet might show a connected status before the other. Be patient!
And that’s it. There is a FAQ on this topic. I’ll be publishing some deeper articles on the subject on Petri.com in the next few weeks.