Back to Announcements

Information – NHSmail Intune: New Windows 365 IP Subnet for RDP Connectivity

Announcements Arpan Das

26/09/2024 13:07:00 PM

Microsoft are implementing a change to the core TCP-based RDP traffic for Cloud PC connections. This traffic uses the wildcard fully qualified domain name (FQDN) *.wvd.microsoft.com, which is outlined in the documentation. While the FQDN remains unchanged, the underlying IP addresses associated with it will be updated.

Key Changes:

All core TCP-based RDP traffic for connections to Cloud PCs is managed through the wildcard FQDN *.wvd.microsoft.com, as detailed in this article. This FQDN is included among the required endpoints and remains unchanged

Some customers prefer using IP addresses, rather than FQDN, to optimize connectivity. These addresses are part of the WindowsVirtualDesktop Azure Service tag, which currently contains many /32 IPv4 addresses. As the service expands, new IP addresses are regularly added to enhance connectivity for users. Frequent updating can create challenges for customers who manually extract IP addresses for configuring VPNs, Secure Web Gateways (SWG), or proxy bypass rules.

To simplify and minimize the need for constant updates, Microsoft are transitioning to a new, dedicated subnet: 40.64.144.0/20. This subnet will handle RDP Reverse Connect traffic for Windows 365. The existing port (TCP:443) and FQDN (*.wvd.microsoft.com) will remain unchanged.

What You Need to Do to Prepare:

Organisations who manually extract IP information from the service tag to configure routes or firewall rules in their on-premises environments, or to bypass traffic from VPN or SWG tunnels, should ensure they have updated their configurations to include the new subnet.

You can enable connectivity for this traffic within your environment by the following:

  • Route this traffic directly out of the nearest egress point.
  • Exempt the traffic from TLS inspection.
  • Ensure the traffic is not proxied.
  • Exclude the traffic from VPN/SWG tunnels.

Organizations that utilize the WindowsVirtualDesktop Azure Service tag directly in their Azure configurations, such as in User-Defined Route (UDR) or firewall rules, do not need to take any action. The new subnet has already been included in the service tag.

Additionally, any customers using only the wildcard FQDN *.wvd.microsoft.com to allow access for this traffic also do not need to take any action.

Configuration Guidance

Organizations that utilize the WindowsVirtualDesktop Azure Service tag directly in their Azure configurations, such as in User-Defined Route (UDR) or firewall rules, do not need to take any action. The new subnet has already been included in the service tag.

  • Azure Network Connections for Windows 365: Make sure the traffic is routed directly from the vNet used for Cloud PCs or Session hosts. If necessary, adjust UDRs and firewall allow lists, and disable TLS inspection for this traffic. Ensure the traffic bypasses any proxy path and takes the direct route configured, so it stays within Microsoft’s managed network.
  • Proxy/VPN/SWG software on Cloud PCs: This traffic should be exempted from any proxy or VPN tunnels on the device, allowing it to take a direct path. For organisations using Windows 365’s Microsoft-hosted network, this direct path is already available when bypassing proxy, SWG, or VPN tunnels.
  • Physical device-side configuration
  • Ensure traffic from physical devices follows the same optimizations. Bypassing proxy, VPN, or SWG configurations, and is routed directly via the internet to the service.

Further support

If you require any support regarding the changes above , please raise an Intune incident ticket by contacting helpdesk@nhs.net or via the Helpdesk Self-Service.

back to top