{"id":8569,"date":"2025-01-26T09:00:13","date_gmt":"2025-01-26T17:00:13","guid":{"rendered":"https:\/\/www.microsoft.com\/insidetrack\/blog\/?p=8569"},"modified":"2025-02-04T15:58:43","modified_gmt":"2025-02-04T23:58:43","slug":"enhancing-vpn-performance-at-microsoft","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/insidetrack\/blog\/enhancing-vpn-performance-at-microsoft\/","title":{"rendered":"Enhancing VPN performance at Microsoft"},"content":{"rendered":"

\"Microsoft[Editor\u2019s note: This content was written to highlight a particular event or moment in time. Although that moment has passed, we\u2019re republishing it here so you can see what our thinking and experience was like at the time.]<\/em><\/p>\n

Modern workers are increasingly mobile and require the flexibility to get work done outside of the office. Here at Microsoft headquarters in the Puget Sound area of Washington State, every weekday an average of 45,000 to 55,000 Microsoft employees use a virtual private network (VPN) connection to remotely connect to the corporate network. As part of our overall Zero Trust Strategy<\/a>, we have redesigned our VPN infrastructure, something that has simplified our design and let us consolidate our access points. This has enabled us to increase capacity and reliability, while also reducing reliance on VPN by moving services and applications to the cloud.<\/p>\n

Providing a seamless remote access experience<\/h2>\n

Remote access at Microsoft is reliant on the VPN client, our VPN infrastructure, and public cloud services. We have had several iterative designs of the VPN service inside Microsoft. Regional weather events in the past required large increases in employees working from home, heavily taxing the VPN infrastructure and requiring a completely new design. Three years ago, we built an entirely new VPN infrastructure, a hybrid design, using Microsoft Azure Active Directory (Azure AD) load balancing and identity services with gateway appliances across our global sites.<\/p>\n

Key to our success in the remote access experience was our decision to deploy a split-tunneled configuration for the majority of employees. We have migrated nearly 100% of previously on-premises resources into Microsoft Azure and Microsoft Office 365. Our continued efforts in application modernization<\/a> are reducing the traffic on our private corporate networks as cloud-native architectures allow direct internet connections. The shift to internet-accessable applications and a split-tunneled VPN design has dramatically reduced the load on VPN servers in most areas of the world.<\/p>\n

Using VPN profiles to improve the user experience<\/h3>\n

We use Microsoft Endpoint Manager to manage our domain-joined and Microsoft Azure AD\u2013joined computers and mobile devices that have enrolled in the service. In our configuration, VPN profiles are replicated through Microsoft Intune and applied to enrolled devices; these include certificate issuance that we create in Configuration Manager for Windows 10 devices. We support Mac and Linux device VPN connectivity with a third-party client using SAML-based authentication.<\/p>\n

We use certificate-based authentication (public key infrastructure, or PKI) and multi\u2011factor authentication solutions. When employees first use the Auto-On VPN connection profile, they are prompted to authenticate strongly. Our VPN infrastructure supports Windows Hello for Business and Multi-Factor Authentication. It stores a cryptographically protected certificate upon successful authentication that allows for either persistent or automatic connection.<\/p>\n

For more information about how we use Microsoft Intune and Endpoint Manager as part of our device management strategy, see Managing Windows 10 devices with Microsoft Intune<\/a>.<\/p>\n

Configuring and installing VPN connection profiles<\/h4>\n

We created VPN profiles that contain all the information a device requires to connect to the corporate network, including the supported authentication methods and the VPN gateways that the device should connect to. We created the connection profiles for domain-joined and Microsoft Intune\u2013managed devices using Microsoft Endpoint Manager.<\/p>\n

For more information about creating VPN profiles, see VPN profiles in Configuration Manager<\/a> and How to Create VPN Profiles in Configuration Manager<\/a>.<\/p>\n

The Microsoft Intune custom profile for Intune-managed devices uses Open Mobile Alliance Uniform Resource Identifier (OMA-URI) settings with XML data type, as illustrated below.<\/p>\n

\"Creating
Creating a Profile XML and editing the OMA-URI settings to create a connection profile in System Center Configuration Manager.<\/figcaption><\/figure>\n

Installing the VPN connection profile<\/h4>\n

The VPN connection profile is installed using a script on domain-joined computers running Windows\u00a010, through a policy in Endpoint Manager.<\/p>\n

For more information about how we use Microsoft Intune as part of our mobile device management strategy, see Mobile device management at Microsoft<\/a>.<\/p>\n

Conditional Access<\/h3>\n

We use an optional feature that checks the device health and corporate policies before allowing it to connect. Conditional Access<\/a> is supported with connection profiles, and we\u2019ve started using this feature in our environment.<\/p>\n

Rather than just relying on the managed device certificate for a \u201cpass\u201d or \u201cfail\u201d for VPN connection, Conditional Access places machines in a quarantined state while checking for the latest required security updates and antivirus definitions to help ensure that the system isn\u2019t introducing risk. On every connection attempt, the system health check looks for a certificate that the device is still compliant with corporate policy.<\/p>\n

Certificate and device enrollment<\/h3>\n

We use an Azure AD certificate for single sign-on to the VPN connection profile. And we currently use Simple Certificate Enrollment Protocol (SCEP) and Network Device Enrollment Service (NDES) to deploy certificates to our mobile devices via Microsoft Endpoint Manager. The SCEP certificate we use is for wireless and VPN. NDES allows software on routers and other network devices running without domain credentials to obtain certificates based on the SCEP.<\/p>\n

NDES performs the following functions:<\/p>\n

    \n
  1. It generates and provides one-time enrollment passwords to administrators.<\/li>\n
  2. It submits enrollment requests to the certificate authority (CA).<\/li>\n
  3. It retrieves enrolled certificates from the CA and forwards them to the network device.<\/li>\n<\/ol>\n

    For more information about deploying NDES, including best practices, see Securing and Hardening Network Device Enrollment Service for Microsoft Intune and System Center Configuration Manager<\/a>.<\/p>\n

    VPN client connection flow<\/h3>\n

    The diagram below illustrates the VPN client-side connection flow.<\/p>\n

    \"A
    The client-side VPN connection flow.<\/figcaption><\/figure>\n

    When a device-compliance\u2013enabled VPN connection profile is triggered (either manually or automatically):<\/p>\n

      \n
    1. The VPN client calls into the Windows 10 Azure AD Token Broker on the local device and identifies itself as a VPN client.<\/li>\n
    2. The Azure AD Token Broker authenticates to Azure AD and provides it with information about the device trying to connect. A device check is performed by Azure AD to determine whether the device complies with our VPN policies.<\/li>\n
    3. If the device is compliant, Azure AD requests a short-lived certificate. If the device isn\u2019t compliant, we perform remediation steps.<\/li>\n
    4. Azure AD pushes down a short-lived certificate to the Certificate Store via the Token Broker. The Token Broker then returns control back over to the VPN client for further connection processing.<\/li>\n
    5. The VPN client uses the Azure AD\u2013issued certificate to authenticate with the VPN gateway.<\/li>\n<\/ol>\n

      Remote access infrastructure<\/h2>\n

      At Microsoft, we have designed and deployed a hybrid infrastructure to provide remote access for all the supported operating systems\u2014using Azure for load balancing and identity services and specialized VPN appliances. We had several considerations when designing the platform:<\/p>\n