Always On VPN Split vs. Force Tunneling

Always On VPN Split vs. Force TunnelingDuring the planning phase of a Windows 10 Always On VPN implementation the administrator must decide between two tunneling options for VPN client traffic – split tunneling or force tunneling. When split tunneling is configured, only traffic for the on-premises network is routed over the VPN tunnel. Everything else is sent directly to the Internet. With force tunneling, all client traffic, including Internet traffic, is routed over the VPN tunnel. There’s been much discussion recently on this topic, and this article serves to outline the advantages and disadvantages for both tunneling methods.

Force Tunneling

Force tunneling is typically enabled to meet the following requirements.

Visibility and Control

By routing all the client’s Internet traffic over the VPN tunnel, administrators can inspect, filter, and log Internet traffic using existing on-premises security solutions such as web proxies, content filters, or Next Generation Firewalls (NGFW).

Privacy

Enabling force tunneling ensures privacy and protection of all Internet communication. By routing all Internet traffic over the VPN, administrators can be certain that all communication from the Always On VPN client is encrypted, even when clients access unencrypted web sites or use untrusted or insecure wireless networks.

Force Tunneling Drawbacks

While configuring force tunneling for Always On VPN has some advantages, it comes with some serious limitations as well.

Poor User Experience

User experience is often degraded when all Internet traffic is routed over the VPN. These suboptimal network paths increase latency, and VPN encapsulation and encryption overhead increase fragmentation, leading to reduced throughput. Most Internet traffic is already encrypted in some form, and encrypting traffic that is already encrypted makes the problem even worse. In addition, force tunneling short-circuits geographic-based Content Delivery Networks (CDNs) further reducing Internet performance. Further, location-based services are often broken which can lead to improper default language selection or inaccurate web search results.

Increased Resource Consumption

Additional resources may need to be provisioned to support force tunneling. With corporate and Internet traffic coming over the VPN, more CPU, memory, and network resources may be required. Deploying additional VPN servers and higher throughput load balancers to support the increase in network traffic may also be necessary. Force tunneling also places higher demands on Internet Service Provider (ISP) links to the corporate datacenter.

Split Tunneling

The alternative to force tunneling is “split tunneling”. With split tunneling configured, only traffic destined for the internal corporate network is routed over the VPN. All other traffic is sent directly to the Internet. Administrators define IP networks that should be routed over the VPN, and those networks are added to the routing table on the VPN client.

Security Enforcement

The challenge of providing visibility and control of Internet traffic with split tunneling enabled can be met using a variety of third-party security solutions. Microsoft Defender ATP recently introduced support for web content filtering. Also, there are numerous cloud-based security offerings from many vendors that allow administrators to monitor and control client-based Internet traffic. Zscaler and Cisco Umbrella are two popular solutions, and no doubt there are many more to choose from.

Recommendations

The general guidance I provide customers is to use split tunneling whenever possible, as it provides the best user experience and reduces demands on existing on-premises infrastructure. Enabling split or force tunneling is ultimately a design decision that must be made during the planning phase of an Always On VPN implementation project. Both configurations are supported, and they each have their merits.

In today’s world, with many applications accessible via public interfaces, force tunneling is an antiquated method for providing visibility and control for managed devices in the field. If required, investigate the use of Microsoft or other third-party solutions that enforce security policy in place without the requirement to backhaul client Internet traffic to the datacenter over VPN for inspection, logging, and filtering.

Additional Information

Whitepaper: Enhancing VPN Performance at Microsoft

Whitepaper: How Microsoft Is Keeping Its Remote Workforce Connected

Microsoft Defender ATP Web Content Filtering

Always On VPN Force Tunneling with Office 365 Exclusions

Always On VPN Force Tunneling with Office 365 ExclusionsWith the COVID-19 global pandemic forcing nearly everyone to work from home these days, organizations that implemented force tunneling for their VPN clients are likely encountering unexpected problems. When force tunneling is enabled, all client traffic, including Internet traffic, is routed over the VPN tunnel. This often overloads the VPN infrastructure and causes serious slowdowns, which degrades the user experience and negatively impacts productivity. This is especially challenging because so many productivity applications like Microsoft Office 365 are optimized for Internet accessibility. It is one of the main reasons that force tunneling is not generally recommended.

Force Tunneling with Exceptions

When enabling split tunneling is not an option, administrators frequently ask about enabling force tunneling with some exceptions. The most common configuration is enabling force tunneling while still allowing Office 365 traffic to go outside of the tunnel. While this is something that third-party solutions do easily, it has been a challenge for Always On VPN. Specifically, Always On VPN has no way to route traffic by hostname or Fully-Qualified Domain Name (FQDN).

Exclusion Routes

To address this challenge, the administrator can configure Exclusion Routes. Exclusion Routes are supported in Windows 10 1803 with update KB4493437, Windows 10 1809 with update KB4490481, and Windows 10 1903/1909.

Exclusion routes are defined in the client routing table that are excluded from the VPN tunnel. The real challenge here is determining all the required IP addresses required for Office 365.

Microsoft Published Guidance

Given current events and the heavy demands placed on enterprises supporting exclusively remote workforces, Microsoft has recently published guidance for configuring Always On VPN force tunneling while excluding Office 365 traffic. Their documentation includes all the required IP addresses to configure exclusions for. This will make it much simpler for administrators to configure Always On VPN to support this unique scenario. The following links provide detailed configuration guidance for enabling force tunneling for Always On VPN with exceptions.

Additional Information

Windows 10 Always On VPN Split vs. Force Tunneling

Windows 10 Always On VPN Routing Configuration

Windows 10 Always On VPN Lockdown Mode

Always On VPN Device Tunnel with Azure VPN Gateway

Always On VPN Device Tunnel with Azure VPN GatewayAlways On VPN is infrastructure independent, which allows for many different deployment scenarios including on-premises and cloud-based. In Microsoft Azure, the Azure VPN gateway can be configured to support Windows 10 Always On VPN client connections in some scenarios. Recently I wrote about using the Azure VPN gateway for Always On VPN user tunnels. In this post I’ll describe how to configure the Azure VPN gateway to support an Always On VPN device tunnel.

Limitations

There are a few crucial limitations that come with using the Azure VPN gateway for Always On VPN. Importantly, the Azure VPN gateway can support either user tunnels or device tunnels, not both at the same time. In addition, Azure supports only a single VPN gateway per VNet, so deploying an additional VPN gateway in the same VNet to support Always On VPN user tunnels is not an option.

Root CA Certificate

The Always On VPN device tunnel is authenticated using a machine certificate issued to domain-joined Windows 10 Enterprise edition clients by the organization’s internal Certification Authority (CA). The CA’s root certificate must be uploaded to Azure for the VPN gateway to authorize device tunnel connections. The root CA certificate can be exported using the Certification Authority management console (certsrv.msc) or via the command line.

Export Certificate – GUI

Follow the steps below to export a root CA certificate using the Certification Authority management console.

1. On the root CA server, open the Certification Authority management console.
2. Right-click the CA and choose Properties.
3. Select the CA server’s certificate and choose View Certificate.
4. Select the Details tab and click Copy to File.
5. Click Next.
6. Choose Base-64 encoded X.509 (.CER).

Always On VPN Device Tunnel with Azure VPN Gateway

7. Click Next.
8. Enter a location to save the file to.
9. Click Next, Finish, and Ok.

Export Certificate – Command Line

Follow the steps below to export a root CA certificate using the command line.

1. On the root CA server, open an elevated command window (not a PowerShell window).
2. Enter certutil.exe -ca.cert root_certificate.cer.
3. Enter certutil.exe -encode root.cer root_certificate_base64.cer.

Copy Public Key

1. Open the saved root certificate file using Notepad.
2. Copy the file contents between the BEGIN CERTIFICATE and END CERTIFICATE tags, as shown here. Use caution and don’t copy the carriage return at the end of the string.

Always On VPN Device Tunnel with Azure VPN Gateway

Point-to-Site Configuration

The Azure VPN gateway must be deployed as a Route-Based gateway to support point-to-site VPN connections. Detailed requirements for the gateway can be found here. Once the VPN gateway has been provisioned, follow the steps below to enable point-to-site configuration for Always On VPN device tunnels.

1. In the navigation pane of the Azure VPN gateway settings click Point-to-site configuration.
2. Click the Configure now link and specify an IPv4 address pool to be assigned to VPN clients. This IP address pool must be unique in the organization and must not overlap with an IP address ranges defined in the Azure virtual network.
3. From the Tunnel type drop-down list select IKEv2.
4. In the Root certificates section enter a descriptive name for the certificate in the Name field.
5. Copy and paste the Base64 encoded public key copied previously into the Public certificate data field.
6. Click Save to save the configuration.

Always On VPN Device Tunnel with Azure VPN Gateway

VPN Client Configuration

To support the Always On VPN device tunnel, the client must have a certificate issued by the internal CA with the Client Authentication Enhanced Key Usage (EKU). Detailed guidance for deploying a Windows 10 Always On VPN device tunnel can be found here.

Download VPN Configuration

1. Click Point-to-site configuration.
2. Click Download VPN client.
3. Click Save.
4. Open the downloaded zip file and extract the VpnSettings.xml file from the Generic folder.
5. Copy the FQDN in the VpnServer element in VpnSettings.xml. This is the FQDN that will be used in the template VPN connection and later in ProfileXML.

Create a Test VPN Connection

It is recommended to create a test VPN connection to perform validation testing of the Azure VPN gateway before provisioning an Always On VPN device tunnel broadly. On a domain-joined Windows 10 enterprise client, create a new VPN connection using IKEv2 with machine certificate authentication. Use the VPN server FQDN copied from the VpnSettings.xml file previously.

Always On VPN Device Tunnel with Azure VPN Gateway

Create an Always On VPN Connection

Once the VPN has been validated using the test profile created previously, an Always On VPN profile can be created and deployed using Intune, SCCM, or PowerShell. The following articles can be used for reference.

Deploy Always On VPN device tunnel using PowerShell

Deploy Always On VPN device tunnel using Intune

IKEv2 Security Configuration

The default IKEv2 security parameters used by the Azure VPN gateway are better than Windows Server, but the administrator will notice that a weak Diffie-Hellman (DH) key (Group 2 – 1024 bit) is used during IPsec phase 1 negotiation.

Always On VPN Device Tunnel with Azure VPN Gateway

Use the following PowerShell commands to update the default IKEv2 security parameters to recommended baseline defaults, including 2048-bit keys (DH group 14) and AES-128 for improved performance.

Connect-AzAccount
Select-AzSubscription -SubscriptionName [Azure Subscription Name]

$Gateway = [Gateway Name]
$ResourceGroup = [Resource Group Name]

$IPsecPolicy = New-AzVpnClientIpsecParameter -IpsecEncryption AES128 -IpsecIntegrity SHA256 -SALifeTime 28800 -SADataSize 102400000 -IkeEncryption AES128 -IkeIntegrity SHA256 -DhGroup DHGroup14 -PfsGroup PFS14

Set-AzVpnClientIpsecParameter -VirtualNetworkGatewayName $Gateway -ResourceGroupName $ResourceGroup -VpnClientIPsecParameter $IPsecPolicy

Note: Be sure to update the cryptography settings on the test VPN connection and in ProfileXML for Always On VPN connections to match the new VPN gateway settings. Failing to do so will result in an IPsec policy mismatch error.

Additional Information

Windows 10 Always On VPN User Tunnel with Azure VPN Gateway

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN Device Tunnel Configuration using Microsoft Intune

Windows 10 Always On VPN Device Tunnel Configuration using PowerShell

Windows 10 Always On VPN Options for Azure Deployments

Windows 10 Always On VPN IKEv2 Features and Limitations

Microsoft Intune NDES Connector Setup Wizard Ended Prematurely

Microsoft Intune NDES Connector Setup Wizard Ended PrematurelyA Windows Server with the Network Device Enrollment Service (NDES) role can be provisioned on-premises to support certificate deployment for non-domain Windows 10 Always On VPN clients. In addition, the Microsoft Intune Connector must be installed and configured on the NDES server to allow Intune-managed clients to request and receive certificates from the on-premises Certification Authority (CA) server.

Setup Wizard Ended Prematurely

When installing the Microsoft Intune Connector, the administrator may encounter a scenario where the setup wizard fails with the following error message.

“Microsoft Intune Connector Setup Wizard ended prematurely because of an error. Your system has not been modified. To install this program at a later time, run Setup Wizard again. Click the Finish button to exit the Setup Wizard.”

Microsoft Intune NDES Connector Setup Wizard Ended Prematurely

Cryptographic Service Provider

This error can occur if the NDES server certificate template is configured to use the Key Storage Provider cryptography service provider (CSP). When configuring the certificate template for the NDES server, the Legacy Cryptography Service Provider must be used, as shown here.

Microsoft Intune NDES Connector Setup Wizard Ended Prematurely

Additional Information

Deploying Windows 10 Always On VPN with Intune using Custom ProfileXML

Windows 10 Always On VPN Device Tunnel Configuration using Microsoft Intune

Deploying Windows 10 Always On VPN with Microsoft Intune

 

Always On VPN Load Balancing with Kemp in Azure

Always On VPN Load Balancing with Kemp in AzureIn a recent post I discussed options for load balancing Windows Server Routing and Remote Access Service (RRAS) in Microsoft Azure for Always On VPN. There are many choices available to the administrator, however the best alternative is to use a dedicated Application Delivery Controller (ADC), or load balancer. The Kemp LoadMaster load balancer is an excellent choice here, as it is easy to configure and deploy. It is also very cost effective and offers flexible licensing plans, including a metered licensing option.

Deploy LoadMaster in Azure

To provision a Kemp LoadMaster load balancer in Microsoft Azure, open the Azure management console and perform the following steps.

1. Click Create Resource.
2. Enter LoadMaster in the search field.
3. Click on LoadMaster Load Balancer ADC Content Switch.

Always On VPN Load Balancing with Kemp in Azure

4. Choose an appropriate license model from the Select a software plan drop-down list.
5. Click Create.

Prepare Azure Instance

Follow the steps below to provision the Azure VM hosting the Kemp LoadMaster load balancer.

1. Choose an Azure subscription to and resource group to deploy the resources to.
2. Provide instance details such as virtual machine name, region, availability options, and image size.
3. Select an authentication type and upload the SSH private key or provide a username and password.
4. Click Next:Disks >.

Always On VPN Load Balancing with Kemp in Azure

5. Select an OS disk type.
6. Click Next: Networking >.

Always On VPN Load Balancing with Kemp in Azure

7. Select a virtual network and subnet for the load balancer.
8. Create or assign a public IP address.
9. Click Review + create.

Always On VPN Load Balancing with Kemp in Azure

LoadMaster Configuration

Once the virtual machine has been provisioned, open a web browser and navigate to the VM’s internal IP address on port 8443 to accept the licensing terms.

Always On VPN Load Balancing with Kemp in Azure

Next, log in with your Kemp ID and password to finish licensing the appliance.

Always On VPN Load Balancing with Kemp in Azure

Finally, log in to the appliance using the username ‘bal’ and the password provided when the virtual machine was configured.

Always On VPN Load Balancing with Kemp in Azure

Azure Network Security Group

A Network Security Group (NSG) is automatically configured and associated with the LoadMaster’s network interface when the appliance is created. Additional inbound security rules must be added to allow VPN client connectivity.

In the Azure management console open the properties for the LoadMaster NSG and follow the steps below to configure security rules to allow inbound VPN protocols.

SSTP

1. Click Inbound security rules.
2. Click Add.
3. Choose Any from the Source drop-down list.
4. Enter * in the Source port ranges field.
5. Select Any from the Destination drop-down list.
6. Enter 443 in the Destination port ranges field.
7. Select the TCP protocol.
8. Select the Allow action.
9. Enter a value in the Priority field.
10. Enter a name for the service in the Name field.
11. Click Add.

Always On VPN Load Balancing with Kemp in Azure

IKEv2

1. Click Inbound security rules.
2. Click Add.
3. Choose Any from the Source drop-down list.
4. Enter * in the Source port ranges field.
5. Select Any from the Destination drop-down list.
6. Enter 500 in the Destination port ranges field.
7. Select the UDP protocol.
8. Select the Allow action.
9. Enter a value in the Priority field.
10. Enter a name for the service in the Name field.
11. Click Add.
12. Repeat the steps below for UDP port 4500.

Always On VPN Load Balancing with Kemp in Azure

Load Balancing SSTP and IKEv2

Refer to the following posts for detailed, prescriptive guidance for configuring the Kemp LoadMaster load balancer for Always On VPN load balancing.

Always On VPN SSTP Load Balancing with Kemp LoadMaster

Always On VPN IKEv2 Load Balancing with the Kemp LoadMaster

Always On VPN Load Balancing Deployment Guide for the Kemp LoadMaster

Summary

Although Windows Server RRAS is not a formally supported workload in Azure, it is still a popular and effective solution for Always On VPN deployments. The Kemp LoadMaster load balancer can be deployed quickly and easily to provide redundancy and increase scalability for larger deployments.

Additional Information

Windows 10 Always On VPN SSTP Load Balancing with Kemp LoadMaster Load Balancers

Windows 10 Always On VPN IKEv2 Load Balancing with Kemp LoadMaster Load Balancers

Windows 10 Always On VPN Load Balancing Deployment Guide for Kemp LoadMaster Load Balancers

Deploying the Kemp LoadMaster Load Balancer in Microsoft Azure

Always On VPN Load Balancing for RRAS in Azure

Always On VPN Load Balancing for RRAS in AzurePreviously I wrote about Always On VPN options for Microsoft Azure deployments. In that post I indicated that running Windows Server with the Routing and Remote Access Service (RRAS) role for VPN was an option to be considered, even though it is not a formally supported workload. Despite the lack of support by Microsoft, deploying RRAS in Azure works well and is quite popular. In fact, I recently published some configuration guidance for RRAS in Azure.

Load Balancing Options for RRAS

Multiple RRAS servers can be deployed in Azure to provide failover/redundancy or to increase capacity. While Windows Network Load Balancing (NLB) can be used on-premises for RRAS load balancing, NLB is not supported and doesn’t work in Azure. With that, there are several options for load balancing RRAS in Azure. They include DNS round robin, Azure Traffic Manager, the native Azure load balancer, Azure Application Gateway, or a dedicated load balancing virtual appliance.

DNS Round Robin

The easiest way to provide load balancing for RRAS in Azure is to use round robin DNS. However, using this method has some serious limitations. Simple DNS round robin can lead to connection attempts to a server that is offline. In addition, this method doesn’t accurately balance the load and often results in uneven distribution of client connections.

Azure Traffic Manager

Using Azure Traffic Manager is another alternative for load balancing RRAS in Azure. In this scenario each VPN server will have its own public IP address and FQDN for which Azure Traffic Manager will intelligently distribute traffic. Details on configuring Azure Traffic Manager for Always On VPN can be found here.

Azure Load Balancer

The native Azure load balancer can be configured to provide load balancing for RRAS in Azure. However, it has some serious limitations. Consider the following.

  • Supports Secure Socket Tunneling Protocol (SSTP) only.
  • Basic health check functionality (port probe only).
  • Limited visibility.
  • Does not work with IKEv2.
  • Does not support TLS offload for SSTP.

More information about the Azure Load Balancer can be found here.

Azure Application Gateway

The Azure Application Gateway can be used for load balancing RRAS SSTP VPN connections where advanced capabilities such as enhanced health checks and TLS offload are required. More information about the Azure Application Gateway can be found here.

Load Balancing Appliance

Using a dedicated Application Delivery Controller (ADC), or load balancer is a very effective way to eliminate single points of failure for Always On VPN deployments hosted in Azure. ADCs provide many advanced features and capabilities to ensure full support for all RRAS VPN protocols. In addition, ADCs offer much better visibility and granular control over VPN connections. There are many solutions available as virtual appliances in the Azure marketplace that can be deployed to provide RRAS load balancing in Azure.

Summary

Deploying Windows Server RRAS in Azure for Always On VPN can be a cost-effective solution for many organizations. Although not a formally supported workload, I’ve deployed it numerous times and it works quite well. Consider using a dedicated ADC to increase scalability or provide failover and redundancy for RRAS in Azure whenever possible.

Additional Information

Windows 10 Always On VPN Options for Azure Deployments

Windows 10 Always On VPN and RRAS in Microsoft Azure

Windows 10 Always On VPN with Microsoft Azure Gateway

Always On VPN and RRAS in Azure

Always On VPN and RRAS in AzureWhen deploying Windows 10 Always On VPN, it may be desirable to host the VPN server in Microsoft’s Azure public cloud. Recently I wrote about Always On VPN deployment options in Azure, and in that post I indicated that deploying Windows Server and the Routing and Remote Access Service (RRAS) was one of those options. Although not formally supported by Microsoft, RRAS is often deployed in Azure because it is cost-effective, easy to manage, and provides flexible scalability.

Supportability

It’s important to state once again that although it is possible to successfully deploy Windows Server with RRAS in Azure to support Always On VPN, as of this writing it is not a formally supported workload. If the administrator makes the decision to deploy RRAS in Azure, they must also accept that Microsoft may refuse to assist with troubleshooting in this specific deployment scenario.

Always On VPN and RRAS in Azure

Reference: https://support.microsoft.com/en-us/help/2721672/microsoft-server-software-support-for-microsoft-azure-virtual-machines

Azure Prerequisites

The configuration of RRAS is identical to on-premises, with a few additional steps required by Azure infrastructure.

Windows Server

RRAS can be configured on any Windows Server virtual machine supported in Microsoft Azure. As with on-premises deployments, Server GUI and Core are supported. Domain-join is optional. The server can be deployed with one network interface or two.

Public IP

A public IP address must be assigned to the VPN server’s external network interface, or the internal interface if the VPN server is configured with a single network adapter. The IP address can be static or dynamic. When using a dynamic IP address, configure a CNAME record in DNS that points to the name configured for the IP address in Azure. If using a static IP address, an A host record can be configured pointing directly to the IP address.

Network Security Group

A Network Security Group (NSG) must be configured and assigned to the VPN server’s external or public-facing network interface that allows the following protocols and ports inbound.

  • TCP port 443 (SSTP)
  • UDP port 500 (IKEv2)
  • UDP port 4500 (IKEv2 NAT traversal)

RRAS in Azure

Below are the infrastructure requirements for supporting Windows Server RRAS VPN in Azure.

Client IP Subnet

Static IP address pool assignment must be used with RRAS. Using DHCP for VPN client IP address assignment in Azure is not supported and will not work. The IP subnet assigned to VPN clients by RRAS must be unique and not overlap with any existing Azure VNet subnets. If more than one VPN server is deployed, each server should be configured to assign a unique subnet for its clients.

IP Forwarding

IP forwarding must be enabled on the VPN server’s internal network interface. Follow the steps below to enable IP forwarding.

1. In the Azure portal, open the properties page for the internal network interface for the VPN server.
2. Click IP configurations in the navigation pane.
3. Click Enabled next to IP forwarding.
4. Click Save.

Always On VPN and RRAS in Azure

Routing

Azure must be configured to route IP traffic from VPN clients back to the VPN server. Follow the steps below to create and assign a routing table in Azure.

1. Click Create Resource.
2. Enter “Route Table” in the search field and press Enter.
3. Click Route Table.
4. Click Create.
5. Enter a descriptive name for the route table in the Name field.
6. Choose an appropriate subscription from the Subscription drop-down list.
7. Select the resource group where the VPN server(s) reside.
8. Select the best location to deploy the route table resource from the Location drop-down list.
9. If the administrator wants to have the VPN client IP subnet route information published automatically, select Enabled for Virtual network gateway route propagation.
10. Click Create.

Always On VPN and RRAS in Azure

Once complete, follow the steps below to define the route for VPN clients.

1. Open the properties page for the route table.
2. Click Routes in the navigation pane.
3. Click Add.
4. Enter a descriptive name in the Route name filed.
5. Enter the IP subnet assigned to VPN clients in the Address prefix field.
6. Select Virtual appliance from the Next hop type drop-down list.
7. Enter the IPv4 address assigned to the VPN server’s internal network interface in the Next hop address field.
8. Click Ok.
9. Repeat the steps above for each VPN server configured in Azure.

Always On VPN and RRAS in Azure

Finally, follow the steps below to assign the route table to an Azure VNet subnet.

1. Open the properties page for the route table.
2. Click Subnets in the navigation pane.
3. Click Associate.
4. Click Virtual network.
5. Choose the appropriate Azure VNet.
6. Click Subnet.
7. Choose an Azure VNet subnet to assign the route table to.
8. Click Ok.
9. Repeat the steps above to assign the route table to any Azure VNet subnet that must be accessible by VPN clients. If VPN clients need access to on-premises resources via Azure site-to-site gateway, assign the route table to the Azure VPN gateway subnet.

Always On VPN and RRAS in Azure

Note: Azure only supports the assignment of one route table per subnet. If a route table is currently assigned, the VPN client subnet route can be added to an existing route table, if necessary.

Summary

Administrators have many choices when it comes to support Always On VPN connections hosted in Azure. RRAS on Windows Server can be an effective solution, assuming you can live without formal support. If having a formally supported solution is a hard requirement, consider deploying Always On VPN using the native Azure VPN gateway or another third-part Network Virtual Appliance (NVA).

Additional Information

Windows 10 Always On VPN with Azure Gateway

Windows 10 Always On VPN Options for Azure Deployments

Windows 10 Always On VPN Multisite with Azure Traffic Manager

Always On VPN with Azure Gateway

Always On VPN with Azure GatewayRecently I wrote about VPN server deployment options for Windows 10 Always On VPN in Azure. In that post I indicated the native Azure VPN gateway could be used to support Always On VPN connections using Internet Key Exchange version 2 (IKEv2) and Secure Socket Tunneling Protocol (SSTP). In this post I’ll outline the requirements and configuration steps for implementing this solution.

Requirements

To support Always On VPN, point-to-site VPN connections must be enabled on the Azure VPN gateway. Not all Azure VPN gateways are alike, and point-to-site connections are not supported in all scenarios. For Always On VPN, the Azure VPN gateway must meet the following requirements.

VPN SKU

The Azure VPN gateway SKU must be VpnGw1, VpnGw2, VpnGw3, VpnGw1AZ, VpnGw2AZ, or VpnGw3AZ. The Basic SKU is not supported.

VPN Type

The VPN type must be route-based. Policy-based VPN gateways are not supported for point-to-site VPN connections.

Limitations

Using the Azure VPN gateway for Always On VPN may not be ideal in all scenarios. The following limitations should be considered thoroughly before choosing the Azure VPN gateway for Always On VPN.

Device Tunnel

RADIUS/EAP authentication for user tunnel connections is not supported if the Azure VPN gateway is configured to support device tunnel with machine certificate authentication.

Maximum Connections

A maximum of 250, 500, and 1000 concurrent IKEv2 connections are supported when using the VpnGw1/AZ, VpnGw2/AZ, and VpnGw3/AZ SKUs, respectively (x2 for active/active gateway deployments). In addition, a maximum of 128 concurrent SSTP connections are supported for all VPN gateway SKUs (x2 for active/active gateway deployments).

Always On VPN with Azure Gateway

Reference: https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpngateways#gwsku

RADIUS Requirements

To support Always On VPN connections, the Azure VPN gateway must be configured to authenticate to a RADIUS server. The RADIUS server must be reachable from the VPN gateway subnet. The RADIUS server can be hosted in Azure or on-premises. Before proceeding, ensure that any network routes, firewall rules, and site-to-site VPN tunnel configuration is in place to allow this communication.

RADIUS Configuration

Guidance for configuring Windows Server NPS for Always On VPN can be found here. The only difference when configuring NPS for use with Azure VPN gateway is the RADIUS client configuration.

Open the NPS management console (nps.msc) and follow the steps below to configure Windows Server NPS to support Always On VPN client connections from the Azure VPN gateway.

1. Expand RADIUS Clients and Servers.
2. Right-click RADIUS Clients and choose New.
3. Enter a descriptive name in the Friendly name field.
4. Enter the Azure VPN gateway subnet using CIDR notation in the Address (IP or DNS) field. The gateway subnet can be found by viewing the properties of the Azure VPN gateway in the Azure portal.
5. Enter the shared secret to be used for RADIUS communication in the Shared secret field.

Always On VPN with Azure Gateway

Azure VPN Gateway Configuration

To begin, provision a Virtual Network Gateway in Azure that meets the requirements outlined above. Guidance for implementing an Azure VPN gateway can be found here. Once complete, follow the steps below to enable support for Always On VPN client connections.

Enable Point-to-Site

Perform the following steps to enable point-to-site VPN connectivity.

1. In the navigation pane of the Azure VPN gateway settings click Point-to-site configuration.
2. Click Configure Now and specify an IPv4 address pool to be assigned to VPN clients. This IP address pool must be unique in the organization and must not overlap with any IP address ranges defined in the Azure virtual network.
3. From the Tunnel type drop-down list select IKEv2 and SSTP (SSL).
4. In the RADIUS authentication field enter the IPv4 address of the RADIUS server. At the time of this writing only a single IPv4 address is supported. If RADIUS redundancy is required, consider creating a load balanced NPS cluster.
5. In the Server secret field enter the RADIUS shared secret.
6. Click Save to save the configuration.

Always On VPN with Azure Gateway

VPN Client Configuration

Perform the following steps to configure a Windows 10 VPN client to connect to the Azure VPN gateway.

Download VPN Configuration

1. Click Point-to-site configuration.
2. Click Download VPN client.
3. Select EAPMSCHAv2 (yes, that’s correct even if EAP-TLS will be used!)
4. Click Download.
5. Open the downloaded zip file and extract the VpnSettings.XML file from the Generic folder.
6. Copy the FQDN in the VpnServer element in VpnSettings.XML. This is the FQDN that will be used in the template VPN connection and later in ProfileXML.

Always On VPN with Azure Gateway

Create a Test VPN Connection

On a Windows 10 device create a test VPN profile using the VPN server address copied previously. Configure EAP settings to match those configured on the NPS server and test connectivity.

Create an Always On VPN Connection

Once the VPN has been validated using the test profile created previously, the VPN server and EAP configuration from the test profile can be used to create the Always On VPN profile for publishing using Intune, SCCM, or PowerShell.

IKEv2 Security Configuration

The default IKEv2 security parameters used by the Azure VPN gateway are better than Windows Server, but the administrator will notice that a weak DH key (1024 bit) is used in phase 1 negotiation.

Always On VPN with Azure Gateway

Use the following PowerShell commands to update the default IKEv2 security parameters to recommended baseline defaults, including 2048-bit keys (DH group 14) and AES-128 for improved performance.

Connect-AzAccount
Select-AzSubscription -SubscriptionName [Azure Subscription Name]

$Gateway = [Gateway Name]
$ResourceGroup = [Resource Group Name]

$IPsecPolicy = New-AzVpnClientIpsecParameter -IpsecEncryption AES128 -IpsecIntegrity SHA256 -SALifeTime 28800 -SADataSize 102400000 -IkeEncryption AES128 -IkeIntegrity SHA256 -DhGroup DHGroup14 -PfsGroup PFS14

Set-AzVpnClientIpsecParameter -VirtualNetworkGatewayName $Gateway -ResourceGroupName $ResourceGroup -VpnClientIPsecParameter $IPsecPolicy

Note: Be sure to update the cryptography settings on the test VPN connection and in ProfileXML for Always On VPN connections to match the new VPN gateway settings. Failing to do so will result in an IPsec policy mismatch error.

Additional Information

Microsoft Azure VPN Gateway Overview

About Microsoft Azure Point-to-Site VPN

Windows 10 Always On VPN IKEv2 Security Configuration

 

 

 

Always On VPN Options for Azure Deployments

Always On VPN Options for Azure DeploymentsOrganizations everywhere are rapidly adopting Microsoft Azure public cloud infrastructure to extend or replace their existing datacenter. As traditional on-premises workloads are migrated to the cloud, customers are looking for options to host VPN services there as well.

Windows Server

Windows Server with the Routing and Remote Access Service (RRAS) installed is a popular choice for on-premises Always On VPN deployments. Intuitively it would make sense to deploy Windows Server and RRAS in Azure as well. However, at the time of this writing, RRAS is not a supported workload on Windows Server in Azure.

Always On VPN Options for Azure Deployments

Reference: https://support.microsoft.com/en-us/help/2721672/microsoft-server-software-support-for-microsoft-azure-virtual-machines/

Although explicitly unsupported, it is possible to deploy Windows Server and RRAS in Azure for Always On VPN. In my experience it works well and can be an option for organizations willing to forgo formal support by Microsoft.

Azure Gateway

Options for supporting Always On VPN connections using native Azure VPN infrastructure depend on the type of VPN gateway chosen.

VPN Gateway

The Azure VPN Gateway can be configured to support client-based (point-to-site) VPN. With some additional configuration it can be used to support Windows 10 Always On VPN deployments. Azure VPN gateway supports both IKEv2 and SSTP VPN protocols for client connections. The Azure VPN gateway has some limitations though. Consider the following:

  • A route-based VPN gateway is required
  • A maximum of 1000 concurrent IKEv2 connections are supported when using the VpnGw3 or VpnGw3AZ SKUs (2000 supported in active/active mode)
  • A maximum of 128 concurrent SSTP connections are supported on all gateway SKUs (256 supported in active/active mode)

Virtual WAN

Azure Virtual WAN is the future of remote connectivity for Azure. It includes support for client-based VPN (currently in public preview at the time of this writing), but only supports IKEv2 and OpenVPN VPN protocols for client connections. SSTP is not supported at all. Further, OpenVPN is not supported for Windows 10 Always On VPN, leaving IKEv2 as the only option, which poses some potential operational challenges. Virtual WAN offer much better scalability though, supporting up to 10,000 concurrent client-based VPN connections.

Virtual Appliance

The most supportable option for hosting VPN services in Azure for Windows 10 Always On VPN is to deploy a third-party Network Virtual Appliance (NVA). They are available from a variety of vendors including Cisco, Check Point, Palo Alto Networks, Fortinet, and many others. To support Windows 10 Always On VPN, the NVA vendor must either support IKEv2 for client-based VPN connections or have a Universal Windows Platform (UWP) VPN plug-in client available from the Microsoft store. Click here to learn more about Always On VPN and third-party VPN devices.

Note: Be careful when choosing an NVA as some vendors support IKEv2 only for site-to-site VPN, but not client-based VPN!

Hybrid Deployments

For organizations with hybrid cloud deployments (infrastructure hosted on-premises and in Azure), there are several options for choosing the best location to deploy VPN services. In general, it is recommended that client VPN connections be established nearest the resources accessed by remote clients. However, having VPN servers hosted both on-premises and in Azure is fully supported. In this scenario Azure Traffic Manager can be configured to intelligently route VPN connections for remote clients.

NetMotion Mobility

The NetMotion Mobility purpose-built enterprise VPN is a popular replacement for Microsoft DirectAccess. It is also an excellent alternative for enterprise organizations considering a migration to Always On VPN. It is a software-based solution that can be deployed on Windows Server and is fully supported running in Microsoft Azure. It offers many advanced features and capabilities not included in other remote access solutions.

Summary

Administrators have many options for deploying VPN servers in Azure to support Windows 10 Always On VPN. Windows Server and RRAS is the simplest and most cost-effective option, but it is not formally supported by Microsoft. Azure VPN gateway is an interesting alternative but lacks enough capacity for larger deployments. Azure Virtual WAN is another option but has limited protocol support. Deploying an NVA is a good choice, and NetMotion Mobility is an excellent alternative to both DirectAccess and Always On VPN that is software-based and fully supported in Azure.

Additional Information

Windows 10 Always On VPN with Azure Gateway

Windows 10 Always On VPN and Third-Party VPN Devices

Windows 10 Always On VPN and Windows Server Routing and Remote Access Service (RRAS)

Windows 10 Always On VPN IKEv2 Features and Limitations

Windows 10 Always On VPN Multisite with Azure Traffic Manager

Comparing DirectAccess and NetMotion Mobility

Deploying NetMotion Mobility in Microsoft Azure

 

 

Always On VPN and Azure MFA ESTS Token Error

Always On VPN and Azure MFA ESTS Token ErrorConfiguring Multifactor Authentication (MFA) is an excellent way to ensure the highest level of assurance for Always On VPN users. Azure MFA is widely deployed and commonly integrated with Windows Server Network Policy Server (NPS) using the NPS Extension for Azure MFA. Azure MFA has a unique advantage over many other MFA providers in that it supports MFA when using Protected Extensible Authentication Protocol (PEAP). This makes Azure MFA the solution of choice for integrating with Windows 10 Always On VPN deployments using client certificate authentication, a recommended security configuration best practice.

NPS Configuration

Installing and configuring the NPS extension for Azure MFA is straightforward. Configuration guidance from Microsoft can be found here.

Connection Issues

After installing the NPS extension for Azure MFA, administrators may find that Always On VPN connections fail and the user is never challenged for authentication. The connection eventually times out and returns the following error message.

“A connection to the remote computer could not be established, so the port used for this connection was closed.”

Always On VPN and Azure MFA ESTS Token Error

In addition, the Application event log on the Windows 10 client contains an Event ID 20221 from the RasClient source that includes the following error message.

“The user [username] dialed a connection named [connection] which has failed. The error code returned on failure is 0.”

Always On VPN and Azure MFA ESTS Token Error

NPS Event Log

Reviewing the event logs on the NPS server reveals more information. The Security event log contains an Event ID 6274 from the Microsoft Windows security auditing source that includes the following error message.

“Network Policy Server discarded the request for a user. Contact the Network Policy Administrator for more information.”

Always On VPN and Azure MFA ESTS Token Error

ESTS Token Error

Digging deeper in the operational event log on the NPS server, the AuthZAdminCh log (Applications and Services Logs > Microsoft > AzureMfa > AuthZ) contains an Event ID 3 from the AuthZ source indicating an ESTS_TOKEN_ERROR message.

Always On VPN and Azure MFA ESTS Token Error

Troubleshooting ESTS Token Error

Follow the steps below to troubleshoot the ESTS_TOKEN_ERROR.

Prerequisites

Ensure that all prerequisites are met. Validate the user is being synced to Azure Active Directory and that it is properly licensed for Azure MFA.

Certificates

As part of the NPS extension configuration, a certificate is created on the NPS server that is uploaded to Azure Active Directory. To validate the certificate was created and uploaded correctly, follow the troubleshooting guidance found here.

Enterprise Applications

The Azure Multi-Factor Auth Client and the Azure Multi-Factor Auth Connector enterprise applications must be enabled to support the NPS extension for Azure MFA. To confirm they are enabled, open an elevated PowerShell command window on the server where the Azure AD Connector is installed and run the following PowerShell commands.

Import-Module MSOnline
Connect-MsolService

Get-MsolServicePrincipal -AppPrincipalId “981f26a1-7f43-403b-a875-f8b09b8cd720” | Select-Object DisplayName, AccountEnabled

Get-MsolServicePrincipal -AppPrincipalId “1f5530b3-261a-47a9-b357-ded261e17918” | Select-Object DisplayName, AccountEnabled

Always On VPN and Azure MFA ESTS Token Error

If either or both enterprise applications are not enabled, enable them using the following PowerShell commands.

Set-MsolServicePrincipal -AppPrincipalId “981f26a1-7f43-403b-a875-f8b09b8cd720” -AccountEnabled $True

Set-MsolServicePrincipal -AppPrincipalId “1f5530b3-261a-47a9-b357-ded261e17918” -AccountEnabled $True

Once complete, restart the IAS service on the NPS server using the following PowerShell command.

Restart-Service IAS -PassThru

Additional Information

Windows 10 Always On VPN Network Policy Server (NPS) Load Balancing Strategies

Deploy Windows 10 Always On VPN with Microsoft Intune

Windows 10 Always On VPN Hands-On Training Classes Now Available

%d bloggers like this: