All posts tagged security

NetMotion Mobility with Microsoft Endpoint Manager and Intune

NetMotion Mobility with Microsoft Endpoint Manager and IntuneNetMotion Software and Microsoft have now partnered to integrate NetMotion Mobility with Microsoft Endpoint Manager and Intune. NetMotion Mobility is a purpose-built enterprise VPN solution that has many advantages over competing remote access technologies. Using Microsoft Endpoint Manager or Intune, organizations can now quickly and easily provision NetMotion client software to their managed devices.

NetMotion Mobility

NetMotion Mobility is a popular remote access solution designed to meet the needs of enterprise organization with diverse mobility requirements. NetMotion Mobility uses a proprietary transport protocol that, unlike any other solution, is designed for mobility from inception. It includes many advanced features not found anywhere else. You can learn more about NetMotion Mobility here.

Comparing DirectAccess and NetMotion Mobility

Endpoint Manager and Intune

More information about the NetMotion Software and Microsoft Endpoint Manager and Intune partnership here.

Additional Information

5 Things NetMotion Mobility Can Do that Microsoft DirectAccess Can’t
5 Things NetMotion Mobility Can Do that Microsoft Windows 10 Always On VPN Can’t
Comparing NetMotion Mobility and Microsoft DirectAccess

Evaluate NetMotion Mobility

Interested in learning more about NetMotion Mobility? Complete the form below and I’ll provide you with more information.

2 Comments
by Richard M. Hicks on March 11, 2020  •  Permalink
Posted in Always On VPN, AOVPN, DirectAccess, Enterprise, enterprise mobility, MEMCM, Microsoft Endpoint Manager, Microsoft Intune, Mobility, NetMotion, NetMotion Mobility, NetMotion Software, Operational Support, Security, VPN, Windows 10, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
Tagged , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on March 11, 2020

https://directaccess.richardhicks.com/2020/03/11/netmotion-mobility-with-microsoft-endpoint-manager-and-intune/

Always On VPN IKEv2 Load Balancing with Citrix NetScaler ADC

Always On VPN SSTP Load Balancing with Citrix NetScaler ADCThe Internet Key Exchange version 2 (IKEv2) VPN protocol is the protocol of choice when the highest level of security is required for Always On VPN connections. It uses IPsec and features configurable security parameters that allow administrators to adjust policies to meet their specific security requirements. IKEv2 is not without some important limitations, but organizations may insist on the use of IKEv2 to provide the greatest protection possible for remote connected clients. Due to complexities of the IKEv2 transport, special configuration on the Citrix ADC is required when load balancing this workload.

Special Note: In December 2019 a serious security vulnerability was discovered on the Citrix ADC that gives an unauthenticated attacker the ability to arbitrarily execute code on the appliance. As of this writing a fix is not available (due end of January 2020) but a temporary workaround can be found here.

Load Balancing IKEv2

When an Always On VPN client establishes a connection using IKEv2, communication begins on UDP port 500, but switches to UDP port 4500 if Network Address Translation (NAT) is detected in the communication path between the client and the server. Because UDP is connectionless, custom configuration is required to ensure that VPN clients maintain connectivity to the same backend VPN server during this transition.

Initial Configuration

Load balancing IKEv2 using the Citrix ADC is similar to other workloads. Below are specific settings and parameters required to load balance IKEv2 using the Citrix ADC.

Note: This article is not a comprehensive configuration guide for the Citrix ADC. It assumes the administrator is familiar with basic load balancing concepts and has experience configuring the Citrix ADC.

Service Settings

The load balancing services for IKEv2 VPN will use UDP ports 500 and 4500. Create the service group and assign group members for UDP 500 as follows.

Always On VPN IKEv2 Load Balancing with Citrix NetScaler ADC

Always On VPN IKEv2 Load Balancing with Citrix NetScaler ADC

Repeat the steps above to create the service group for UDP port 4500.

Virtual Server Settings

Two virtual servers are required, one for UDP port 500 and one for UDP port 4500. Ensure that the service group using UDP port 500 is bound to the virtual server using the same port.

Always On VPN IKEv2 Load Balancing with Citrix NetScaler ADC

Always On VPN IKEv2 Load Balancing with Citrix NetScaler ADC

Repeat the steps above to create the virtual service for UDP port 4500.

Service Monitoring

Since IKEv2 uses the UDP protocol, the only option for service monitoring is to use PING, which is configured by default. Ensure that the firewall on the VPN server allows inbound ICMPv4 and ICMPv6 Echo Request. The default PING monitor on the Citrix ADC will ping the resource every 5 seconds. If a different interval is required, the administrator can edit the PING monitor and bind that to the service or service group as necessary.

Persistency Group

A Persistency Group on the Citrix ADC will be configured to ensure that IKEv2 VPN client requests from the same client are always routed to the same backend server. Follow the steps below to create a Persistency Group and assign it to both IKEv2 virtual servers created previously.

1. In the Citrix ADC management console expand Traffic Management > Load Balancing > Persistency Groups.
2. Click Add.
3. Enter a descriptive name for the Persistency Group.
4. Select SOURCEIP from the Persistence drop-down list.
5. Next to the Virtual Server Name section click the Add button.
6. Add both previously configured IKEv2 virtual servers for UDP 500 and 4500.
7. Click Create.

Always On VPN IKEv2 Load Balancing with Citrix NetScaler ADC

Additional Information

Windows 10 Always On VPN SSTP Load Balancing with Citrix NetScaler ADC

Windows 10 Always On VPN IKEv2 Features and Limitations

Windows 10 AlWAYS On VPN and IKEv2 Fragmentation

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN Certificate Requirements for IKEv2

5 Comments
by Richard M. Hicks on January 20, 2020  •  Permalink
Posted in ADC, Always On VPN, AOVPN, application delivery controller, Citrix ADC, device tunnel, Enterprise, enterprise mobility, High Availability, IKEv2, Load Balancing, Mobility, Netscaler, Remote Access, routing and remote access service, RRAS, Security, user tunnel, VPN, Windows 10, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
Tagged , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on January 20, 2020

https://directaccess.richardhicks.com/2020/01/20/always-on-vpn-ikev2-load-balancing-with-citrix-netscaler-adc/

Always On VPN SSTP Load Balancing with Citrix NetScaler ADC

Always On VPN SSTP Load Balancing with Citrix NetScaler ADCOne of the many advantages of using Windows Server Routing and Remote Access Service (RRAS) as the VPN server to support Windows 10 Always On VPN connections is that it includes support for the Secure Socket Tunneling Protocol (SSTP). SSTP is a TLS-based VPN protocol that is easy to configure and deploy and is very firewall friendly. This ensures consistent and reliable connectivity even behind restrictive firewalls. The Citrix Application Delivery Controller (ADC), formerly known as NetScaler, is a popular platform for load balancing Always On VPN connections. In this article I’ll describe how to configure load balancing on the Citrix ADC for RRAS VPN connections using the SSTP VPN protocol.

Special Note: In December 2019 a serious security vulnerability was discovered on the Citrix ADC that gives an unauthenticated attacker the ability to arbitrarily execute code on the appliance. As of this writing a fix is not available (due end of January 2020) but a temporary workaround can be found here.

Load Balancing SSTP

Previously I’ve written about some of the use cases and benefits of SSTP load balancing as well as the options for offloading TLS for SSTP VPN connections. Load balancing SSTP eliminates single points of failure and enables support for multiple RRAS VPN servers to increase scalability. It is generally recommended that the Citrix ADC be configured to pass through encrypted SSTP VPN connections. However, TLS offloading can be configured to improve performance and reduce resource utilization on VPN servers, if required.

Configuration

Load balancing SSTP on the Citrix ADC is straightforward and not unlike load balancing a common HTTPS web server. Below are specific settings and parameters required to load balance SSTP using the Citrix ADC.

Note: This article is not a comprehensive configuration guide for the Citrix ADC. It assumes the administrator is familiar with basic load balancing concepts and has experience configuring the Citrix ADC.

Service Settings

The load balancing service for SSTP VPN should be configured to use TCP port 443 and the SSL_BRIDGE protocol. If TLS offload is required, TCP port 80 and the HTTP protocol can be configured. Additional configuration is required on the RRAS server when TLS offload is enabled, however. Detailed information for configuring RRAS and SSTP for TLS offload can be found here.

Always On VPN SSTP Load Balancing with Citrix NetScaler ADC

Virtual Server Settings

The virtual server is configured to use TCP port 443. It is recommended to use SSLSESSION persistence.

Always On VPN SSTP Load Balancing with Citrix NetScaler ADC

The LEASTCONNECTION load balancing method is the recommend option for load balancing method.

Always On VPN SSTP Load Balancing with Citrix NetScaler ADC

Service Monitoring

Using the default TCP monitor (tcp-default) is not recommended for monitoring SSTP, as a simple TCP port check does not accurately reflect the health of the SSTP service running on the RRAS server. To more precisely monitor the SSTP service status, a new custom monitor must be created and bound to the load balancing services. Follow the steps below to configure a custom SSTP VPN monitor on the Citrix ADC.

  1. Open the Citrix ADC management console and expand Traffic Management.
  2. Select Monitors.
  3. Click Add.
  4. Enter a descriptive name in the Name field.
  5. Select HTTP form the Type drop-down list and click Select.
  6. Adjust the Interval and Response Time-out values according to your requirements.
  7. Enter 401 in the Response Codes field and click the “+” button.
  8. In the Response Codes field click the “x” next to 200.
  9. In the HTTP Request field enter HEAD /sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/.
  10. Check the box next to Secure (not required if TLS offload is enabled).
  11. Select ns_default_ssl_profile_backend from the SSL profile drop-down list (not required if TLS offload is enabled).
  12. Click Create.

Always On VPN SSTP Load Balancing with Citrix NetScaler ADC

Once complete, bind the new service monitor to the load balancing services or service groups accordingly.

TLS Offload

It is generally recommended that TLS offload not be enabled for SSTP VPN. However, if TLS offload is desired, it is configured in much the same way as a common HTTPS web server. Specific guidance for enabling TLS offload on the Citrix ADC can be found here. Details for configuring RRAS and SSTP to support TLS offload can be found here.

Certificates

When enabling TLS offload for SSTP VPN connections it is recommended that the public SSL certificate be installed on the RRAS server, even though TLS processing will be handled on the Citrix ADC and HTTP will be used between the Citrix ADC and the RRAS server. If installing the public SSL certificate on the RRAS server is not an option, additional configuration will be required. Specifically, TLS offload for SSTP must be configured using the Enable-SSTPOffload.ps1 PowerShell script, which can be found here.

Once the script has been downloaded, open an elevated PowerShell command window and enter the following command.

.\Enable-SSTPOffload.ps1 -CertificateHash [SHA256 Certificate Hash of Public SSL Certificate] -Restart

Example:

.\Enable-SSTPOffload.ps1 -CertificateHash ‘C3AB8FF13720E8AD9047DD39466B3C8974E592C2FA383D4A3960714CAEF0C4F2’ -Restart

Re-Encryption

When offloading TLS for SSTP VPN connections, all traffic between the Citrix ADC and the RRAS server will be sent in the clear using HTTP. In some instances, TLS offload is required only for traffic inspection, not performance gain. In this scenario the Citrix ADC will be configured to terminate and then re-encrypt connections to the RRAS server. When terminating TLS on the Citrix ADC and re-encrypting connections to the RRAS server is required, the same certificate must be used on both the Citrix ADC and the RRAS server. Using different certificates on the RRAS server and the load balancer is not supported.

Additional Information

Windows 10 Always On VPN Load Balancing and SSL Offload

SSL Offload Configuration for Citrix ADC (NetScaler)

Windows 10 Always On VPN SSTP Load Balancing with Kemp LoadMaster

Windows 10 Always On VPN SSTP Load Balancing with F5 BIG-IP

Windows 10 Always On VPN Connects then Disconnects

Windows 10 Always On VPN SSL Certificate Requirements for SSTP

3 Comments
by Richard M. Hicks on January 13, 2020  •  Permalink
Posted in ADC, Always On VPN, AOVPN, application delivery controller, certificates, Citrix ADC, Enterprise, enterprise mobility, High Availability, Load Balancing, Mobility, Netscaler, Remote Access, routing and remote access service, RRAS, Secure Socket Tunneling Protocol, Security, SSL, SSL and TLS, SSTP, TLS, VPN, Windows 10, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
Tagged , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on January 13, 2020

https://directaccess.richardhicks.com/2020/01/13/always-on-vpn-sstp-load-balancing-with-citrix-netscaler-adc/

Always On VPN Hands On Training in 2020

The calendar of events for our Windows 10 Always On VPN hands-on training classes is now available!

2020 Training Calendar

This year we will be making the following stops.

  • March 3-5 – Denver, CO
  • April 14-16 – New York, NY
  • June 15-15 – Bern, Switzerland (hosted by RealStuff – register here!)
  • August 18-20 – Honolulu, HI
  • October 6-8 – Washington D.C.
  • December 1-3 – San Diego, CA

Always On VPN Hands-On Training

Comprehensive Training

My Windows 10 Always On VPN hands-on training classes will cover all aspects of designing, implementing, and supporting an Always On VPN solution in the enterprise. This three-day course will cover topics such as…

  • Windows 10 Always On VPN overview
  • Introduction to CSP
  • Infrastructure requirements
  • Planning and design considerations
  • Installation, configuration, and client provisioning

Advanced topics will include…

  • Redundancy and high availability
  • Cloud-based deployments
  • Third-party VPN infrastructure and client support
  • Multifactor authentication
  • Always On VPN migration strategies

Windows 10 Always On VPN Hands-On Training Classes for 2018

Register Today

Space is limited, so register now to reserve your spot in one of our Always On VPN hands-on training classes. Hope to see you there!

Always On VPN Hands-On Training

Leave a comment
by Richard M. Hicks on January 1, 2020  •  Permalink
Posted in Always On VPN, AOVPN, DirectAccess, DirectAccess Deprecated, DirectAccess End of Life, DirectAccess EOL, education, Enterprise, enterprise mobility, learning, Mobility, Remote Access, Security, VPN, Windows 10, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
Tagged , , , , , , , ,

Posted by Richard M. Hicks on January 1, 2020

https://directaccess.richardhicks.com/2020/01/01/always-on-vpn-hands-on-training-in-2020/

Microsoft Intune NDES Connector Setup Wizard Ended Prematurely

Microsoft Intune NDES Connector Setup Wizard Ended PrematurelyA Windows Server with the Network Device Enrollment Service (NDES) role can be provisioned on-premises to support certificate deployment for non-domain Windows 10 Always On VPN clients. In addition, the Microsoft Intune Connector must be installed and configured on the NDES server to allow Intune-managed clients to request and receive certificates from the on-premises Certification Authority (CA) server.

Setup Wizard Ended Prematurely

When installing the Microsoft Intune Connector, the administrator may encounter a scenario where the setup wizard fails with the following error message.

“Microsoft Intune Connector Setup Wizard ended prematurely because of an error. Your system has not been modified. To install this program at a later time, run Setup Wizard again. Click the Finish button to exit the Setup Wizard.”

Microsoft Intune NDES Connector Setup Wizard Ended Prematurely

Cryptographic Service Provider

This error can occur if the NDES server certificate template is configured to use the Key Storage Provider cryptography service provider (CSP). When configuring the certificate template for the NDES server, the Legacy Cryptography Service Provider must be used, as shown here.

Microsoft Intune NDES Connector Setup Wizard Ended Prematurely

Additional Information

Deploying Windows 10 Always On VPN with Intune using Custom ProfileXML

Windows 10 Always On VPN Device Tunnel Configuration using Microsoft Intune

Deploying Windows 10 Always On VPN with Microsoft Intune

 

6 Comments
by Richard M. Hicks on November 11, 2019  •  Permalink
Posted in Always On VPN, AOVPN, authentication, Azure, certificates, cloud, Encryption, Enterprise, enterprise mobility, InTune, Microsoft Intune, Mobility, NDES, Network Device Enrollment Service, Network Device Enrollment Services, PKI, public cloud, public key infrastructure, Remote Access, Security, systems management, troubleshooting, user tunnel, VPN, Windows 10, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
Tagged , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on November 11, 2019

https://directaccess.richardhicks.com/2019/11/11/microsoft-intune-ndes-connector-setup-wizard-ended-prematurely/

Always On VPN IKEv2 Policy Mismatch Error

Always On VPN IKEv2 Policy Mismatch ErrorThe Internet Key Exchange version 2 (IKEv2) VPN protocol is the protocol of choice for Windows 10 Always On VPN deployments where the highest levels of security and assurance are required. However, as I’ve written about in the past, often the default IKEv2 security settings are less than desirable. Before using IKEv2 VPN in a production environment the administrator will need to update these security settings accordingly.

Connection Failure

When configuring Windows Server Routing and Remote Access Service (RRAS) or a third-party VPN appliance to support IKEv2 using custom security policies, the administrator may encounter a scenario in which a connection cannot be established due to a policy mismatch error. When the connection attempt fails, an error will be recorded in the Windows Application event log from the RasClient source with Event ID 20227. The error message states the following:

“The user [username] dialed a connection named [connection name] which has failed. The error code returned on failure is 13868.”

Always On VPN IKEv2 Policy Mismatch Error

Error Code 13868

Error code 13868 translates to ERROR_IPSEC_IKE_POLICY_MATCH. Essentially this error indicates that the IKEv2 security policy on the client did not match the configuration on the server.

Server Configuration

To view the current IKEv2 IPsec policy configuration, open an elevated PowerShell command window and run the following command.

Get-VpnServerIPsecConfiguration

Always On VPN IKEv2 Policy Mismatch Error

Client Configuration

To ensure interoperability, the VPN client must be configured to use the same IKEv2 security policy as defined on the sever. To view a VPN client’s currently configured IKEv2 security policy, open an elevated PowerShell command window and run the following command.

Get-VpnConnection -Name [connection name] | Select-Object -ExpandProperty IPsecCustomPolicy

Always On VPN IKEv2 Policy Mismatch Error

Note: If this PowerShell command returns no output, the VPN connection is not using a custom IKEv2 IPsec security policy.

Updating Settings

Guidance for configuring IKEv2 security policies on Windows Server RRAS and Windows 10 can be found here.

Summary

IKEv2 policy mismatch errors can be resolved easily by ensuring both the VPN server and client are configured to use the same IPsec security policies. Use the PowerShell commands in the above referenced above to validate settings and make changes when necessary.

Additional Information

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN IKEv2 Features and Limitations

Show-VpnConnectionIPsecConfiguration PowerShell script on Github

Set-IKEv2SecurityBaseline PowerShell script on Github

8 Comments
by Richard M. Hicks on September 2, 2019  •  Permalink
Posted in Always On VPN, AOVPN, device tunnel, Enterprise, enterprise mobility, GitHub, IKEv2, Mobility, PowerShell, ProfileXML, Remote Access, routing and remote access service, RRAS, Security, user tunnel, VPN, Windows 10, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
Tagged , , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on September 2, 2019

https://directaccess.richardhicks.com/2019/09/02/always-on-vpn-ikev2-policy-mismatch-error/

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 PFS2048

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

 

 

 

33 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 Options for Azure Deployments

Always On VPN Options for Azure DeploymentsOrganizations everywhere are rapidly adopting Microsoft Azure public cloud infrastructure to extend or replace their existing datacenter. As traditional on-premises workloads are migrated to the cloud, customers are looking for options to host VPN services there as well.

Windows Server

Windows Server with the Routing and Remote Access Service (RRAS) installed is a popular choice for on-premises Always On VPN deployments. Intuitively it would make sense to deploy Windows Server and RRAS in Azure as well. However, at the time of this writing, RRAS is not a supported workload on Windows Server in Azure.

Always On VPN Options for Azure Deployments

Reference: https://support.microsoft.com/en-us/help/2721672/microsoft-server-software-support-for-microsoft-azure-virtual-machines/

Although explicitly unsupported, it is possible to deploy Windows Server and RRAS in Azure for Always On VPN. In my experience it works well and can be an option for organizations willing to forgo formal support by Microsoft.

Azure Gateway

Options for supporting Always On VPN connections using native Azure VPN infrastructure depend on the type of VPN gateway chosen.

VPN Gateway

The Azure VPN Gateway can be configured to support client-based (point-to-site) VPN. With some additional configuration it can be used to support Windows 10 Always On VPN deployments. Azure VPN gateway supports both IKEv2 and SSTP VPN protocols for client connections. The Azure VPN gateway has some limitations though. Consider the following:

  • A route-based VPN gateway is required
  • A maximum of 1000 concurrent IKEv2 connections are supported when using the VpnGw3 or VpnGw3AZ SKUs (2000 supported in active/active mode)
  • A maximum of 128 concurrent SSTP connections are supported on all gateway SKUs (256 supported in active/active mode)

Virtual WAN

Azure Virtual WAN is the future of remote connectivity for Azure. It includes support for client-based VPN (currently in public preview at the time of this writing), but only supports IKEv2 and OpenVPN VPN protocols for client connections. SSTP is not supported at all. Further, OpenVPN is not supported for Windows 10 Always On VPN, leaving IKEv2 as the only option, which poses some potential operational challenges. Virtual WAN offer much better scalability though, supporting up to 10,000 concurrent client-based VPN connections.

Virtual Appliance

The most supportable option for hosting VPN services in Azure for Windows 10 Always On VPN is to deploy a third-party Network Virtual Appliance (NVA). They are available from a variety of vendors including Cisco, Check Point, Palo Alto Networks, Fortinet, and many others. To support Windows 10 Always On VPN, the NVA vendor must either support IKEv2 for client-based VPN connections or have a Universal Windows Platform (UWP) VPN plug-in client available from the Microsoft store. Click here to learn more about Always On VPN and third-party VPN devices.

Note: Be careful when choosing an NVA as some vendors support IKEv2 only for site-to-site VPN, but not client-based VPN!

Hybrid Deployments

For organizations with hybrid cloud deployments (infrastructure hosted on-premises and in Azure), there are several options for choosing the best location to deploy VPN services. In general, it is recommended that client VPN connections be established nearest the resources accessed by remote clients. However, having VPN servers hosted both on-premises and in Azure is fully supported. In this scenario Azure Traffic Manager can be configured to intelligently route VPN connections for remote clients.

NetMotion Mobility

The NetMotion Mobility purpose-built enterprise VPN is a popular replacement for Microsoft DirectAccess. It is also an excellent alternative for enterprise organizations considering a migration to Always On VPN. It is a software-based solution that can be deployed on Windows Server and is fully supported running in Microsoft Azure. It offers many advanced features and capabilities not included in other remote access solutions.

Summary

Administrators have many options for deploying VPN servers in Azure to support Windows 10 Always On VPN. Windows Server and RRAS is the simplest and most cost-effective option, but it is not formally supported by Microsoft. Azure VPN gateway is an interesting alternative but lacks enough capacity for larger deployments. Azure Virtual WAN is another option but has limited protocol support. Deploying an NVA is a good choice, and NetMotion Mobility is an excellent alternative to both DirectAccess and Always On VPN that is software-based and fully supported in Azure.

Additional Information

Windows 10 Always On VPN with Azure Gateway

Windows 10 Always On VPN and Third-Party VPN Devices

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

Windows 10 Always On VPN IKEv2 Features and Limitations

Windows 10 Always On VPN Multisite with Azure Traffic Manager

Comparing DirectAccess and NetMotion Mobility

Deploying NetMotion Mobility in Microsoft Azure

 

 

20 Comments
by Richard M. Hicks on June 24, 2019  •  Permalink
Posted in Always On VPN, AOVPN, Azure, Azure Virtual WAN, Azure VPN, Azure VPN Gateway, cloud, DirectAccess, DirectAccess Deprecated, DirectAccess End of Life, DirectAccess EOL, end of life, Enterprise, enterprise mobility, IKEv2, Mobility, NetMotion, NetMotion Mobility, OpenVPN, public cloud, Remote Access, routing and remote access service, RRAS, Security, SSTP, VPN, Windows 10, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
Tagged , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on June 24, 2019

https://directaccess.richardhicks.com/2019/06/24/always-on-vpn-options-for-azure-deployments/

Always On VPN Device Tunnel and Certificate Revocation

Always On VPN Device Tunnel and Certificate RevocationRecently I wrote about denying access to Windows 10 Always On VPN users or computers. In that post I provided specific guidance for denying access to computers configured with the device tunnel. To summarize, the process involved exporting the device certificate from the issuing Certification Authority (CA) server and placing it in the Untrusted Certificates certificate store on each VPN server. In theory, simply revoking the device certificate should be all that’s required to prevent device tunnel connections.

Revocation Check Failure

As it turns out, a bug in Windows Server Routing and Remote Access prevents this from working as expected. Windows Server 2012 R2, 2016, and 2019 all fail to check the Certificate Revocation List (CRL) for IKEv2 VPN connections using machine certificate authentication (for example an Always On VPN device tunnel).

Updates for Windows Server

Microsoft has released fixes to support device tunnel certificate revocation for the following operating systems.

Windows Server 2019 – KB4505658 (build 17763.652)

Windows Server 2016 – KB4503294 (build 14393.3053)

Windows Server 2012/R2 – Will not be updated.

Enable Revocation Check

Additional configuration is required to enable support for CRL checking. Microsoft published guidance for configuring CRL revocation checks for IKEv2 VPN connections using machine certificate authentication here. Specifically, administrators must enable the RootCertificateNameToAccept parameter and set a registry key to enable this functionality.

Open an elevated PowerShell window and run the following commands to enable CRL checking for IKEv2 VPN connections using machine certificate authentication.

$Thumbprint = ‘Root CA Certificate Thumbprint’
$RootCACert = (Get-ChildItem -Path cert:\LocalMachine\root | Where-Object {$_.Thumbprint -eq $Thumbprint})
Set-VpnAuthProtocol -RootCertificateNameToAccept $RootCACert -PassThru

New-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\Ikev2\’ -Name CertAuthFlags -PropertyTYpe DWORD -Value ‘4’ -Force

Restart-Service RemoteAccess -PassThru

Always On VPN Device Tunnel and Certificate Revocation

A PowerShell script to update the RootCertificateNameToAccept parameter on multiple VPN servers can be found here.

Revoking Certificates

To prevent a Windows 10 Always On VPN device tunnel connection, the administrator must first revoke the certificate on the issuing CA. Next, open an elevated command window an enter the following commands. Repeat these steps on each VPN server in the enterprise.

certutil -urlcache * delete
certutil -setreg chain\ChainCacheResyncFiletime @now

Additional Information

Denying Access to Windows 10 Always On VPN Users or Computers

Blocking VPN Clients that use Revoked Certificates

PowerShell Script to Configure RootCertificateNameToAccept on GitHub

 

 

15 Comments
by Richard M. Hicks on June 20, 2019  •  Permalink
Posted in Always On VPN, AOVPN, authentication, certificates, device tunnel, Encryption, Enterprise, enterprise mobility, GitHub, Hotfix, IKEv2, Mobility, PKI, PowerShell, Remote Access, routing and remote access service, RRAS, Security, VPN, Windows 10, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
Tagged , , , , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on June 20, 2019

https://directaccess.richardhicks.com/2019/06/20/always-on-vpn-device-tunnel-and-certificate-revocation/

Always On VPN SSTP Load Balancing with F5 BIG-IP

Always On VPN SSTP Load Balancing with F5 BIG-IP The Windows Server Routing and Remote Access Service (RRAS) includes support for the Secure Sockets Tunneling Protocol (SSTP), which is a Microsoft proprietary VPN protocol that uses SSL/TLS for security and privacy of VPN connections. The advantage of using SSTP for Always On VPN is that it is firewall friendly and ensures consistent remote connectivity even behind highly restrictive firewalls.

Load Balancing SSTP

In a recent post, I described some of the use cases and benefits of SSTP load balancing as well as the offloading of TLS for SSTP VPN connections. Using a load balancer for SSTP VPN connections increases scalability, and offloading TLS for SSTP reduces resource utilization and improves performance for VPN connections. There are positive security benefits too.

Configuration

Enabling load balancing for SSTP on the F5 BIG-IP platform is fundamentally similar to load balancing HTTPS web servers. However, there are a few subtle but important differences.

Default Monitor

The default HTTP and HTTPS monitors on the F5 will not accurately reflect the health of the SSTP service running on the RRAS server. In addition, using a simple TCP port monitor could yield unexpected results. To ensure accurate service status monitoring, a new custom monitor must be created to validate the health of the SSTP service.

Custom SSTP Monitor

Open the F5 BIG-IP management console and follow the steps below to create and assign a new custom monitor for SSTP.

Create Monitor

1. In the navigation tree highlight Local Traffic.
2. Click Monitors.
3. Click Create.

Always On VPN SSTP Load Balancing with F5 BIG-IP

4. Enter a descriptive name in the Name field and from the Type drop-down list choose HTTP if TLS offload is enabled, or HTTPS if it is not.
5. In the Send String field enter HEAD /sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/ HTTP/1.1\r\nHost:r\nConnection: Close\r\n\r\n.
6. In the Receive String field enter HTTP/1.1 401.
7. Click Finished.

Always On VPN SSTP Load Balancing with F5 BIG-IP

Assign Monitor

1. Below Local Traffic click Pools.
2. Click on the SSTP VPN server pool.
3. In the Health Monitors section select the SSTP VPN health monitor from the Available list and make it Active.
4. Click Update.

Always On VPN SSTP Load Balancing with F5 BIG-IP

CLI Configuration

If you prefer to configure the SSTP VPN monitor using the F5’s Command Line Interface (CLI), you can download the monitor configuration from my GitHub here.

TLS Offload

It is generally recommended that TLS offload not be enabled for SSTP VPN. However, if TLS offload is desired, it is configured in much the same way as a common HTTPS web server. Specific guidance for enabling TLS offload on the F5 BIG-IP can be found here. Details for configuring RRAS and SSTP to support TLS offload can be found here.

Certificates

When enabling TLS offload for SSTP VPN connections it is recommended that the public SSL certificate be installed on the RRAS server, even though TLS processing will be handled on the F5 and HTTP will be used between the F5 and the RRAS server. If installing the public SSL certificate on the RRAS server is not an option, additional configuration will be required. Specifically, TLS offload for SSTP must be configured using the Enable-SSTPOffload PowerShell script, which can be found here.

Once the script has been downloaded, open an elevated PowerShell command window and enter the following command.

Enable-SSTPOffload -CertificateHash [SHA256 Certificate Hash of Public SSL Certificate] -Restart

Example:

Enable-SSTPOffload -CertificateHash “C3AB8FF13720E8AD9047DD39466B3C8974E592C2FA383D4A3960714CAEF0C4F2” -Restart

Re-Encryption

When offloading TLS for SSTP VPN connections, all traffic between the F5 and the RRAS server will be sent in the clear using HTTP. In some instances, TLS offload is required only for traffic inspection, not performance gain. In this scenario the F5 will be configured to terminate and then re-encrypt connections to the RRAS server. When terminating TLS on the F5 and re-encrypting connections to the RRAS server is required, the same certificate must be used on both the F5 and the RRAS server. Using different certificates on the RRAS server and the load balancer is not supported.

Additional Information

Windows 10 Always On VPN SSTP Load Balancing and SSL Offload

Windows 10 Always On VPN SSL Certificate Requirements for SSTP

Windows 10 Always On VPN ECDSA SSL Certificate Request for SSTP

Windows 10 Always On VPN SSTP Connects then Disconnects

Windows 10 Always On VPN Load Balancing Deployment Guide for Kemp Load Balancers

 

4 Comments
by Richard M. Hicks on June 17, 2019  •  Permalink
Posted in ADC, Always On VPN, AOVPN, application delivery controller, BIG-IP, certificates, Encryption, Enterprise, enterprise mobility, F5, High Availability, Load Balancing, local traffic manager, LTM, Mobility, PowerShell, Remote Access, routing and remote access service, RRAS, Security, SSL, SSL and TLS, SSTP, TLS, VPN, Windows 10, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
Tagged , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on June 17, 2019

https://directaccess.richardhicks.com/2019/06/17/always-on-vpn-sstp-load-balancing-with-f5-big-ip/

« Older Posts
%d bloggers like this: