All posts tagged always on

Always On VPN and Device Sharing

Always On VPN client configuration settings are typically deployed in the user’s context. However, this presents a unique challenge when sharing a single device with multiple users who have an Always On VPN profile assigned to them. By design, Windows designates only a single user profile on a shared device to be “always on”. When multiple users with assigned Always On VPN profiles share the same machine, it could yield unexpected results.

Auto Trigger Profile

When an Always On VPN profile is provisioned to a user, Windows records information about this profile in the registry. Specifically, the Always On VPN profile’s name and GUID are recorded, as well as the user’s Security Identifier (SID) and the path to the rasphone.pbk file that contains the Always On VPN profile.

Multiple Users

When a new user logs on to a shared device and receives their Always On VPN profile, Windows overwrites this existing data in the registry with the current user’s information. Each time this user logs on, their Always On VPN connection will establish automatically. Any other users with Always On VPN profiles configured on the same shared device will no longer connect automatically after this. The most recently deployed Always On VPN profile will be designated the “always on” profile.

Connect Automatically

In the above scenario, any user with an assigned Always On VPN profile on the shared device can take over the “always on” designation by opening the VPN connection properties and checking the “Connect automatically” check box.

When this happens, this user will now own the “always on” profile, and other users on the shared device will no longer connect automatically.

Workarounds

If multiple users share a single device requiring Always On VPN connectivity, you have a few options.

Intune

If you are deploying Always On VPN client configuration settings using Intune, you must use the Custom device configuration profile template. Specifically, as shown here, you must deploy your XML configuration file using the ./Device/Vendor/MSFT/VPNv2/ OMA-DM URI.

Unfortunately, the native Intune VPN template does not support deploying Always On VPN profiles in the “all users” context.

PowerShell

When using PowerShell, either natively or with SCCM or another software deployment tool, administrators can use my Always On VPN deployment PowerShell script with the -AllUserConnection parameter.

PowerON DPC

When using PowerON Platforms’ Dynamic Profile Configurator (DPC) to deploy Always On VPN client configuration settings using on-premises Active Directory or via Intune, no changes are required. DPC deploys Always On VPN user profiles in the “all users” context by default.

Additional Information

New-AovpnConnection.ps1 PowerShell Script on GitHub

PowerON Platforms’ Dynamic Profile Configurator (DPC)

Always On VPN DPC with PowerON Platforms’ DPC

6 Comments
by Richard M. Hicks on March 27, 2023  •  Permalink
Posted in administration, Always On VPN, AOVPN, AovpnDPC, Deployment, DPC, Dynamic Profile Configurator, Endpoint Manager, Enterprise, enterprise mobility, GitHub, InTune, MDM, MEM, MEMCM, Microsoft, Microsoft Endpoint Manager, Microsoft Intune, Mobile Device Management, Mobility, OMA-DM, Operational Support, PowerShell, ProfileXML, Remote Access, user tunnel, VPN, Windows 10, Windows 11
Tagged , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on March 27, 2023

https://directaccess.richardhicks.com/2023/03/27/always-on-vpn-and-device-sharing/

Always On VPN with Azure Gateway

Always On VPN with Azure GatewayRecently I wrote about VPN server deployment options for Windows 10 Always On VPN in Azure. In that post I indicated the native Azure VPN gateway could be used to support Always On VPN connections using Internet Key Exchange version 2 (IKEv2) and Secure Socket Tunneling Protocol (SSTP). In this post I’ll outline the requirements and configuration steps for implementing this solution.

Requirements

To support Always On VPN, point-to-site VPN connections must be enabled on the Azure VPN gateway. Not all Azure VPN gateways are alike, and point-to-site connections are not supported in all scenarios. For Always On VPN, the Azure VPN gateway must meet the following requirements.

VPN SKU

The Azure VPN gateway SKU must be VpnGw1, VpnGw2, VpnGw3, VpnGw1AZ, VpnGw2AZ, or VpnGw3AZ. The Basic SKU is not supported.

VPN Type

The VPN type must be route-based. Policy-based VPN gateways are not supported for point-to-site VPN connections.

Limitations

Using the Azure VPN gateway for Always On VPN may not be ideal in all scenarios. The following limitations should be considered thoroughly before choosing the Azure VPN gateway for Always On VPN.

Device Tunnel

RADIUS/EAP authentication for user tunnel connections is not supported if the Azure VPN gateway is configured to support device tunnel with machine certificate authentication.

Maximum Connections

A maximum of 250, 500, and 1000 concurrent IKEv2 connections are supported when using the VpnGw1/AZ, VpnGw2/AZ, and VpnGw3/AZ SKUs, respectively (x2 for active/active gateway deployments). In addition, a maximum of 128 concurrent SSTP connections are supported for all VPN gateway SKUs (x2 for active/active gateway deployments).

Always On VPN with Azure Gateway

Reference: https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpngateways#gwsku

RADIUS Requirements

To support Always On VPN connections, the Azure VPN gateway must be configured to authenticate to a RADIUS server. The RADIUS server must be reachable from the VPN gateway subnet. The RADIUS server can be hosted in Azure or on-premises. Before proceeding, ensure that any network routes, firewall rules, and site-to-site VPN tunnel configuration is in place to allow this communication.

RADIUS Configuration

Guidance for configuring Windows Server NPS for Always On VPN can be found here. The only difference when configuring NPS for use with Azure VPN gateway is the RADIUS client configuration.

Open the NPS management console (nps.msc) and follow the steps below to configure Windows Server NPS to support Always On VPN client connections from the Azure VPN gateway.

1. Expand RADIUS Clients and Servers.
2. Right-click RADIUS Clients and choose New.
3. Enter a descriptive name in the Friendly name field.
4. Enter the Azure VPN gateway subnet using CIDR notation in the Address (IP or DNS) field. The gateway subnet can be found by viewing the properties of the Azure VPN gateway in the Azure portal.
5. Enter the shared secret to be used for RADIUS communication in the Shared secret field.

Always On VPN with Azure Gateway

Azure VPN Gateway Configuration

To begin, provision a Virtual Network Gateway in Azure that meets the requirements outlined above. Guidance for implementing an Azure VPN gateway can be found here. Once complete, follow the steps below to enable support for Always On VPN client connections.

Enable Point-to-Site

Perform the following steps to enable point-to-site VPN connectivity.

1. In the navigation pane of the Azure VPN gateway settings click Point-to-site configuration.
2. Click Configure Now and specify an IPv4 address pool to be assigned to VPN clients. This IP address pool must be unique in the organization and must not overlap with any IP address ranges defined in the Azure virtual network.
3. From the Tunnel type drop-down list select IKEv2 and SSTP (SSL).
4. In the RADIUS authentication field enter the IPv4 address of the RADIUS server. At the time of this writing only a single IPv4 address is supported. If RADIUS redundancy is required, consider creating a load balanced NPS cluster.
5. In the Server secret field enter the RADIUS shared secret.
6. Click Save to save the configuration.

Always On VPN with Azure Gateway

VPN Client Configuration

Perform the following steps to configure a Windows 10 VPN client to connect to the Azure VPN gateway.

Download VPN Configuration

1. Click Point-to-site configuration.
2. Click Download VPN client.
3. Select EAPMSCHAv2 (yes, that’s correct even if EAP-TLS will be used!)
4. Click Download.
5. Open the downloaded zip file and extract the VpnSettings.XML file from the Generic folder.
6. Copy the FQDN in the VpnServer element in VpnSettings.XML. This is the FQDN that will be used in the template VPN connection and later in ProfileXML.

Always On VPN with Azure Gateway

Create a Test VPN Connection

On a Windows 10 device create a test VPN profile using the VPN server address copied previously. Configure EAP settings to match those configured on the NPS server and test connectivity.

Create an Always On VPN Connection

Once the VPN has been validated using the test profile created previously, the VPN server and EAP configuration from the test profile can be used to create the Always On VPN profile for publishing using Intune, SCCM, or PowerShell.

IKEv2 Security Configuration

The default IKEv2 security parameters used by the Azure VPN gateway are better than Windows Server, but the administrator will notice that a weak DH key (1024 bit) is used in phase 1 negotiation.

Always On VPN with Azure Gateway

Use the following PowerShell commands to update the default IKEv2 security parameters to recommended baseline defaults, including 2048-bit keys (DH group 14) and AES-128 for improved performance.

Connect-AzAccount
Select-AzSubscription -SubscriptionName [Azure Subscription Name]

$Gateway = [Gateway Name]
$ResourceGroup = [Resource Group Name]

$IPsecPolicy = New-AzVpnClientIpsecParameter -IpsecEncryption AES128 -IpsecIntegrity SHA256 -SALifeTime 28800 -SADataSize 102400000 -IkeEncryption AES128 -IkeIntegrity SHA256 -DhGroup DHGroup14 -PfsGroup PFS14

Set-AzVpnClientIpsecParameter -VirtualNetworkGatewayName $Gateway -ResourceGroupName $ResourceGroup -VpnClientIPsecParameter $IPsecPolicy

Note: Be sure to update the cryptography settings on the test VPN connection and in ProfileXML for Always On VPN connections to match the new VPN gateway settings. Failing to do so will result in an IPsec policy mismatch error.

Additional Information

Microsoft Azure VPN Gateway Overview

About Microsoft Azure Point-to-Site VPN

Windows 10 Always On VPN IKEv2 Security Configuration

 

 

 

74 Comments
by Richard M. Hicks on August 26, 2019  •  Permalink
Posted in Always On VPN, AOVPN, Azure, Azure VPN, Azure VPN Gateway, cloud, device tunnel, Enterprise, enterprise mobility, IKEv2, InTune, Microsoft Intune, Mobility, network policy server, NPS, PowerShell, ProfileXML, Remote Access, Security, SSL, SSL and TLS, SSTP, TLS, user tunnel, VPN, Windows 10, XML
Tagged , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on August 26, 2019

https://directaccess.richardhicks.com/2019/08/26/always-on-vpn-with-azure-gateway/

Always On VPN and RRAS with Single NIC

Always On VPN and RRAS with Single NICI’m commonly asked “can Windows Server with Routing and Remote Access Service (RRAS) be configured with a single network interface?” This is likely because the official Microsoft documentation references only a multihomed dual NIC configuration, leading many to believe it is a strict requirement.

Single NIC

Deploying Windows Server RRAS with a single network interface is indeed supported and works without issue. There are no functional limitations imposed by using a single network interface. All features are fully supported in this scenario. The choice to use one or two network interfaces is purely a design choice, driven by several factors such as current network configuration and security requirements.

Dual NIC

Although a single NIC configuration is fully supported, there are some important advantages associated with mulithome dual NIC deployments. The following should be considered when deciding between single NIC and dual NIC VPN configurations.

Traffic Segmentation

Having separate internal and external network connections provides logical and physical separation of trusted and untrusted network traffic. Terminating connections from Always On VPN clients on the Internet in an isolated perimeter or DMZ network yields positive security benefits.

Firewall Configuration

Using two network interfaces allows for a more restrictive Windows Firewall policy to be applied to the external interface. This reduces the exposure of running services on the RRAS server to untrusted networks. This is especially critical if the VPN server is Windows Server RRAS and it is joined to a domain.

Network Performance

For very busy RRAS servers, having two network interfaces can improve network performance. With two network interfaces, network traffic is distributed between two network adapters, reducing utilization on each interface.

Dual NIC Best Practices

When deploying an RRAS server with dual NICs, the following recommendations for network interface configuration should be followed.

IP Addressing

Each network interface must be assigned an IP address from a unique subnet. Having both NICs on the same subnet is not supported.

Default Gateway

The default gateway should be configured on the external facing network interface only. The internal interface should not be configured with a gateway. Rather, static routes to any remote internal networks should be configured.

To add a static route on a Windows Server, open an elevated PowerShell command window and run the following command.

New-NetRoute -AddressFamily IPv4 -DestinationPrefix 10.0.0.0/8 -InterfaceAlias ‘Internal’ -NextHop 172.21.12.254

DNS

For domain-joined RRAS servers, corporate DNS servers should be configured on the Internal network interface only. No DNS servers should be configured on the external interface. If the server is not joined to a domain, DNS servers can be configured on whichever interface has connectivity to the defined DNS servers.

NAT

When the RRAS server is behind a device performing Network Address Translation (NAT), the NAT should be configured to translate only the destination address (DNAT). This allows the VPN server (or load balancer for multiserver deployments) to see the client’s original source IP address, which ensures efficient traffic distribution and meaningful log data.

Client, Service, and Protocol Bindings

All unnecessary clients, services, and protocols should be unbound from the external network interface. It is recommended that only the IPv4 and IPv6 protocols be enabled on the external interface, as shown here. Again, this reduces exposure for the server to the untrusted external network.

Always On VPN and RRAS with Single NIC

Summary

The dual NIC, multihomed configuration is generally recommended for most deployments as it offers security and performance advantages over the single NIC configuration. For organizations with less demanding security requirements, a single NIC deployment can be deployed safely without compromising functionality or supportability. In addition, a single NIC deployment may be the best option when multiple networks aren’t readily available.

Additional Information

Windows 10 Always On VPN and Windows Server Routing and Remote Access (RRAS)

Windows 10 Always On VPN Protocol Recommendations for Windows Server RRAS

Windows 10 Always On VPN Options for Azure Deployments

Windows 10 Always On VPN Hands On Training

75 Comments
by Richard M. Hicks on August 19, 2019  •  Permalink
Posted in Always On VPN, AOVPN, Enterprise, enterprise mobility, Mobility, PowerShell, Remote Access, routing and remote access service, RRAS, Security, VPN, Windows 10, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
Tagged , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on August 19, 2019

https://directaccess.richardhicks.com/2019/08/19/always-on-vpn-and-rras-with-single-nic/

« Older Posts