Always On VPN Updates to Improve Connection Reliability

Always On VPN Updates to Improve Connection ReliabilityA longstanding issue with Windows 10 Always On VPN is that of VPN tunnel connectivity reliability and device tunnel/user tunnel interoperability. Many administrators have reported that Always On VPN connections fail to establish automatically at times, that only one tunnel comes up at a time (user tunnel or device tunnel, but not both), or that VPN tunnels fail to establish when coming out of sleep or hibernate modes. Have a look at the comments on this post and you’ll get a good understanding of the issues with Always On VPN.

Recent Updates

The good news is that most of these issues have been resolved with recent updates to Windows 10 1803 and 1809. Specifically, the February 19, 2019 update for Windows 10 1803 (KB4487029) and the March 1, 2019 update for Windows 10 1809 (KB4482887) include fixes to address these known issues. Administrators are encouraged to deploy Windows 10 1803 with the latest updates applied when implementing Always On VPN. Windows 10 1809 with the latest updates applied is preferred though.

Persistent Issues

Although initial reports are favorable for these updates and based on my experience the effectiveness and reliability of Windows 10 Always On VPN is greatly improved, there have still been some reports of intermittent VPN tunnel establishment failures.

Possible Causes

During my testing, after applying the updates referenced earlier both device tunnel and user tunnel connections are established much more consistently than before the updates were applied. I did encounter some issues, however. Specifically, when coming out of sleep or hibernate, VPN connections would fail to establish. Occasionally VPN connections would fail after a complete restart.

NCSI

After further investigation it was determined that the connectivity failure was caused by the Network Connectivity Status Indicator (NCSI) probe failing, causing Windows to report “No Internet access”.

Always On VPN Updates to Improve Connection Reliability

Cisco Umbrella Roaming Client

In this instance the NCSI probe failure was caused by the Cisco Umbrella Roaming Client installed and running on the device. The Umbrella Roaming Client is security software that provides client protection by monitoring and filtering DNS queries. It operates by configuring a DNS listener on the loopback address. NCSI probes are known to fail when the DNS server is running on a different interface than is being tested.

Resolution

Microsoft released a fix for this issue in Windows 10 1709. The fix involves changing a group policy setting to disable interface binding when perform DNS lookups by the NCSI. You can enable this setting via Active Directory group policy by navigating to Computer Configuration > Administrative Templates > Network > Network Connectivity Status Indicator > Specify global DNS. Select Enabled and check the option to Use global DNS, as shown here.

Always On VPN Updates to Improve Connection Reliability

For testing purposes this setting can be enabled individual using the following PowerShell command.

New-ItemProperty -Path “HKLM:\SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator\” -Name UseGlobalDNS -PropertyType DWORD -Value 1 -Force

Third-Party Software

As Always On VPN connectivity can be affected by NCSI, any third-party firewall or antivirus/antimalware solution could potentially introduce VPN connection instability. Observe NCSI operation closely when troubleshooting unreliable connections with Always On VPN.

Additional Information

Windows 10 1803 Update KB4487029

Windows 10 1809 Update KB4482887

Cisco Umbrella Roaming Client Limited Network Connectivity Warning

Network Connectivity Status Indicator (NCSI) Operation Explained

NetMotion Mobility Device Tunnel Configuration

NetMotion Mobility Device Tunnel ConfigurationIn its default configuration, NetMotion Mobility connections are established at the user level. In most cases this level of access is sufficient, but there are some common uses cases that require VPN connectivity before the user logs on. Examples include provisioning a new device to a user who has never logged on before, or to allow support engineers to connect to a remote device without requiring a user to log in first.

Infrastructure Requirements

To support NetMotion Mobility’s “unattended mode” (device tunnel) it will be necessary to deploy a Windows Server 2016 (or 2012R2) Network Policy Server (NPS). In addition, an internal private certification authority (CA) will be required to issue certificates to the NPS server and all NetMotion Mobility client computers.

Client Certificate Requirements

A certificate with the Client Authentication Enhanced Key Usage (EKU) must be provisioned to the local computer certificate store on all NetMotion Mobility clients that require a device tunnel (figure 1). The subject name on the certificate must match the fully qualified domain name of the client computer (figure 2). It is recommended that certificate auto enrollment be used to streamline the provisioning process.

NetMotion Mobility Device Tunnel Configuration

Figure 1. Computer certificate with Client Authentication EKU.

NetMotion Mobility Device Tunnel Configuration

Figure 2. Computer certificate with subject name matching the client computer’s hostname.

NPS Server Certificate Requirements

A certificate with the Server Authentication EKU must be provisioned to the local computer certificate store on the NPS server (figure 3). The subject name on the certificate must match the fully qualified domain name of the NPS server (figure 4).

NetMotion Mobility Device Tunnel Configuration

Figure 3. Computer certificate with Server Authentication EKU.

NetMotion Mobility Device Tunnel Configuration

Figure 4. Computer certificate with subject name matching the NPS server’s hostname.

NPS Server Configuration

Next install the NPS server role by running the following PowerShell command.

Install-WindowsFeature NPAS -IncludeMamagementTools

Once complete, open the NPS server management console and perform the following steps.

Note: Below is a highly simplified NPS configuration designed for a single use case. It is provided for demonstration purposes only. The NPS server may be used by more than one network access server (NAS) so the example policies included below may not work in every deployment.

  1. Expand RADIUS Clients and Servers.
  2. Right-click RADIUS clients and choose New.
  3. Select the option to Enable this RADIUS client.
  4. Enter a friendly name.
  5. Enter the IP address or hostname of the NetMotion gateway server.
  6. Click Verify to validate the hostname or IP address.
  7. Select Manual to enter a shared secret, or select Generate to create one automatically.
  8. Copy the shared secret as it will be required when configure the NetMotion Mobility gateway server later.
  9. Click OK.
    NetMotion Mobility Device Tunnel Configuration
  10. Expand Policies.
  11. Right-click Network Policies and choose New.
  12. Enter a descriptive name for the new policy.
  13. Select Type of network access server and choose Unspecified.
  14. Click Next.
    NetMotion Mobility Device Tunnel Configuration
  15. Click Add.
  16. Select Client IPv4 Address.
  17. Click Add.
  18. Enter the internal IPv4 address of the NetMotion Mobility gateway server.
  19. Click OK.
  20. Click Next.
    NetMotion Mobility Device Tunnel Configuration
  21. Select Access granted.
  22. Click Next.
    NetMotion Mobility Device Tunnel Configuration
  23. Click Add.
  24. Choose Microsoft: Protected EAP (PEAP).
  25. Click OK.
  26. Select Microsoft: Protected EAP (PEAP).
  27. Click Edit.
  28. Choose the appropriate certificate in the Certificate issued to drop down list.
  29. Select Secure password (EAP-MSCHAP v2).
  30. Click Remove.
  31. Click Add.
  32. Choose Smart Card or other certificate.
  33. Click OK.
  34. Select Smart Card or other certificate.
  35. Click Edit.
  36. Choose the appropriate certificate in the Certificate issued to drop down list.
  37. Click OK.
    NetMotion Mobility Device Tunnel Configuration
  38. Uncheck all options beneath Less secure authentication methods.
  39. Click Next three times.
  40. Click Finish.
    NetMotion Mobility Device Tunnel Configuration

Mobility Server Configuration

Open the NetMotion Mobility management console and perform the following steps.

  1. In the drop-down menu click Configure.
  2. Click Authentication Settings.
  3. Click New.
  4. Enter a descriptive name for the new authentication profile.
  5. Click OK.
  6. Expand Authentication.
  7. Select Mode.
  8. Select Unattended Mode Authentication Setting Override.
  9. From the Authentication mode drop-down box choose Unattended.
  10. Click Apply.
    NetMotion Mobility Device Tunnel Configuration
  11. Expand RADIUS: Device Authentication.
  12. Select Servers.
  13. Select [Profile Name] Authentication Setting Override.
  14. Click Add.
  15. Enter the IP address of the NPS server.
  16. Enter the port (default is 1812).
  17. Enter the shared secret.
  18. Click OK.
    NetMotion Mobility Device Tunnel Configuration
  19. In the drop-down menu click Configure.
  20. Click Client Settings.
  21. Expand Device Settings.
  22. Select the device group to enable unattended mode for.
  23. Expand Authentication.
  24. Select Settings Profile.
  25. Select [Device Group Name] Group Settings Override.
  26. In the Profile drop-down menu choose the authentication profile created previously.
  27. Click Apply.
    NetMotion Mobility Device Tunnel Configuration

Validation Testing

If everything is configured correctly, the NetMotion Mobility client will now indicate that the user and the device have been authenticated.

NetMotion Mobility Device Tunnel Configuration

Summary

Enabling unattended mode with NetMotion Mobility provides feature parity with DirectAccess machine tunnel and Windows 10 Always On VPN device tunnel. It ensures that domain connectivity is available before the user logs on. This allows users to log on remotely without cached credentials. It also allows administrators to continue working seamlessly on a remote computer after a reboot without having a user present to log on.

Additional Resources

NetMotion Mobility as an Alternative to DirectAccess

 

DirectAccess IP-HTTPS Preauthentication using F5 BIG-IP

Note: For information about configuring the Citrix NetScaler to perform IP-HTTPS preauthentication, click here. For information about configuring Windows Server 2012 R2 to perform IP-HTTPS preauthentication natively, click here.

Introduction

DirectAccess IP-HTTPS Preauthentication using F5 BIG-IPRecently I wrote about security challenges with DirectAccess and the IP-HTTPS IPv6 transition technology. Specifically, IP-HTTPS transition tunnel connections are not authenticated by the DirectAccess server, only the client. This allows an unauthorized device to obtain an IPv6 address on the DirectAccess client network. With it, an attacker can perform network reconnaissance using ICMPv6 and potentially launch a variety of Denial-of-Service (DoS) attacks. For more details, click here.

Note: DirectAccess IPsec data connections not at risk. Data is never exposed at any time with the default configuration.

Mitigation

To mitigate these issues, it is recommended that an Application Delivery Controller (ADC) be used to terminate SSL connections and enforce client certificate authentication. Doing this will ensure that only authorized connections will be accepted by the DirectAccess server. In addition, there are some scalability and performance benefits to implementing this configuration when supporting Windows 7 clients.

Important Considerations

Performing IP-HTTPS preauthentication on the F5 BIG-IP is formally unsupported by Microsoft. In addition, terminating IP-HTTPS on the F5 appliance breaks OTP authentication.

F5 BIG-IP Configuration

To configure the F5 BIG-IP to perform SSL offload for DirectAccess IP-HTTPS, follow the guidance documented here. In addition, to configure the F5 BIG-IP to perform preauthentication for DirectAccess clients, when creating the client SSL profile, click Custom above the Client Authentication section and choose Require from the Client Certificate drop-down list and Always from the Frequency drop-down list. In addition, choose your internal PKI’s root Certification Authority (CA) certificate from the Trusted Certificate Authorities drop-down list and from the Advertised Certificate Authorities drop-down list.

DirectAccess IP-HTTPS Preauthentication using F5 BIG-IP

Summary

Enabling client certificate authentication for IP-HTTPS connections ensures that only authorized DirectAccess clients can establish a connection to the DirectAccess server and obtain an IPv6 address. It also prevents an unauthorized user from performing network reconnaissance or launching IPv6 Denial-of-Service (DoS) attacks.