Always On VPN and Interface Metrics

Always On VPN DNS Registration Update Available

In Windows, each network interface identified by the operating system is assigned a metric value. Interface metrics are settings that determine the priority or preference of network interfaces when there are multiple active network connections. The Windows networking stack uses these metrics to determine which network interface should be used for routing traffic when multiple network interfaces are available. Network interface metrics are critical for Always On VPN administrators to understand because they can impact how name resolution requests are processed when an Always On VPN connection is established.

Metric Values

By default, Windows automatically assigns metric values to network interfaces (including VPN interfaces) based on various factors, including the connection speed, link state, and interface type. It tries to select the most suitable interface for general internet connectivity.

Metrics and DNS

Windows will also use the network interface with the lowest metric value as the preferred interface for sending DNS queries by default. This means that DNS queries will be routed through the network interface with the lowest metric value, assuming it is available and connected. When an Always On VPN connection is established, DNS queries may fail or return unexpected results if the network interface metrics are not configured optimally.

Split DNS and Wired Ethernet

Split DNS (sometimes called ‘split brain DNS’) is when the DNS namespace is the same internally and externally. The most common scenario where interface metric settings interfere with DNS operation is when using split DNS and the endpoint is connected to the Internet with a wired Ethernet connection. In this scenario, the Ethernet interface will be assigned the same or lower interface metric value as the Always On VPN interface, which can yield unexpected results.

Viewing Metrics

Always On VPN administrators can view currently assigned interface metric values by running the following PowerShell command.

Get-NetIpInterface

Assigning Metrics

Most Always On VPN administrators will never have to change interface metric settings. However, if your implementation uses split DNS and some of your endpoints connect using wired Ethernet connections, you may need to update the interface metric settings to ensure proper DNS operation. Choose a setting for the interface metric value that is lower than the wired Ethernet interface. I’ve used a value of ‘3’ without issue for many years. Use one of the following methods to update the interface metric for Always On VPN connections.

PowerShell

Updating interface metric settings in Windows can be accomplished by running the Set-NetIpInterface PowerShell command.

Set-NetIpInterface -InterfaceAlias <connection name> -InterfaceMetric 3

Note: Using PowerShell to assign the interface metric is not persistent! While this method is suitable for local validation testing, you should use one of the following methods to implement this change permanently.

Rasphone.pbk

To assign the interface metric permanently, Always On VPN administrators can edit the following settings in the rasphone.pbk configuration file.

IpInterfaceMetric=3

Ipv6InterfaceMetric=3

Administrators can automate updating this setting using the Update-Rasphone.ps1 PowerShell script. In addition, the following scripts can be used with Microsoft Intune remediation.

Detect-DeviceIpv4InterfaceMetric.ps1

Remediate-DeviceIpv4InterfaceMetric.ps1

Detect-DeviceIpv6InterfaceMetric.ps1

Remediate-DeviceIpv6InterfaceMetric.ps1

Detect-Ipv4InterfaceMetric.ps1

Remediate-Ipv4InterfaceMetric.ps1

Detect-Ipv6InterfaceMetric.ps1

Remediate-Ipv6InterfaceMetric.ps1

DPC

Organizations using PowerON Platforms’ Dynamic Profile Configurator (DPC) to manage Always On VPN client configuration settings with Active Directory and group policy or Microsoft Intune can enable the VPN Tunnel Metric setting.

Additional Information

Get-NetIpInterface PowerShell Command

Set-NetIpInterface PowerShell Command

Managing Always On VPN Client Settings with DPC

Always On VPN DPC with Microsoft Intune

Always On VPN DPC Advanced Features

Always On VPN DPC Video Demonstration

PowerON Platforms Always On VPN Dynamic Profile Configurator (DPC)

Microsoft Entra Global Secure Access

Last week Microsoft introduced new Security Service Edge (SSE) capabilities as part of the Microsoft Entra suite of technologies. Included in these announcements, Microsoft introduced the public preview of two new secure remote access technologies – Microsoft Entra Internet Access and Microsoft Entra Private Access. The latter of these will particularly interest Microsoft Always On VPN administrators in some deployment scenarios.

Microsoft Entra Internet Access

Microsoft Entra Internet Access is a new Secure Web Gateway (SWG) cloud service solution designed to protect users from threats on the public Internet. Features include web content filtering, malware inspection, TLS inspection, and more. In addition, Entra Internet Access can protect Microsoft 365 applications. Azure Conditional Access policies can be enforced for Internet traffic. Network conditions are now included with Azure Conditional Access, which can further protect against attacks by requiring access from specific trusted or compliant networks. Today, the public preview is available for Microsoft 365 scenarios only. Internet traffic and other SaaS applications will be available later this year.

Microsoft Entra Private Access

Microsoft Entra Private Access is a Zero Trust Network Access (ZTNA) cloud service solution that leverages the Azure Application Proxy access model. With Azure App Proxy, administrators can easily publish private, on-premises web applications by installing the connector on an on-premises server. Administrators can leverage Azure AD authentication and conditional access policies to ensure device compliance or enforce multifactor authentication (MFA), if required. Microsoft Entra Private Access extends the capabilities of the Azure Application Proxy to support TCP and UDP-based applications.

Private Access vs. Always On VPN

Microsoft Entra Private Access will be a compelling alternative to Always On VPN in the future. Specifically, organizations using native Azure AD join devices could benefit tremendously from this technology. Microsoft Entra Private Access is much simpler to implement than Always On VPN and requires no on-premises infrastructure other than the Azure Application Proxy connector. Using Microsoft Entra Private Access also means that no inbound access from the Internet is required, making the solution inherently more secure and reducing the public attack surface. For organizations using hybrid Azure AD join, Always On VPN continues to be the best Microsoft solution for these scenarios.

References

Microsoft Entra Expands into Security Service Edge (SSE)

Microsoft Entra – Secure Access for a Connected World

Microsoft Entra Internet Access Preview

Microsoft Entra Private Access Preview

What is Zero Trust?

What is Zero Trust Network Access?

What is Security Service Edge (SSE)?

What is Secure Access Service Edge (SASE)?

What’s the Difference Between SSE and SASE?

Contact Us

I’ve had the privilege of participating in the private preview for Microsoft Entra Internet Access and Private Access. If you’d like to learn more about these technologies and how they can help your organization, fill out the form below, and I’ll provide more information.

Azure Conditional Access Certificates with SID Information Now Available

I recently wrote about changes to certificate-based authentication affecting Always On VPN implementations. These changes were introduced by Microsoft’s security update KB5014754. When the update is installed on domain controllers and enterprise Certification Authorities (CAs), administrators can perform strong user mapping for certificates used for Active Directory authentication. However, when first introduced, the update came with some serious limitations that prevented administrators from enabling full enforcement mode for certificate mapping.

Limitations

When KB5014754 is installed on an enterprise issuing CA, a new certificate extension (1.3.6.1.4.1.311.25.2) is added to the issued certificate that includes the principal’s (user or device) Security Identifier (SID). However, this only occurs when an online template is used. An online template is one with the subject name built from Active Directory information. The SID is not embedded in certificates issued using an offline template. Offline templates are templates where the subject name is supplied in the request. There are two scenarios where this causes problems for Always On VPN.

Microsoft Intune

Certificates delivered with Microsoft Intune via the Intune Certificate Connector use an offline template. This applies to certificates using PKCS or SCEP. Today, the SID is not embedded by issuing CAs using offline templates.

Azure Conditional Access

The short-lived certificate issued by Azure when Conditional Access is configured for Always On VPN did not include the SID. However, that recently changed.

Recent Updates

Today we can scratch Azure Conditional Access off the list of limitations for Always On VPN. Microsoft recently introduced support for the new SID extension in Azure Conditional Access certificates, as shown here.

Now when an Azure Conditional Access certificate is issued to an on-premises user or device account that is synced with Azure Active Directory, Azure Conditional Access will include the SID information in the issued short-lived certificate.

Intune

Unfortunately, we’re still waiting for Microsoft to address the limitation with certificates delivered using Microsoft Intune. Hopefully we’ll see an update for that later this year.  

Additional Information

Certificate-Based Authentication Changes and Always On VPN

Microsoft KB5014754

Digital Certificates and TPM

Microsoft Intune Certificate Connector Service Account and PKCS

%d bloggers like this: