This article is written for home/office scenarios, it’s NOT recommended for production.
Protect hybrid workloads from threa...
In this article, we will show you how to deploy a Site-to-Site VPN between Azure and Windows RRAS Server.
In This Article
Introduction
Our home office started growing and we need to connect my on-premises environment to Azure. Now to build hybrid connectivity to Azure, you have a couple of options. You can read about all the options on Microsoft documentation here.
The most compelling option to me is to use the Azure Site-to-Site VPN connection. One of the required criteria to build a Site-to-Site VPN connection is to have a compatible VPN device and someone who can configure it. For more information about compatible VPN devices that Microsoft supports and device configuration, please check the official list of VPN Devices here.
What if you don’t have a compatible VPN appliance such as Ubiquiti, Cisco, F5, Fortinet, etc.?
The good news is, that you can build a Site-to-Site VPN to Azure without having to purchase a VPN appliance.
In this article, we will go over deploying a new Routing and Remote Access (RRAS) server and connecting it to an Azure Gateway. The process is not limited to home labs, but it could be also used for a small office environment where a Site-to-Site VPN to Azure is required.
Prerequisites
To follow this article, you need to have the following:
1) Microsoft Azure subscription. If you don’t have an Azure subscription, you can create a free one here.
2) Azure Virtual Network
- One or more subnets
- Gateway Subnet
- Virtual Network Gateway
- Local Network Gateway
3) Router/firewall on-premises with the application forwarding option.
- Port Forwarding UDP 500 and 4500 => RRAS server.
- Static Public IP address (dynamic public IP will also work but make sure it’s not changing regularly). Please check more on how to update your public IP address if your ISP has changed it.
4) Windows Server (2016, 2019, 2022, or 2025) with Desktop Experience deployed on-premises with two NICs. The Internal NIC represents the local private network, and the External NIC represents the network of the router which is also private but on a different subnet.
- RRAS role installed which will act as the gateway for the home/office network.
- Do not join the server to the domain for security purposes.
Site-to-Site VPN Network Architecture
In this example, the network architecture for the Site-to-Site VPN in our configuration will look like this:
There are a lot of different options and scenarios, but I will use this architecture for the remainder of this guide.
Assuming you have all the prerequisites in place, take now the following steps:
Add the RRAS Role
The first step is to install the Routing and Remote Access (RRAS) role on Windows Server. To speed up the process, I will use PowerShell instead of UI.
On your RRAS server, open Windows PowerShell and run the following command:
# Add RRAS RoleInstall-WindowsFeature -Name RemoteAccess, DirectAccess-VPN, Routing -IncludeManagementTools -VerboseOnce the role is installed, you can verify that the Routing and Remote Access console is installed by typing the following command: rrasmgmt.msc
The service will show stopped at this stage, we will complete the configuration in the next section (Configure Windows RRAS).
Create Azure-side resources
In this section, we will create all the Azure side resources that were mentioned in the prerequisites section. To speed up the process, we will be using the Azure CLI.
Open an Azure Cloud Shell session (https://shell.azure.com/) and specify the subscription that you want to use:
# Set Azure Subscription az account set --subscription "replace_with_your_subscription_id"And then create a resource group. You can update the resource group name and the location based on your needs.
# Creat Azure Resource Groupaz group create --name rg-s2s-vpn-home --location WestEuropeTake now the following steps:
Create an Azure Virtual Network
To create a virtual network, run this command in Azure Cloud Shell named Hub-VNet virtual network and the HubSubnet01 for the first subnet. You can update the IP address prefix based on your needs.
az network vnet create --resource-group rg-s2s-vpn-home --name Hub-VNet-1 --address-prefix 10.1.0.0/16 --subnet-name HubSubnet01 --subnet-prefix 10.1.0.0/24Then run this command in Cloud Shell to add the GatewaySubnet subnet to Hub-VNet-1.
az network vnet subnet create --resource-group rg-s2s-vpn-home --vnet-name Hub-VNet-1 --address-prefix 10.1.255.0/27 --name GatewaySubnetCreate an Azure Virtual Network Gateway
A virtual network gateway must have a Public IP address. You first create the IP address resource and then refer to it when creating your virtual network gateway.
Run the following command to request and create a Dynamic Public IP address. Please note that the only time the Public IP address changes is when the gateway is deleted and re-created. It doesn’t change across resizing, resetting, or other internal maintenance/upgrades of your VPN gateway.
az network public-ip create --name pip-hub-vpn-gw --resource-group rg-s2s-vpn-home --allocation-method DynamicNext, run this command in Cloud Shell to create the vng-hub-vnet-1 virtual network gateway:
If you run this command using the ‘–no-wait‘ parameter, you don’t see any feedback or output. This parameter allows the gateway to be created in the background. It takes around 30 minutes to create a gateway.
az network vnet-gateway create --resource-group rg-s2s-vpn-home --name vng-hub-vnet-1 --public-ip-address pip-hub-vpn-gw --vnet Hub-VNet-1 --gateway-type Vpn --vpn-type RouteBased --sku VpnGw1 --no-waitIn this example, I am using the VPN type as ‘RoutedBased‘ since Route-based VPNs are the preferred connection method for on-premises devices, since they are more resilient to topology changes such as the creation of new subnets, for example. I used the Gateway SKU as ‘VpnGw1‘, you can choose the Gateway SKU that you want to use. There are configuration limitations for certain SKUs. For more information, please check Gateway SKUs.
Create a Local Network Gateway
The local network gateway typically refers to the on-premises location. You give the site a name by which Azure can refer to it, then specify the public IP address of the on-premises VPN/Router device to which you will create a connection.
To check your current public IP address in your home/office, you can run the following PowerShell command:
(Invoke-RestMethod 'http://ipinfo.io/json').IPYou also need to specify the IP address prefixes that will be routed through the virtual network gateway to the RRAS VPN server. The address prefixes you specify here are the prefixes located on your on-premises (internal) network. If your on-premises network changes, you can easily update the prefixes.
Use theaz network local-gateway create command in Cloud Shell to create a local network gateway with multiple local address prefixes representing your home/lab network:
az network local-gateway create --gateway-ip-address 23.99.221.164 --name lgw-s2s-home --resource-group rg-s2s-vpn-home --local-address-prefixes 172.16.20.0/24 172.16.21.0/24Now that all Azure resources are created, let’s move to put all the pieces together.
Configure Port Forwarding
In this step, you need to log in to your router/firewall device and then configure port forwarding rules for UDP ports 500 and 4500 pointing to your RRAS server.
Here is a screenshot of my port forwarding rules:
Configure Windows RRAS
Now it’s time to switch to the Routing and Remote Access Server console on-premises.
Right-click on the server name and select ‘Configure and Enable Routing and Remote Access‘.
Routing and Remote Access Server Setup Wizard will open. Click Next > on the Welcome page.
Select ‘Secure connection between two private networks‘. Click Next > to continue.
Leave the Demand-Dial Connections as default ‘Yes‘. Click Next > to continue.
For the IP Address Assignment, keep the default ‘Automatically‘ assigned. Click Next > to continue.
Then click ‘Finish‘ on the completing wizard ‘Created a secure connection between this network and a private network‘. When you press ‘Finish‘, the service for Routing and Remote Access will start which may take a couple of seconds to complete.
The Demand-Dial Interface Wizard will open. Click Next > on the Welcome page.
Enter a descriptive name for the Interface Name (i.e. AzureGW). This interface will connect to the VPN gateway in Azure.
For the Connection Type, make sure ‘Connect using virtual private networking (VPN)‘ is selected. Click Next > to continue.
For the VPN Type, select ‘IKEv2‘. Click Next > to continue.
In the ‘Destination Address, enter the Azure virtual network Gateway public IP address (Azure side). Click Next > to continue.
For the Protocols and Security, leave the default ‘Route IP packets on this interface‘. Click Next > to continue.
In the Static Routes for Remote Networks, click ‘Add‘ and enter the address space that you set on the virtual network (Azure side), and then set the ‘Metric‘ to 10. Click ‘OK‘ and then click Next > to continue.
In the Dial-Out Credentials leave the default blank. Click Next > to continue.
Then click ‘Finish‘ on completing the Demand-Dial Interface Wizard. When you press ‘Finish‘, you will see a new network interface called ‘AzureGW‘ with a Disconnected state which is expected as shown in the below figure:
Double-click the new interface you just created ‘AzureGW‘ and then select the Options tab. On the Options tab, set the ‘Redial attempts‘ to 3.
On the Security tab, select the preshared key radio button and enter your super-secret shared key here. Please take note of the preshared key here, since you need it in the next section to create the connection.
Then go over IPv4 and create a New Static route… What the Static Routes do, is tell the Routing and Remote Access server that anytime it gets an IP bound for a specific IP address send it out to the VPN interface.
Enter the address space that you set on the virtual network (Azure side) and set the ‘Metric‘ to 10, and make sure to select ‘Use this route to initiate demand-dial connections‘. Click ‘OK‘. This is a repeatable step of what we did before, but you need to add a static route here as well.
Here is the IPv4 Static Routes configuration in my example.
Create the VPN Connection in Azure
In the final step, we need to create a logical VPN connection in Azure.
Run the following command to create the Site-to-Site VPN connection between your virtual network gateway and your on-premises VPN device.
Pay particular attention to the shared key value, which must match the configured shared key value for the RRAS server that you set as described in the previous section.
<strong>az network vpn-connection create --name HubVNet1ToHome --resource-group rg-s2s-vpn-home --vnet-gateway1 vng-hub-vnet-1 --location westeurope --shared-key abc123 --local-gateway2 lgw-s2s-home</strong>After a short while, the connection should be established as shown in the below figure.
Verify Connectivity
Now it’s time to switch to the Routing and Remote Access Server console on-premises and verify that the ‘AzureGW‘ is connected under Network Interfaces.
To test the connection to Azure, we have deployed a VM in the Azure virtual network (Hub-VNet-1). It got a private IP address 10.1.0.4 and without a public IP address.
Testing the connection from an on-premises server to Azure VM (10.1.0.4):
Testing the connection in the opposite direction from the VM in Azure to an on-premises server (172.16.20.153):
There’s more…
By completing all the steps described above, you will be able to connect from on-premises to Azure but nothing else. In other words, you can’t get to the Internet and browse any site from your home/office network.
There is still one more thing to do which is to enable NAT (Network Address Translation) on the Routing and Remote Access Server, so everything on the internal private subnet is going to be masked/NATed behind the external interface.
Switch back to the Routing and Remote Access Server on-premises and run the following PowerShell commands (assuming the name of the interfaces are External and Internal).
$ExternalInterface="External"$InternalInterface="Internal"cmd.exe /c "netsh routing ip nat add interface $ExternalInterface"cmd.exe /c "netsh routing ip nat set interface $ExternalInterface mode=full"cmd.exe /c "netsh routing ip nat add interface $InternalInterface"Now verify that you can browse the Internet from your on-premises private network. As you can see that my (NextHop) is the RRAS server (172.16.20.2) and then to the Internet.
That’s it there you have it!
FAQs
What if your Public IP has changed?
Now, what happened if your ISP changed your Public IP address on-premises?
// The VPN connection will break of course!
To reconnect, you need to find out what is the new Public IP address using the following command:
(Invoke-RestMethod 'http://ipinfo.io/json').IPAnd then go back to the Azure portal and update the IP address in the Local network gateway under ‘Configuration‘ and hit Save as shown in the below figure (of course you can automate this with PowerShell).
Another option instead of updating the public IP address manually in Azure is, if you already own a domain name on Cloudflare for example, and would like to use it for a dynamic IP host, you can accomplish it by setting up a DDNS update client, such as ddclient. ddclient is a program that can run on your Linux server and automatically report your new IP to your domain name provider whenever your public IP changes.
Updated: As of November 20, 2020, Azure now supports FQDN configurations for its Site-to-Site VPN connections. If you have a dynamic public IP address that could change after a certain period, often determined by your Internet service provider (ISP), you can use a constant DNS name with a Dynamic DNS service to point to the current public IP address of your VPN device.
Just make sure to create the Local Network Gateway in Azure with the FQDN Endpoint as shown in the figure below. Your Azure VPN gateway will resolve the FQDN to determine the updated public IP address to connect to.
You need to take some extra steps to configure this, but it works as expected.
Can I deploy RRAS with a Single Network Interface?
Yes, deploying Windows Server RRAS with only one network interface is fully supported and functions seamlessly. There are no functional restrictions when opting for a single network interface.
All features are fully supported in this setup. The decision to use one or two network interfaces is solely a design consideration influenced by various factors, including the existing network configuration and security needs.
We would prefer the dual NIC deployment for security reasons and traffic segmentation.
__
Thank you for reading my blog.
If you have any questions or feedback, please leave a comment.
-Charbel Nemnom-
