Always On VPN and Intune Proactive Remediation

Always On VPN and Autopilot Hybrid Azure AD Join

When configuring and deploying Windows Always On VPN using Microsoft Endpoint Manager (MEM)/Intune, administrators may find that some settings are not exposed in the MEM UI. In some cases, deploying the configuration profile using custom XML is the workaround. However, many crucial Always On VPN settings are not exposed using either method. Here, administrators must resort to editing settings in the VPN configuration file on the client after provisioning the VPN profile.

Phonebook

A file called rasphone.pbk stores all Windows VPN settings on the endpoint. It includes name/value pairs that correspond to many settings administrators change manually in the GUI. Other settings can be changed using PowerShell. Depending on the connection type, the file can be found in one of two locations.

  • User Tunnel: $env:AppData\Microsoft\Network\Connections\Pbk\rasphone.pbk
  • Device Tunnel: $env:ProgramData\Microsoft\Network\Connections\Pbk\rasphone.pbk

Documentation for Windows VPN client phonebook entry settings can be found here.

Limitations

Unfortunately, editing the rasphone.pbk file isn’t always convenient. Making the changes is technically easy. Administrators can write a simple PowerShell script to update the text file as required. However, automating this at scale is challenging. Thankfully, Intune Proactive Remediations can help.

Proactive Remediations

With Intune Proactive Remediations, administrators can create and deploy script packages to monitor and optionally update specific configuration settings. The package includes two scripts, a detection script, and a remediation script. The detection script looks at the current value of a particular setting and reports on its compliance. The remediation script is triggered to update the setting if the value is incorrect.

Requirements

Intune Proactive Remediations has some specific licensing requirements. Administrators must also enroll devices into Endpoint analytics and provision a Windows Health Monitoring configuration profile. There are also limitations on the size and type of scripts that administrators can use. More information on prerequisites can be found here.

Script Packages

Administrators can create detection and remediation PowerShell scripts to update settings in rasphone.pbk, or optionally, they can download sample scripts from my GitHub repository here. This repository contains user and device tunnel detection and remediation scripts for many popular settings in rasphone.pbk. Examples include updating the VPN Strategy, changing VPN interface metrics, disabling class-based default routes, and many more.

Note: The scripts in my GitHub repository are examples only. While they can be used in production environments, they are basic and may not work as expected in all scenarios. For example, the scripts as written today assume only a single VPN profile provisioned. Unexpected results may occur if more than one VPN profile exists. Please use them at your own risk.

Deployment

In this example, we’ll deploy a Proactive Remediation to disable IKE mobility for user tunnel VPN connections. To configure an Intune Proactive Remediation, open the Microsoft Endpoint Manager portal (https://endpoint.microsoft.com/) and navigate to Reports > Endpoint analytics > Proactive remediations. After creating or downloading the detection and remediation scripts, perform the following steps to create and deploy a Proactive Remediation script package.

  1. Click Create script package.
  2. Enter a name for the package in the Name field.
  3. Enter a description for the package in the Description field (optional).
  4. Click Next.
  5. Click the blue folder icon next to the Detection script file field and upload the detection script.
  6. Click the blue folder icon next to the Remediation script file field and upload the associated remediation script.
  7. For user tunnel connections, click Yes next to Run this script using the logged-on credentials. For device tunnel connections, click No.
  8. Click Next.

Assign scope tags and group assignments as necessary, then click Create. Click Refresh to update the UI to display the newly created script package.

Caveats

Be advised that Proactive Remediation script packages run immediately after the first device sync and then every 24 hours after that. Timing issues could lead to delays in functionality. For example, if an Always On VPN profile is provisioned after a Proactive Remediation script runs, the changes made by the remediation script won’t be available until much later. Also, changes made while the VPN is active will not take effect until after restarting the connection.

Special Thanks

Special thanks to Tom Klaver at Inspark for turning me on to this feature. It has been an absolute lifesaver for sure!

Additional Information

Microsoft Intune Proactive Remediation Tutorial

Windows VPN Phonebook Entry Settings

Intune Proactive Remediation Script Samples on GitHub

Microsoft Windows Always On VPN Class-Based Default Route and Intune

Microsoft Windows Always On VPN Short Name Access Failure

DirectAccess Troubleshooting with Nmap

DirectAccess IP-HTTPS Discovery Script for NmapDirectAccess troubleshooting can be made much easier using open source tools such as Nmap. Nmap can be used to perform many essential network connectivity and configuration checks, including validating network paths, confirming DirectAccess server response, and viewing SSL configuration. Nmap can also be used to ensure that the attack surface of the DirectAccess server is properly minimized. Some tests can be performed using only native Nmap functionality, while others require the use of specialized Nmap scripts that are included with the tool.

Installation

Nmap can be installed on a wide variety of operating systems, including Windows. If you plan to install Nmap on Windows, be sure to also install WinPcap and the Microsoft Visual C++ 2013 Redistributable. The Visual C++ component is included with the Nmap download. WinPcap must be downloaded separately here.

Testing External Connectivity

Validating external connectivity is often one of the first DirectAccess troubleshooting steps I take. Confirm that the DirectAccess public hostname resolves to the correct IP address, then run the following Nmap command to validate network connectivity from the Internet to the DirectAccess server.

nmap -n -Pn -p443 <da_public_hostname>

DirectAccess Troubleshooting with Nmap

If the hostname resolves correctly and the network path is complete, the server should respond and Nmap will show the port as open. However, this doesn’t necessarily mean that the DirectAccess server is the device that replied! Due to misconfiguration, it is possible that another server or network device listening on TCP port 443 responded, so this is not a conclusive test.

DirectAccess Server Response

To confirm the DirectAccess server is responding to HTTPS requests and not some other server or device, run the following Nmap command with the ip-https-discover script.

nmap -n -Pn -p443 <da_public_hostname> –script ip-https-discover

If the DirectAccess server responds to the request, Nmap will return the following message:

IP-HTTPS is supported. This indicates that this host supports Microsoft DirectAccess.

DirectAccess Troubleshooting with Nmap

If the port is open but the script does not return this message, it is likely that another server or device is responding on TCP port 443, not the DirectAccess server.

Note: If an Application Delivery Controller (ADC) is configured to perform IP-HTTPS preauthentication, the Nmap IP-HTTPS discovery script will not return this result. This is expected and by design.

SSL Certificate Validation

It is not uncommon for DirectAccess clients to fail to connect via IP-HTTPS because of SSL certificate issues. Specifically, an SSL certificate that is not trusted, is expired, or its subject field does not match the public hostname will prevent DirectAccess clients from connecting. To view the SSL certificate configuration of a DirectAccess server, run the following Nmap command with the ssl-cert script.

nmap -n -Pn -p443 <da_public_hostname> –script ssl-cert

DirectAccess Troubleshooting with Nmap

SSL Cipher Suite Configuration

Occasionally there can be issues with the SSL configuration on the DirectAccess server that prevent some clients from connecting, or result in poor performance. This commonly occurs when administrators perform SSL hardening on the DirectAccess server and remove support for null cipher suites. Null cipher suites should never be disabled on the DirectAccess server. They are important to ensure the highest levels of performance for Windows 8.x and Windows 10 clients. Also, if an Application Delivery Controller (ADC) or load balancer is performing SSL offload, lack of support for null cipher suites will prevent Windows 8.x and Windows 10 clients from connecting. To determine if the DirectAccess server supports null cipher suites, run the following Nmap command with the ssl-enum-ciphers script.

nmap -n -Pn -p443 <da_public_hostname> –script ssl-enum-ciphers

DirectAccess Troubleshooting with Nmap

Attack Surface Audit

If DirectAccess implementation and security best practices are followed, the DirectAccess server will be behind an edge firewall. The only port required to be allowed inbound for DirectAccess is TCP port 443. It is recommended that a full port scan be performed against the DirectAccess server’s public IPv4 address to identify any unnecessary ports that may be open externally. To perform a full port scan, run the following Nmap command.

nmap -n -Pn -p- <da_public_hostname>

Ideally it should look like this.

DirectAccess Troubleshooting with Nmap

If it looks something like this, you’re in serious trouble!

DirectAccess Troubleshooting with Nmap

The DirectAccess server should never be listening for requests other that HTTPS on the public Internet. Exposing services such as SMB (TCP port 445), RDP (TCP port 3389), and others presents a significant security risk. It is recommended that edge firewalls be configured to allow inbound TCP port 443 only. If the DirectAccess server is connected directly to the public Internet (not recommended!) then the Windows Firewall should be configured to restrict access to inbound TCP port 443 only.

Additional Resources

DirectAccess IP-HTTPS Discovery Script for Nmap
Planning and Implementing DirectAccess with Windows Server 2016 on Pluralsight
Implementing DirectAccess with Windows Server 2016 Book
DirectAccess Troubleshooting and Consulting Services

%d bloggers like this: