Azure’s Default Outbound Access Changes: Guidance for Azure Virtual Desktop Customers

After March 31, 2026, newly created Azure Virtual Networks (VNets) will no longer have default outbound internet access (DOA) enabled by default. Azure Virtual Desktop customers must configure outbound connectivity explicitly when setting up new VNets. This post explains what’s changing, who’s impacted, and the recommended actions, including Private Subnets.

What is Default Outbound Access (DOA)?

Default Outbound Access is Azure’s legacy behavior that allowed all resources in a virtual network to reach the public internet without configuring a specific internet egress path. This allowed telemetry, Windows activation, updates, and other service dependencies to reach external endpoints even when no explicit outbound connectivity method was configured.

What’s changing?

After March 31, 2026, as detailed in Azure’s communications, Azure will no longer enable DOA by default for new virtual networks. Instead, the VNet will be configured for Private Subnet option, allowing you to designate subnets without internet access for improved isolation and compliance. These changes encourage more intentional, secure network configurations while offering flexibility for different workload needs. Disabling Private Subnet option will allow administrators to restore DOA capabilities to the VNet, although Microsoft strongly recommends using NAT Gateway to provide outbound Internet access for session hosts.

Impact on Azure Virtual Desktop Customers

For Azure Virtual Desktop deployments created after March 31, 2026, outbound internet access must be explicitly configured, otherwise deployment and connectivity of the Session Hosts will fail. Existing VNets remain unaffected and will continue to use the configured internet access method.

What You Should Do

To prepare for Azure’s Default Outbound Access changes and ensure your Azure Virtual Desktop deployments remain secure and functional.

Recommendations

• Update deployment plans to ensure either an explicit NAT, such as a NAT Gateway or Default Outbound access (not recommended) is enabled by disabling the Private Subnet option.
• Test connectivity to ensure all services dependent on outbound access continue to function as expected.

Supported Outbound Access Methods

To maintain connectivity, choose one of these supported methods:

1. NAT Gateway (recommended)

Note: Direct RDP Shortpath (UDP over STUN) cannot be established through a NAT Gateway because its symmetric NAT policy prevents direct UDP connectivity over public networks.

 

 

2. Azure Standard Load Balancer

 

 

3. Public IP address on a VM

 

 

4. Azure Firewall or third-party Network Virtual Appliance (NVA). Note, it is not recommended to route RDP or other long-lived connections through Azure Firewall or any other network virtual appliance which allows for automatic scale-in. A direct method such as NAT Gateway should be used.

More information about the pros and cons of each method can be found at Default Outbound Access.

Resources:

• Azure updates | Microsoft Azure
• Default Outbound Access in Azure
• Transition to an explicit method of public connectivity| Microsoft Learn
• Quickstart: Create a NAT Gateway

Quick FAQ

Does this affect existing VNets? No. Only VNets created after March 31, 2026, are affected.  Existing VNets will continue to operate as normal.

What if I do nothing on a new VNet? Host pool deployment will fail, and connectivity will fail because the VNet does not have internet access. Configure NAT Gateway or another supported method before starting a host pool deployment.

Why do Azure Virtual Desktop session hosts need outbound internet access? Many Azure Virtual Desktop functions depend on the session host having outbound access to Microsoft services. Without configuring NAT Gateway or another supported method of explicit outbound for the VNet, Azure Virtual Desktop will not deploy or function correctly.

What are the required endpoints? Please see https://learn.microsoft.com/azure/virtual-desktop/required-fqdn-endpoint?tabs=azure for a list of the endpoints required.

Why might peer-to-peer connectivity using STUN-based UDP hole punching not work when using NAT Gateway? NAT Gateway uses a type of network address translation that does not support cone symmetric NAT behavior. This can prevent STUN (Simple Traversal Underneath NAT) based UDP hole punching, commonly used for establishing peer-to-peer connections, from working as expected. If your application relies on reliable UDP connectivity between peers, STUN may revert to TURN (Traversal Using Relays around NAT) in some instances. TURN relays traffic between endpoints, ensuring consistent connectivity even when direct peer-to-peer paths are blocked. This helps maintain smooth real-time experiences for your users.

What explicit outbound options support STUN? Azure Standard Load Balancer supports UDP over STUN.

How do I configure Azure Firewall? For additional security you can configure Azure Firewall using these instructions: https://learn.microsoft.com/en-us/azure/firewall/protect-azure-virtual-desktop?context=/azure/virtual-desktop/context/context

. It is strongly recommended that a direct method of access is used for RDP and other long-lived connections such as VPN or Secure Web Gateway tunnels. This is due to devices such as Azure firewall scaling in when load is low which can disrupt connectivity.

Wrap-up

Azure’s change reinforces intentional networking for better security. By planning explicit egress, Azure Virtual Desktop customers can stay compliant and keep session hosts reliably connected.