All posts in category Active Directory

Considerations for Always On VPN with Azure VPN Gateway and Virtual WAN

Organizations migrating on-premises applications, data, and infrastructure to the cloud may also consider terminating Always On VPN connections there. Using one of the native Azure VPN services might be compelling at first glance. After all, having an Azure-managed VPN gateway service sounds intuitive. However, some severe limitations exist for using Azure VPN services for Always On VPN deployments.

Azure VPN Gateway

The following are limitations for Always On VPN with Azure VPN gateway.

Authentication Methods

Azure VPN gateway supports both EAP and machine certificate authentication. However, it can only support one authentication method at a time. With only EAP or certificate authentication, administrators must choose between a device or user tunnel. A single Azure VPN gateway cannot support both at the same time. For native Entra ID joined devices, this is not a problem. However, for native on-premises Active Directory or hybrid Entra ID joined devices, this is a problem, as the device tunnel is essential in these scenarios.

Note: Technically speaking, administrators could deploy another Azure VPN gateway to work around this limitation. However, Azure limits VPN gateway deployments to one per virtual network. This requires administrators to deploy a second VPN gateway in a separate virtual network, which then requires virtual network peering to be enabled, complicating the configuration greatly.

SSTP

Although the Azure VPN gateway supports SSTP, it is, unfortunately, a second-class citizen. Today, all SKUs of the Azure VPN gateway are limited to just 128 SSTP connections (256 in active/active mode). There is currently no way to increase this. If more than 256 connections are required, you must use IKEv2.

RADIUS

In addition, there is currently no option to change the default timeout value (30 seconds) for RADIUS authentication requests. This short timeout value presents a challenge when using MFA with the NPS extension or with Azure Conditional Access, as users may be unable to respond to the push notification before the timeout expires, resulting in failed authentication attempts.

In addition, Azure does not support routing traffic to on-premises RADIUS servers over ExpressRoute connections. In this scenario, administrators must route RADIUS traffic to on-premises servers over a site-to-site connection.

Geographic Redundancy

Geographic redundancy using Azure Traffic Manager (or another global server load balancer) with two or more gateways is not supported when using the Azure VPN gateway. Azure manages the certificate used on the gateway, which includes a certificate with the subject name of the individual gateway. There is no option to supply a custom certificate with a global hostname in the subject, which is required to support geographic redundancy. With that, administrators are limited to the redundancy provided natively by the Azure VPN gateway.

IPv6

Azure does not support Azure VPN gateway in a virtual network that includes IPv6 addressing.

Azure Virtual WAN

Azure Virtual WAN includes many of the same limitations as the Azure VPN gateway, in addition to the following.

SSTP

Unlike the Azure VPN gateway, there is no support for SSTP in Azure Virtual WAN.

IPv6

IPv6 is not currently supported at all in Azure Virtual WAN.

Summary

Intuitively, it seems that leveraging native Azure VPN gateway services would be ideal. However, due to the limitations outlined in this article, administrators must decide carefully if any of these prevent adoption in their environment. Although not formally supported, many organizations deploy Windows Server Routing and Remote Access (RRAS) servers in Azure to address these limitations.

Additional Information

Always On VPN Options for Azure Deployments

Always On VPN with Azure Gateway

Always On VPN Device Tunnel with Azure VPN Gateway

Always On VPN and RRAS in Azure

What is Azure VPN Gateway?

What is Azure Virtual WAN?

3 Comments

by Richard M. Hicks on January 31, 2024 • Permalink

Posted in AADJ, Active Directory, administration, Always On VPN, AOVPN, authentication, Azure, Azure Active Directory, Azure AD, Azure AD Join, Azure Conditional Access, Azure MFA, Azure Virtual WAN, Azure VPN, Azure VPN Gateway, certificates, cloud, Cloud Service, Conditional Access, Deployment, device tunnel, EAP, Enterprise, enterprise mobility, Entra, Entra ID, extensible authentication protocol, global server load balancer, GSLB, HAADJ, High Availability, Hybrid Azure AD Join, IKEv2, Infrastructure, IPv6, MFA, Microsoft, Microsoft Entra, Microsoft Entra ID, Mobility, Multifactor Authentiction, multisite, network policy server, NPS, OTP, public cloud, Remote Access, routing and remote access service, RRAS, Secure Socket Tunneling Protocol, Security, SSTP, user tunnel, VPN, Windows 10, Windows 11, Windows Server 2016, Windows Server 2019, Windows Server 2022

Posted by Richard M. Hicks on January 31, 2024

https://directaccess.richardhicks.com/2024/01/31/considerations-for-always-on-vpn-with-azure-vpn-gateway-and-virtual-wan/

Always On VPN November 2023 Security Updates

Microsoft has released its security updates for November 2023. For Always On VPN administrators, it’s a light month, with just a single CVE affecting Always On VPN infrastructure.

PEAP

CVE-2023-36028 addresses a remote code execution (RCE) vulnerability in the Microsoft Protected Extensible Authentication Protocol (PEAP). An attacker could exploit this vulnerability by sending a specially crafted PEAP packet to a Windows Network Policy Server (NPS). This attack does not require authentication or user interaction.

Affected Systems

This PEAP vulnerability affects only NPS servers configured to support PEAP authentication explicitly. PEAP authentication is a best practice configuration for Always On VPN deployments and is widely deployed. NPS servers deployed to support other services, such as Wi-Fi or router and switch access that are configured to allow PEAP authentication, are also affected.

Exposure

NPS servers are not (or should not be!) exposed directly to the public Internet. This limits the attack surface to adversaries already on the internal network.

Mitigation

Microsoft suggests disabling PEAP authentication support on NPS servers until the update is applied. However, this would break the majority of Always On VPN deployments today. Since disabling PEAP isn’t a viable option, administrators can reduce their attack surface by updating the NPS firewall rules to restrict access only to authorized VPN servers or other network devices until their systems are fully updated.

Additional Information

November 2023 Security Updates

CVE-2023-36028 PEAP Remote Code Execution Vulnerability

4 Comments

by Richard M. Hicks on November 14, 2023 • Permalink

Posted by Richard M. Hicks on November 14, 2023

https://directaccess.richardhicks.com/2023/11/14/always-on-vpn-november-2023-security-updates/

Always On VPN and Interface Metrics

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