Remote Access Questions and Answers Webinar Hosted by Kemp

Join me this Thursday, April 9 at 10:00AM EDT for a Remote Access Q&A session hosted by Kemp Technologies. During this free live webinar, I’ll be answering all your questions as they relate to enterprise mobility, remote access, scalability and performance, security, and much more. Topics are not limited to Kemp products at all, so feel free to join and ask me anything you like! Register now and submit your questions!

Remote Access Q&A Webinar Hosted by Kemp

Always On VPN Device Tunnel Only Deployment Considerations

Always On VPN Device Tunnel Only Deployment ConsiderationsRecently I wrote about Windows Always On VPN device tunnel operation and best practices, explaining its common uses cases and requirements, as well as sharing some detailed information about authentication, deployment recommendations, and best practices. I’m commonly asked if deploying Always On VPN using the device tunnel exclusively, as opposed to using it to supplement the user tunnel, is supported or recommended. I’ll address those topics in detail here.

Device Tunnel Only?

To start, yes, it is possible to deploy Windows Always On VPN using only the device tunnel. In this scenario the administrator will configure full access to the network instead of limited access to domain infrastructure services and management servers.

Is It Recommended?

Generally, no. Remember, the device tunnel was designed with a specific purpose in mind, that being to provide pre-logon network connectivity to support scenarios such as logging on without cached credentials. Typically, the device tunnel is best used for its intended purpose, which is providing supplemental functionality to the user tunnel.

Deployment Considerations

The choice to implement Always On VPN using only the device tunnel is an interesting one. There are some potential advantages to this deployment model, but it is not without some serious limitations. Below I’ve listed some of the advantages and disadvantages to deploying the device tunnel alone for Windows 10 Always On VPN.

Advantages

Using the device tunnel alone does have some compelling advantages over the standard two tunnel (device tunnel/user tunnel) deployment model. Consider the following.

  • Single VPN Connection – Deploying the device tunnel alone means a single VPN connection to configure, deploy, and manage on the client. This also results in less concurrent connections and, importantly, less IP addresses to allocate and provision.
  • Reduced Infrastructure – The device tunnel is authenticated using only the device certificate. This certificate check is performed directly on the Windows Server Routing and Remote Access Service (RRAS) VPN server, eliminating the requirement to deploy Network Policy Server (NPS) servers for authentication.
  • User Transparency – The device tunnel does not appear in the modern Windows UI. The user will not see this connection if they click on the network icon in the notification area. In addition, they will not see the device tunnel connection in the settings app under Network & Internet > VPN. This prevents casual users from playing with the connection settings, and potentially deleting the connection entirely. It’s not that they can’t delete the device tunnel however, it’s just not as obvious.
  • Simplified Deployment – Deploying the device tunnel is less complicated than deploying the user tunnel. The device tunnel is provisioned once to the device and available to all users. This eliminates the complexity of having to deploy the user tunnel in each individual user’s profile.

Disadvantages

While there are some advantages to using the device tunnel by itself, this configuration is not without some serious limitations. Consider the following.

  • IKEv2 Only – The device tunnel uses the IKEv2 VPN protocol exclusively. It does not support SSTP. While IKEv2 is an excellent protocol in terms of security, it is commonly blocked by firewalls. This will prevent some users from accessing the network remotely depending on their location.
  • Limited OS Support – The device tunnel is only supported on Windows Enterprise edition clients, and those clients must be joined to a domain. Arguably the device tunnel wouldn’t be necessary if the client isn’t domain joined, but some organizations have widely deployed Windows Professional, which would preclude them from being able to use the device tunnel.
  • Machine Certificate Authentication Only – The device tunnel is authenticated using only the certificate issued to the device. This means anyone who logs on to the device will have full access to the internal network. This may or may not be desirable, depending on individual requirements.
  • No Mutual Authentication – When the device tunnel is authenticated, the server performs authentication of the client, but the client does not authenticate the server. The lack of mutual authentication increases the risk of a man-in-the-middle attack.
  • CRL Checks Not Enforced – By default, RRAS does not perform certificate revocation checking for device tunnel connections. This means simply revoking a certificate won’t prevent the device from connecting. You’ll have to import the client’s device certificate into the Untrusted Certificates certificate store on each VPN server. Fortunately, there is a fix available to address this limitation, but it involves some additional configuration. See Always On VPN Device Tunnel and Certificate Revocation for more details.
  • No Support for Azure Conditional Access – Azure Conditional Access requires EAP authentication. However, the device tunnel does not use EAP but instead uses a simple device certificate check to authenticate the device.
  • No Support for Multifactor Authentication – As the device tunnel is authenticated by the RRAS VPN server directly and authentication requests are not sent to the NPS server, it is not possible to integrate MFA with the device tunnel.
  • Limited Connection Visibility – Since the device tunnel is designed for the device and not the user it does not appear in the list of active network connections in the Windows UI. There is no user-friendly connection status indicator, although the connection can be viewed using the classic network control panel applet (ncpa.cpl).

Summary

The choice to deploy Windows Always On VPN using the device tunnel alone, or in conjunction with the user tunnel, is a design choice that administrators must make based on their individual requirements. Using the device tunnel alone is supported and works but has some serious drawbacks and limitations. The best experience will be found using the device tunnel as it was intended, as an optional component to provide pre-logon connectivity for an existing Always On VPN user tunnel.

Additional Information

Windows 10 Always On VPN Device Tunnel with Azure VPN Gateway

Windows 10 Always On VPN Device Tunnel and Certificate Revocation

Windows 10 Always On VPN Device Tunnel Configuration with Microsoft Intune

Windows 10 Always On VPN Device Tunnel Does Not Connect Automatically

Windows 10 Always On VPN Device Tunnel Missing in Windows 10 UI

Deleting a Windows 10 Always On VPN Device Tunnel

Windows 10 Always On VPN Device Tunnel Configuration using PowerShell

Windows 10 Always On VPN IKEv2 Features and Limitations

Always On VPN SSTP Load Balancing with Citrix NetScaler ADC

Always On VPN SSTP Load Balancing with Citrix NetScaler ADCOne of the many advantages of using Windows Server Routing and Remote Access Service (RRAS) as the VPN server to support Windows 10 Always On VPN connections is that it includes support for the Secure Socket Tunneling Protocol (SSTP). SSTP is a TLS-based VPN protocol that is easy to configure and deploy and is very firewall friendly. This ensures consistent and reliable connectivity even behind restrictive firewalls. The Citrix ADC (formerly NetScaler) is a popular platform for load balancing Always On VPN connections. In this article I’ll describe how to configure load balancing on the Citrix ADC for RRAS VPN connections using the SSTP VPN protocol.

Special Note: In December 2019 a serious security vulnerability was discovered on the Citrix ADC that gives an unauthenticated attacker the ability to arbitrarily execute code on the appliance. As of this writing a fix is not available (due end of January 2020) but a temporary workaround can be found here.

Load Balancing SSTP

Previously I’ve written about some of the use cases and benefits of SSTP load balancing as well as the options for offloading TLS for SSTP VPN connections. Load balancing SSTP eliminates single points of failure and enables support for multiple RRAS VPN servers to increase scalability. It is generally recommended that the Citrix ADC be configured to pass through encrypted SSTP VPN connections. However, TLS offloading can be configured to improve performance and reduce resource utilization on VPN servers, if required.

Configuration

Load balancing SSTP on the Citrix ADC is straightforward and not unlike load balancing a common HTTPS web server. Below are specific settings and parameters required to load balance SSTP using the Citrix ADC.

Note: This article is not a comprehensive configuration guide for the Citrix ADC. It assumes the administrator is familiar with basic load balancing concepts and has experience configuring the Citrix ADC.

Service Settings

The load balancing service for SSTP VPN should be configured to use TCP port 443 and the SSL_BRIDGE protocol. If TLS offload is required, TCP port 80 and the HTTP protocol can be configured. Additional configuration is required on the RRAS server when TLS offload is enabled, however. Detailed information for configuring RRAS and SSTP for TLS offload can be found here.

Always On VPN SSTP Load Balancing with Citrix NetScaler ADC

Virtual Server Settings

The virtual server is configured to use TCP port 443. It is recommended to use SSLSESSION persistence.

Always On VPN SSTP Load Balancing with Citrix NetScaler ADC

The LEASTCONNECTION load balancing method is the recommend option for load balancing method.

Always On VPN SSTP Load Balancing with Citrix NetScaler ADC

Service Monitoring

Using the default TCP monitor (tcp-default) is not recommended for monitoring SSTP, as a simple TCP port check does not accurately reflect the health of the SSTP service running on the RRAS server. To more precisely monitor the SSTP service status, a new custom monitor must be created and bound to the load balancing services. Follow the steps below to configure a custom SSTP VPN monitor on the Citrix ADC.

  1. Open the Citrix ADC management console and expand Traffic Management.
  2. Select Monitors.
  3. Click Add.
  4. Enter a descriptive name in the Name field.
  5. Select HTTP form the Type drop-down list and click Select.
  6. Adjust the Interval and Response Time-out values according to your requirements.
  7. Enter 401 in the Response Codes field and click the “+” button.
  8. In the Response Codes field click the “x” next to 200.
  9. In the HTTP Request field enter HEAD /sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/.
  10. Check the box next to Secure (not required if TLS offload is enabled).
  11. Select ns_default_ssl_profile_backend from the SSL profile drop-down list (not required if TLS offload is enabled).
  12. Click Create.

Always On VPN SSTP Load Balancing with Citrix NetScaler ADC

Once complete, bind the new service monitor to the load balancing services or service groups accordingly.

TLS Offload

It is generally recommended that TLS offload not be enabled for SSTP VPN. However, if TLS offload is desired, it is configured in much the same way as a common HTTPS web server. Specific guidance for enabling TLS offload on the Citrix ADC can be found here. Details for configuring RRAS and SSTP to support TLS offload can be found here.

Certificates

When enabling TLS offload for SSTP VPN connections it is recommended that the public SSL certificate be installed on the RRAS server, even though TLS processing will be handled on the Citrix ADC and HTTP will be used between the Citrix ADC and the RRAS server. If installing the public SSL certificate on the RRAS server is not an option, additional configuration will be required. Specifically, TLS offload for SSTP must be configured using the Enable-SSTPOffload.ps1 PowerShell script, which can be found here.

Once the script has been downloaded, open an elevated PowerShell command window and enter the following command.

.\Enable-SSTPOffload.ps1 -CertificateHash [SHA256 Certificate Hash of Public SSL Certificate] -Restart

Example:

.\Enable-SSTPOffload.ps1 -CertificateHash ‘C3AB8FF13720E8AD9047DD39466B3C8974E592C2FA383D4A3960714CAEF0C4F2’ -Restart

Re-Encryption

When offloading TLS for SSTP VPN connections, all traffic between the Citrix ADC and the RRAS server will be sent in the clear using HTTP. In some instances, TLS offload is required only for traffic inspection, not performance gain. In this scenario the Citrix ADC will be configured to terminate and then re-encrypt connections to the RRAS server. When terminating TLS on the Citrix ADC and re-encrypting connections to the RRAS server is required, the same certificate must be used on both the Citrix ADC and the RRAS server. Using different certificates on the RRAS server and the load balancer is not supported.

Additional Information

Windows 10 Always On VPN Load Balancing and SSL Offload

SSL Offload Configuration for Citrix ADC (NetScaler)

Windows 10 Always On VPN SSTP Load Balancing with Kemp LoadMaster

Windows 10 Always On VPN SSTP Load Balancing with F5 BIG-IP

Windows 10 Always On VPN Connects then Disconnects

Windows 10 Always On VPN SSL Certificate Requirements for SSTP