Creating a site-to-site connection to your Azure virtual network is desired in a lot of scenarios. Think hybrid cloud, new workloads, communicating with internal systems from Azure and so on. And in demo scenarios when you’re out travelling you might need that access too. Well, looking at the list of supported devices (below) we can find Windows RRAS for example.
Supported VPN devices: https://msdn.microsoft.com/en-us/library/azure/jj156075.aspx
And reading the guide (below) we’ll see how it’s actually done.
Configure Site-to-site VPN: https://msdn.microsoft.com/en-us/library/azure/dn133795.aspx
According to the last link you’ll need an external IPv4 that’s not behind NAT: “Obtain an externally facing IPv4 IP for your VPN device. This IP address is required for a site-to-site configuration and is used for your VPN device, which cannot be located behind a NAT.”
That last statement has been discussed quite a lot, and when you read the RFC (RFC 3715, http://tools.ietf.org/html/rfc3715) of course that IPsec connection will work over NAT. It’s just not supported by Microsoft, meaning that we can’t help you configuring your firewall to allow passthrough, hence we want your gateway to be directly connected to the internet.
For IPsec to traverse your NAT you’ll need to forward some ports (often called port forwarding in your router).
IKE – UDP 500
Encapsulating Security Payload (ESP) – IP protocol 50
Authentication Header (AH) – IP protocol 51
IPsec NAT traversal – UDP 4500
My setup consists of a Telia router with an external IP of 78.72.172.xx, my internal ip range is 192.168.1.0/24. This is added as a local network in Azure.
I then create a new virtual network in Azure and create a dynamic gateway. This will be assigned an ip address.
After that I’ve installed a VM on my local network running Windows Server 2012 R2 and configured it with RRAS. If you download the VPN device configuration script from the Azure portal it’ll set everything up for you, including installing the role. I’ve also configured the port forwarding in my router.
As you can see in the screenshot above the rule “IPSEC_500” forwards all traffic to 192.168.1.150.
Once you have your port forwarding up and running you can have your RRAS server connect.
Give the portal some time (or refresh it) and it’ll show connected too
I’ve deployed two VM’s in Azure and turned off the firewall to be able to verify connectivity using ping.
In the screenshot above I’ve verified connectivity to 10.0.0.5 in Azure with ping, and I’ve done a traceroute. The timeout is from the Azure gateway that doesn’t respond to ICMP. Internal address of RRAS server can be seen in the lower window.
Note that this is unsupported by Microsoft – but works according to RFC.