All posts tagged Microsoft Azure

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

Always On VPN Device Tunnel and Custom Cryptography Native Support Now in Intune

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?

Leave a comment
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
Tagged , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

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 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/

Deploying NetMotion Mobility in Azure

NetMotion MobilityOne of the many advantages NetMotion Mobility offers is that it requires no proprietary hardware to deliver its advanced capabilities and performance. It is a software solution that can be installed on any physical or virtual Windows server. This provides great deployment flexibility by allowing administrators to deploy this remote access solution on their existing virtual infrastructure, which is much less costly than investing in dedicated hardware or virtual appliances.

Cloud Deployment

As customers begin moving their traditional on-premises infrastructure to the cloud, it’s good to know that NetMotion Mobility is fully supported in popular public cloud platforms such as Microsoft Azure. Installing and configuring Mobility on a server in Azure requires a few important changes to a standard Azure VM deployment however. Below is detailed guidance for installing and configuring NetMotion Mobility on a Windows Server 2016 virtual machine hosted in the Microsoft Azure public cloud.

Azure Networking Configuration

Before installing the NetMotion Mobility software, follow the steps below to configure the Azure VM with a static public IP address and enable IP forwarding on the internal network interface.

  1. In the Azure management portal, select the NetMotion Mobility virtual machine and click Networking.
  2. Click on the public-facing network interface.
  3. In the Settings section click IP configurations.
  4. In the IP configurations section click on the IP configuration for the network interface.
  5. In the Public IP address setting section click Enabled for the Public IP address.
  6. Click Configure required settings for the IP address.
  7. Click Create New.
  8. Enter a descriptive name and select Static as the assignment method.
    Deploying NetMotion Mobility in Azure
  9. Click OK
  10. Click Save.Deploying NetMotion Mobility in AzureNote: The process of saving the network interface configuration takes a few minutes. Be patient!
  11. Note the public IP address, as this will be used later during the Mobility configuration.
  12. Close the IP address configuration blade.
  13. In the IP forwarding settings section click Enabled for IP forwarding.Deploying NetMotion Mobility in Azure
  14. Click Save.

NetMotion Mobility Installation

Proceed with the installation of NetMotion Mobility. When prompted for the external address, enter the public IP address created previously.

Deploying NetMotion Mobility in Azure

Next choose the option to Use pool of virtual IP addresses. Click Add and enter the starting and ending IP addresses, subnet prefix length, and default gateway and click OK.

Deploying NetMotion Mobility in Azure

Complete the remaining NetMotion Mobility configuration as required.

Azure Routing Table

A user defined routing table must be configured to ensure that NetMotion Mobility client traffic is routed correctly in Azure. Follow the steps below to complete the configuration.

  1. In the Azure management portal click New.
  2. In the Search the Marketplace field enter route table.
  3. In the results section click Route table.
  4. Click Create.
  5. Enter a descriptive name and select a subscription, resource group, and location.
  6. Click Create.

Deploying NetMotion Mobility in Azure

Once the deployment has completed successfully, click Go to resource in the notifications list.

Deploying NetMotion Mobility in Azure

Follow the steps below to add a route to the route table.

  1. In the Settings sections click Routes.
  2. Click Add.
  3. Enter a descriptive name.
  4. In the Address prefix field enter the subnet used by mobility clients defined earlier.
  5. Select Virtual appliance as the Next hop type.
  6. Enter the IP address of the NetMotion Mobility server’s internal network interface.
  7. Click OK.Deploying NetMotion Mobility in Azure
  8. Click Subnets.
  9. Click Associate.
  10. Click Choose a virtual network and select the network where the NetMotion Mobility gateway resides.
  11. Click Choose a subnet and select the subnet where the NetMotion Mobility gateway’s internal network interface resides.
  12. Click OK.

Note: If clients connecting to the NetMotion Mobility server need to access resources on-premises via a site-to-site gateway, be sure to associate the route table with the Azure gateway subnet.

Azure Network Security Group

A network security group must be configured to allow inbound UDP port 5008 to allow external clients to reach the NetMotion Mobility gateway server. Follow the steps below to create and assign a network security group.

  1. In the Azure management portal click New.
  2. In the Search the Marketplace field enter network security group.
  3. In the results section click Network security group.
  4. Click Create.
  5. Enter a descriptive name and select a subscription, resource group, and location.
  6. Click Create.

Deploying NetMotion Mobility in Azure

Once the deployment has completed successfully, click Go to resource in the notifications list.

Deploying NetMotion Mobility in Azure

Follow the steps below to configure the network security group.

  1. In the Settings section click Inbound security rules.
  2. Click Add.
  3. Enter 5008 in the Destination port ranges field.
  4. Select UDP for the protocol.
  5. Select Allow for the action.
  6. Enter a descriptive name.
  7. Click OK.
    Deploying NetMotion Mobility in Azure
  8. Click Network Interfaces.
  9. Click Associate.
  10. Select the external network interface of the NetMotion Mobility gateway server.

Summary

After completing the steps above, install the client software and configure it to use the static public IP address created previously. Alternatively, configure a DNS record to point to the public IP address and specify the Fully Qualified Domain Name (FQDN) instead of the IP address itself.

Additional Resources

Enabling Secure Remote Administration for the NetMotion Mobility Console

NetMotion Mobility Device Tunnel Configuration

NetMotion Mobility as an Alternative to Microsoft DirectAccess

NetMotion Mobility and Microsoft DirectAccess Comparison Whitepaper

NetMotion and Microsoft DirectAccess On-Demand Webinar

10 Comments
by Richard M. Hicks on February 8, 2018  •  Permalink
Posted in Azure, cloud, NetMotion, NetMotion Mobility, Remote Access, Security, VPN, Windows 10, Windows Server 2016
Tagged , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on February 8, 2018

https://directaccess.richardhicks.com/2018/02/08/deploying-netmotion-mobility-in-azure/

« Older Posts