You dont have javascript enabled! Please enable it! Deploy Site-to-Site VPN Between Azure And Windows RRAS Server - CHARBEL NEMNOM - MVP | MCT | CCSP | CISM - Cloud & CyberSecurity

Deploy Site-to-Site VPN Between Azure and Windows RRAS Server

8 Min. Read

This article is written for home/office scenarios, it’s NOT recommended for production.

In this article, we will show you how to deploy a Site-to-Site VPN between Azure and Windows RRAS Server.

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.

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:

Site-to-Site VPN Network Architecture
Site-to-Site VPN Network Architecture

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 Role
Install-WindowsFeature -Name RemoteAccess, DirectAccess-VPN, Routing -IncludeManagementTools -Verbose

Once 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).

Deploy Site-to-Site VPN Between Azure and Windows RRAS Server 1

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 Group
az group create --name rg-s2s-vpn-home --location WestEurope

Take 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/24

Then 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 GatewaySubnet

Create 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 Dynamic

Next, 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-wait

In 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').IP

You 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 the az 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/24

Now 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:

Deploy Site-to-Site VPN Between Azure and Windows RRAS Server 2

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‘.

Deploy Site-to-Site VPN Between Azure and Windows RRAS Server 3

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.

Deploy Site-to-Site VPN Between Azure and Windows RRAS Server 4

Leave the Demand-Dial Connections as default ‘Yes‘. Click Next > to continue.

Deploy Site-to-Site VPN Between Azure and Windows RRAS Server 5

For the IP Address Assignment, keep the default ‘Automatically‘ assigned. Click Next > to continue.

Deploy Site-to-Site VPN Between Azure and Windows RRAS Server 6

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.

Deploy Site-to-Site VPN Between Azure and Windows RRAS Server 7

For the Connection Type, make sure ‘Connect using virtual private networking (VPN)‘ is selected. Click Next > to continue.

Deploy Site-to-Site VPN Between Azure and Windows RRAS Server 8

For the VPN Type, select ‘IKEv2‘. Click Next > to continue.

Deploy Site-to-Site VPN Between Azure and Windows RRAS Server 9

In the ‘Destination Address, enter the Azure virtual network Gateway public IP address (Azure side). Click Next > to continue.

Deploy Site-to-Site VPN Between Azure and Windows RRAS Server 10

For the Protocols and Security, leave the default ‘Route IP packets on this interface‘. Click Next > to continue.

Deploy Site-to-Site VPN Between Azure and Windows RRAS Server 11

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.

Deploy Site-to-Site VPN Between Azure and Windows RRAS Server 12

In the Dial-Out Credentials leave the default blank. Click Next > to continue.

Deploy Site-to-Site VPN Between Azure and Windows RRAS Server 13

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:

Deploy Site-to-Site VPN Between Azure and Windows RRAS Server 14

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.

Deploy Site-to-Site VPN Between Azure and Windows RRAS Server 15

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.

Deploy Site-to-Site VPN Between Azure and Windows RRAS Server 16

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.

Deploy Site-to-Site VPN Between Azure and Windows RRAS Server 17

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.

Deploy Site-to-Site VPN Between Azure and Windows RRAS Server 18

Here is the IPv4 Static Routes configuration in my example.

Deploy Site-to-Site VPN Between Azure and Windows RRAS Server 19

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.

Deploy Site-to-Site VPN Between Azure and Windows RRAS Server 20

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.

Deploy Site-to-Site VPN Between Azure and Windows RRAS Server 21

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.

Deploy Site-to-Site VPN Between Azure and Windows RRAS Server 22

Testing the connection from an on-premises server to Azure VM (10.1.0.4):

Deploy Site-to-Site VPN Between Azure and Windows RRAS Server 23

Testing the connection in the opposite direction from the VM in Azure to an on-premises server (172.16.20.153):

Deploy Site-to-Site VPN Between Azure and Windows RRAS Server 24

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.

Deploy Site-to-Site VPN Between Azure and Windows RRAS Server 25

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').IP

And 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).

Local network gateway IP configuration
Local network gateway IP configuration

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.

Azure FQDN Site-to-Site VPN
Azure FQDN Site-to-Site VPN

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-

Photo of author
About the Author:
Charbel Nemnom
Charbel Nemnom is a Senior Cloud Architect with 21+ years of IT experience. As a Swiss Certified Information Security Manager (ISM), CCSP, CISM, Microsoft MVP, and MCT, he excels in optimizing mission-critical enterprise systems. His extensive practical knowledge spans complex system design, network architecture, business continuity, and cloud security, establishing him as an authoritative and trustworthy expert in the field. Charbel frequently writes about Cloud, Cybersecurity, and IT Certifications.
Previous

Update Rollup 2 for System Center 2019 is Now Available

SysAdmin Day, Win an #Amazon Voucher With @AltaroSoftware

Next

14 thoughts on “Deploy Site-to-Site VPN Between Azure and Windows RRAS Server”

Leave a comment...

  1. The following command was not found: routing ip nat add interface Azure External.
    The following command was not found: routing ip nat set interface Azure External mode=full.
    The following command was not found: routing ip nat add interface Lab Internal.

    netsh>routing
    The following command was not found: routing.
    netsh>?

    The following commands are available:

    Commands in this context:
    .. – Goes up one context level.
    ? – Displays a list of commands.
    abort – Discards changes made while in offline mode.
    add – Adds a configuration entry to a list of entries.
    advfirewall – Changes to the `netsh advfirewall’ context.
    alias – Adds an alias.
    branchcache – Changes to the `netsh branchcache’ context.
    bridge – Changes to the `netsh bridge’ context.
    bye – Exits the program.
    commit – Commits changes made while in offline mode.
    delete – Deletes a configuration entry from a list of entries.
    dhcpclient – Changes to the `netsh dhcpclient’ context.
    dnsclient – Changes to the `netsh dnsclient’ context.
    dump – Displays a configuration script.
    exec – Runs a script file.
    exit – Exits the program.
    firewall – Changes to the `netsh firewall’ context.
    help – Displays a list of commands.
    http – Changes to the `netsh http’ context.
    interface – Changes to the `netsh interface’ context.
    ipsec – Changes to the `netsh ipsec’ context.
    ipsecdosprotection – Changes to the `netsh ipsecdosprotection’ context.
    lan – Changes to the `netsh lan’ context.
    namespace – Changes to the `netsh namespace’ context.
    netio – Changes to the `netsh netio’ context.
    offline – Sets the current mode to offline.
    online – Sets the current mode to online.
    popd – Pops a context from the stack.
    pushd – Pushes current context on stack.
    quit – Exits the program.
    ras – Changes to the `netsh ras’ context.
    rpc – Changes to the `netsh rpc’ context.
    set – Updates configuration settings.
    show – Displays information.
    trace – Changes to the `netsh trace’ context.
    unalias – Deletes an alias.
    wfp – Changes to the `netsh wfp’ context.
    winhttp – Changes to the `netsh winhttp’ context.
    winsock – Changes to the `netsh winsock’ context.

    Is something missing from my 2019 RRAS server?

  2. Hello Carl, thanks for the comment. Hope you are doing well.
    Three questions:
    1) Did you install the management tools for the RRAS role? Install-WindowsFeature -Name RemoteAccess, DirectAccess-VPN, Routing -IncludeManagementTools -Verbose
    2) Did you run the commands using the PowerShell console or Command Prompt?
    3) I have seen that you have spaces in your Network Interface names ‘Azure External’ and ‘Lab Internal’
    Please double-check. Hope this helps!

  3. I’m setting up a home lab and this post has saved me time and effort, it worked first time.
    Thank you very much.

  4. Thank you, Robert for the feedback and comment, much appreciated!
    I am happy to hear that it worked for you first time.
    All the best,

  5. Hello Charbel,
    Would it be possible to do the same but with RRAS having only one interface (internal)?
    Port forward would still be possible and clients would need static routes to local RRAS to reach Azure side.

  6. Hello Dražen, thanks for the comment and the question!
    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.
    I would prefer the dual NIC deployment for security reasons and traffic segmentation.
    Hope it helps!

  7. Hello! Great document, but I do something wrong. I can connect from OnPrem to Azure resources, but from Azure I can only connect to the RRAS machine.
    What am I missing?

  8. Hello Kent, thanks for the comment and feedback!
    Could you please make sure that the on-premises machine(s) have their Gateway set to the RRAS internal IP address?
    I believe that you also configured the Static Routes on the RRAS server as well, right?
    How many virtual networks do you have in Azure? Is it a Hub and Spoke network topology, or only one single VNet?
    Are you using virtual network peering in Azure?
    Hope it helps!

  9. I am running into these 3 issues:
    1. From Azure, I can ping my RRAS server only and nothing else on my home network.
    2. From any other on-premises computer, I can’t connect to anything in Azure.

    I see you made a comment to another person “Make sure that the on-premises machines have their Gateway set to the RRAS internal IP address” I’m not quite sure what you mean by this. I already setup my port forwarding rules on my router. You don’t mean for me to go into 50 other computers on my home network and manually change the gateway address (which is my router) to the RRAS as the new gateway? If you could elaborate on this, it would be helpful.

    None of my other on-premises devices know about the new network interface you had us create so it makes sense that those other computers won’t be able to send/receive any pings.

    Any advice you have would be great!

  10. Hello Steve, Thanks for your comment and for sharing the details of the issues you are facing! Let’s address each one step by step:

    Issue 1: Azure can only ping RRAS server
    This issue typically occurs when the routing on your RRAS server is not configured correctly or when there is a firewall rule blocking the traffic. Here are some steps to troubleshoot this:
    1. Check the routing table on your RRAS server to ensure that routes to your internal network are correctly configured.
    2. Ensure firewall rules on the RRAS server and Azure Network Security Group (NSG) allow ICMP (ping) traffic to and from the internal network.
    3. Verify the RRAS server’s NAT configuration to make sure it’s correctly forwarding traffic between the Azure VPN and your internal network.

    Issue 2: On-premises computers can’t connect to Azure
    This is often related to routing and gateway configuration on your local network. When I mentioned that on-premises machines should have their gateway set to the RRAS internal IP address, I was suggesting that traffic intended for the Azure network needs to be routed through the RRAS server, because RRAS is acting as a router in this case and knows how to reach network based on his routing table. Here’s a more detailed explanation:

    1. Centralized Configuration via DHCP (Option 1): If manually changing the gateway on each device is not feasible, you can configure your DHCP server to set the RRAS server’s internal IP as the default gateway for all devices. This way, devices will automatically receive the correct gateway configuration.
    2. Static Routes (Option 2): Alternatively, you can add a static route on your router. This route will direct traffic destined for the Azure network through the RRAS server without changing the gateway on every device.
    For example, if your Azure network is 10.1.0.0/16 and your RRAS server’s internal IP is 192.168.1.2, you would add a route like this:

    Destination: 10.1.0.0
    Subnet Mask: 255.255.0.0
    Gateway: 192.168.1.2

    The exact steps to add a static route depend on your router’s model and firmware.
    It’s correct that other on-premises devices are unaware of the new network interface. By using one of the methods above, traffic from these devices will be correctly routed through the RRAS server to reach Azure.

    In summary, to resolve your issues:
    1) Verify and adjust the routing and firewall settings on your RRAS server and Azure NSG.
    2) Configure your network to route traffic through the RRAS server using DHCP settings or static routes on your router.
    Hope it helps!

  11. Thank you for that info. I am now able to access Azure VM’s using private IP addresses and can access network printers from an Azure VM. However, I have another issue and I don’t know if it’s the network adapter or something I did incorrectly. When I log into an Azure VM (private IP ) from the RRAS server and copy/paste a large file from the Azure VM to the RRAS server, it works fine. However. when I log into an Azure VM (private IP) from a different on-premises computer, copy/paste a large file from the VM to the computer, in about 10 seconds, the network connectivity on the RRAS server completely drops. I can’t ping to or from it and all RRAS functions stop working. To fix the issue. I have to unplug and replug the cable. The cable, in this case is an ethernet to USB-C adapter since the ethernet port and wifi do not work with this device. Do you think there is some configuration I didn’t setup correctly with RRAS?

  12. Hello Steve, thanks for the update! It sounds like you’ve made significant progress, which is great to hear.
    The issue you’re describing now appears to be related to the stability and reliability of the network adapter on your RRAS server, particularly since the network drops completely when transferring large files. How much the large file size is in GB?

    Here are some steps to troubleshoot and potentially resolve this issue:
    1) Ensure that the network adapter on the RRAS server is configured correctly (Disable Power Saving/Update Drivers/Check settings such as Jumbo Frames, Large Send Offload, and others to see if tweaking them improves stability).
    2) Since you’re using a USB-C to Ethernet adapter, consider using a high-quality adapter from a reputable manufacturer. Some adapters might not handle high data throughput well. If possible, try using a different USB-C to Ethernet adapter to see if the issue persists. Personally, I prefer using built-in Ethernet adapters.
    3) Monitor the network load on your RRAS server during file transfers: Use the Resource Monitor or Performance Monitor to keep an eye on the network utilization and see if any other resources (CPU, RAM) are being maxed out during the transfer. Ensure that the network bandwidth is not being overwhelmed and saturated, causing instability.
    4) Check the Event Viewer on your RRAS server for any logs or error messages related to RRAS or network connectivity. This can provide clues as to why the network drops.
    5) Since your RRAS server is using an adapter due to non-functional built-in Ethernet and Wi-Fi ports, it’s worth considering if possible to use a different device as your RRAS server to see if the issue persists.
    If after trying these steps the issue still occurs, it might be worth considering upgrading the RRAS server (CPU/RAM/Network) to ensure it can handle the network demands effectively.

    I am sorry, but I cannot support further in the comment section. If you would like to work on this, please feel free to reach out via email by filling out this form. Thanks!

  13. Hello Charbel,

    I don’t expect you to post this. I just want to say thank you for this blog and your responses. Everything is running perfectly now thanks to your instructions and feedback. Just want you to know your site is helping out a lot of folks, especially me. When a person googles “Azure VPN Gateway with RRAS”, your site comes up at the top. (Microsoft really should be thanking you!)

    I did have to setup static routes in my router btw, open up firewall rules on the RRAS server for the private IP ranges in the Azure Vnets, and replaced the ethernet to usb-c adapter.

  14. Thank you so much, Steve for your kind words and for sharing your experience!
    I’m thrilled to hear that everything is running perfectly now and that the instructions and feedback were helpful.
    Your success is exactly why I maintain this blog. It’s great to know that the site is making a positive impact.
    All the best!

Let us know what you think, or ask a question...