RRAS on an Azure VM Is Unsupported: Check Before Design

You open the portal, deploy Windows Server 2022 into a subnet, and the Remote Access role installs cleanly. That sequence proves the installer works, not that Microsoft supports the configuration. The published server-software support guidance for Azure virtual machines lists RRAS among the Windows Server features that are not supported on Azure VMs, and that is an architecture decision rather than a troubleshooting detail. A tunnel that comes up does not move the deployment inside the support boundary.

The walkthrough below starts on the support page, then works outward to requirements and replacement options.

Start on the support page, not in the lab

Read the Azure VM support guidance before you size anything. It separates supported products, roles and features instead of treating Windows Server as one undifferentiated block. Note which row your intended workload actually falls under, because two components that look related in the console can sit in different rows.

Write the citation into the design document while the page is open. Support status is a fact with a source, and a design review that cannot cite it will be argued down by whoever has the demo.

Separate OS support from role and feature support

The same guidance lists Network Policy and Access Services among supported roles while listing RRAS separately as unsupported. Those two entries describe different things, and collapsing them into “remote access is supported” is how a project gets approved on a misreading. The operating system being supported says nothing about a feature that has its own row.

The limitation is also narrower than it is sometimes quoted. It concerns that feature running inside an Azure VM; it does not mean a private network cannot connect to Azure, and it does not say RRAS is unsupported everywhere. An older lab that forwards packets correctly is evidence about packets, not about the support statement.

Keep those two questions apart for the rest of the project: does it work, and is it supported. You will need different answers and sometimes different owners for each.

Write down what the design must actually do

Before choosing a replacement, turn the site list into requirements a product can be measured against:

• Tunnel protocols the branch devices already speak, and whether any site needs dynamic routing.
• Remote prefixes, including any overlapping address space that needs translation rather than routing.
• Route exchange with Azure, and who owns each route table entry.
• Throughput and connection counts the busiest hour must sustain.
• Failover behaviour that the site owners have agreed to, not just the one you can build.

NAT is the item that gets skipped and then decides the whole design. A device that can establish IPsec may still translate addresses differently from the RRAS deployment it replaces, which changes what the branch sees as source addresses and what your logs record.

Take the list to the network owners and confirm it before any product discussion. Ambiguous requirements turn every vendor comparison into a preference argument.

Evaluate replacements against those requirements

Azure's managed connectivity services and vendor-supported network virtual appliances both need scoring against the same list. Do not assume either is a drop-in equivalent of an RRAS VM because it can terminate IPsec: the NAT model, route ownership and high-availability design decide how existing sites connect and where their replies return. Score each candidate on paper against the list and write down which requirements it fails, because that note is what makes the choice reviewable later.

A load balancer in front of two appliance VMs is not high availability by itself. It supplies a front end, not synchronized tunnel state, and a failover that drops every session is a design choice somebody has to make on purpose. Ask the appliance vendor what the supported HA pattern is and whether it matches the availability the sites were promised. Test the failover before those sites depend on it, and treat every dropped session as a finding rather than a surprise.

Where the requirement is genuinely simple — one site, one prefix, no overlap — a managed service usually wins on operational cost. Where translation and dynamic routing are both in play, the appliance path may be the only fit, and that is a reason to plan a longer migration rather than to keep the unsupported VM.

If an RRAS VM is already running

Discovery is not a reason to delete it. Plan the change around the dependencies that VM accumulated: routes other subnets rely on, NAT rules that hide source addresses, and whatever monitoring has learned to expect its address. Preserve the required routes and a tested recovery path while the supported target is designed and validated alongside.

Keep supportability and technical diagnosis as separate findings throughout. An unsupported arrangement can also have an ordinary routing error, and correcting that error does not change its support status. Both statements belong in the report, and neither one cancels the other.

Close the walkthrough by recording the support citation, the requirements list, the chosen replacement and the cutover order. Those four items are what an auditor or a new team member will ask for first.