Extending an On-Premises Network to Azure Using Site-to-Site VPN and Windows Server 2019 RRAS
Hybrid Cloud Connectivity is one of the most common Enterprise Networking scenarios. Organizations often need secure communication between On-Premises Infrastructure and Workloads Running in Microsoft Azure. A Site-to-Site VPN provides an Encrypted Tunnel between an On-Premises Network and an Azure Virtual Network, allowing Systems on both Sides to Communicate as if they were part of the same Private Network.
In this architecture, Azure uses a Virtual Network Gateway as the VPN Endpoint inside the Azure Virtual Network. On the On-Premises Side, a Windows Server 2019 System configured with the Routing and Remote Access Service Role acts as the VPN Device. The Two Endpoints establish an IPsec Tunnel using a Shared Key and Defined Network Address Spaces.
The following steps describe how to extend an on-premises network to Azure by using a Site-to-Site VPN connection.
1. Create the Azure Resource Group
The first step is to create a dedicated Azure Resource Group that will contain all networking components related to the VPN deployment. Using a separate resource group simplifies management, monitoring, access control, and lifecycle management of the solution.
Typical resources placed in this resource group include the virtual network, the VPN gateway, the public IP address associated with the gateway, the local network gateway object, and the Site-to-Site VPN connection.
2. Create the Azure Virtual Network
After the resource group is created, deploy an Azure Virtual Network that will host the Azure workloads and the VPN gateway. The address space selected for the virtual network must not overlap with the on-premises network address space. Overlapping IP ranges will prevent routing from functioning correctly.
Configuration:
Virtual Network Address Space: 10.0.0.0/24
Create two Subnets inside the Virtual Network:
Default Workload Subnet: 10.0.0.0/26
GatewaySubnet: 10.0.0.96/28
The Subnet used for the Azure VPN Gateway must be named GatewaySubnet exactly. Azure requires this Reserved Subnet Name when deploying a Virtual Network Gateway. No Virtual Machines or other Resources should be deployed into this Subnet because it is reserved exclusively for the VPN Gateway Infrastructure.
3. Create the Local Network Gateway
The Local Network Gateway represents the On-Premises VPN Endpoint in Azure. It does not deploy any resources in the On-Premises Environment; rather, it defines the Remote VPN Endpoint and the Internal Networks that exist Behind that Endpoint.
During the configuration of the Local Network Gateway, the Administrator must provide the Public IP Address of the On-Premises VPN Device. If the Windows Server RRAS system is located behind a Firewall or NAT Device, the Public IP of that Firewall must be used.
In addition to the Public IP, the Internal Address Spaces of the On-Premises Network must be defined. These Address Ranges allow Azure to Route Traffic to the appropriate Networks through the VPN Tunnel.
5. Create the Public IP Address for the Azure VPN Gateway
Before creating the Virtual Network Gateway, a Public IP Address Resource must be created. This Public IP will be assigned to the Azure VPN Gateway and will Serve as the Remote Endpoint for the On-Premises VPN Connection.
Use a Standard SKU Public IP Address because it provides better reliability and aligns with modern Azure Networking Standards.
Once the Public IP is created, it will be selected during the creation of the Virtual Network Gateway.
6. Create the Azure Virtual Network Gateway
The Azure Virtual Network Gateway acts as the Azure-side VPN device that terminates the encrypted IPsec tunnel. This gateway is deployed into the GatewaySubnet created earlier.
Recommended configuration includes the following parameters:
Gateway Type: VPN
VPN Type: Route-Based
Public IP: Standard Public IP (created previously)
Virtual Network: (The Azure Virtual Network created in the earlier step)
SKU: (Select an appropriate VPN Gateway SKU depending on Performance and Availability requirements.)
The deployment of the Virtual Network Gateway may take between 30 and 45 minutes because Azure must provision Dedicated Gateway Infrastructure within the GatewaySubnet.
7. Create the Site-to-Site VPN Connection
After the Virtual Network Gateway has been successfully deployed, the Site-to-Site VPN Connection between the Azure Gateway and the On-Premises Environment.
This step links the Virtual Network Gateway to the Local Network Gateway created earlier.
During the configuration process, define a Shared Key, also known as a Pre-Shared Key.
This key will be used to Authenticate the IPsec Tunnel between Azure and the On-Premises RRAS Server.
The same Shared Key must later be configured on the RRAS Server during VPN Configuration.
8. Deploy a Virtual Machine in Azure for Connectivity Testing
To verify connectivity after the VPN Tunnel is established, deploy a Virtual Machine inside the Default Workload Subnet of the Azure Virtual Network.
This test machine can later be used to validate communication with the On-Premises Network using RDP, Ping (if allowed), File Sharing, or other Application Protocols.
9. Deploy Windows Server 2019 with the RRAS Role
On the On-Premises Network, deploy or configure a Windows Server 2019 system that will serve as the VPN Endpoint.
Install the Remote Access Role and enable the Routing and Remote Access Service Role Service. This Server will function as the On-Premises VPN Gateway.
The Server must have connectivity to the Internet and should ideally have a Static Public IP Address. If the RRAS Server is Located Behind a Firewall, the Firewall must allow and Forward the required IPsec Traffic to the RRAS Server.
10. Configure RRAS for Site-to-Site VPN
Using the Routing and Remote Access console, configure a Site-to-Site VPN connection.
This process involves creating a Demand-Dial Interface that connects to the Azure VPN Gateway. During the configuration, specify the Public IP Address of the Azure Virtual Network Gateway as the Remote Endpoint.
The Shared Key defined earlier in Azure must also be configured on the RRAS Server so that both VPN Endpoints can Authenticate Each Other.
The VPN connection should be configured to use IPsec Encryption with the appropriate Authentication settings supported by Azure.
11. Add Static Routes for Azure Networks
After the VPN Interface is created, add a Static Route on the RRAS Server that directs Traffic for the Azure Virtual Network through the VPN Tunnel.
Example:
Destination Network: 10.0.0.0/24
Interface: Demand-Dial Interface connected to Azure
This configuration ensures that Traffic originating from the On-Premises Environment destined for Azure is Properly Routed through the Encrypted VPN Tunnel.
12. Test Connectivity Between On-Premises and Azure
Once both sides of the VPN connection are configured, verify that the tunnel is active.
In Azure, the VPN connection status should display Connected. On the RRAS Server, the Demand-Dial Interface should indicate that the Tunnel is Established.
After confirming the Tunnel Status, Test Connectivity between the Two Environments.
Common validation tests include connecting to Azure Virtual Machines using Remote Desktop, Testing Ping Connectivity where ICMP is allowed, accessing Shared Folders using SMB Drive Mapping, and Verifying Application-Specific Traffic.
Successful communication confirms that the Hybrid Connectivity between the On-Premises Network and Azure has been established correctly.
Conclusion
A Site-to-Site VPN provides a secure and reliable method for extending an on-premises network into Azure. By using Azure Virtual Network Gateway on the cloud side and Windows Server 2019 with the RRAS role on the on-premises side, organizations can create encrypted communication channels that enable hybrid workloads, migration scenarios, and seamless connectivity between environments.
This architecture is widely used in hybrid cloud deployments because it allows organizations to integrate existing infrastructure with cloud-based resources while maintaining security and centralized network control.
0 comments