All posts tagged IKEv2

Always On VPN Updates for RRAS and IKEv2

Many users have reported connection stability issues using Windows Server 2019 Routing and Remote Access Service (RRAS) and the IKEv2 VPN protocol. Specifically, there have been reports of random disconnects for which the connection cannot be re-established for an extended period. At the same time, other VPN connections may work without issue.

KB5003703

Microsoft has identified an issue in RRAS where the RemoteAccess service enters DoS protection mode, limiting incoming IKEv2 connection attempts. They released an update on June 15 (OS Build 17763.2028) that addresses this issue. Previously, the only workaround was to restart the IKEEXT service, which was highly disruptive if performed during peak hours.

No More Files

In addition, this update includes another Always On VPN-related fix for Windows 10 1809 clients. An Always On VPN user tunnel connection may fail, with an error message stating, “There are no more files.” The problem can occur after an existing user’s certificate is automatically renewed.

Additional Information

Microsoft Update June 15, 2021 KB5003703 (OS Build 17763.2028)

15 Comments

by Richard M. Hicks on June 22, 2021 • Permalink

Posted in Always On VPN, AOVPN, enterprise mobility, Hotfix, IKEv2, Mobility, Operational Support, Remote Access, routing and remote access service, RRAS, Update, user tunnel, VPN, Windows 10, Windows Server 2019

Posted by Richard M. Hicks on June 22, 2021

https://directaccess.richardhicks.com/2021/06/22/always-on-vpn-updates-for-rras-and-ikev2/

Always On VPN IPsec Root Certificate Configuration Issue

When configuring a Windows Routing and Remote Access Service (RRAS) server to support Internet Key Exchange version 2 (IKEv2) VPN connections, it is essential for the administrator to define the root certification authority for which to accept IPsec security associations (SAs). Without defining this setting, the VPN server will accept a device certificate issued by any root certification authority defined in the Trusted Root Certification Authorities store. Details about configuring IKEv2 security and defining the root certification authority can be found here.

Multiple Root Certificates

Administrators may find that when they try to define a specific root certification authority, the setting may not be implemented as expected. This commonly occurs when there is more than one root certificate in the Trusted Root Certification Authorities store for the same PKI.

Certificate Selection

When running the PowerShell command Set-VpnAuthProtocol to define the root certification authority, PowerShell may ignore the administrator-defined certificate and choose a different one, as shown here. This will result in failed IPsec VPN connections from Windows 10 Always On VPN clients using IKEv2.

Certificate Publishing

This issue can occur when root certification authority certificates are published using Active Directory group policy. It appears that Windows prefers Active Directory group policy published certificates over those published directly in the Certification Authorities Container in Active Directory. To resolve this issue, remove any group policy objects that are publishing root certification authority certificates and ensure those root certificates are published in the Certification Authorities container in Active Directory.

PowerShell Script

A PowerShell script to configure this setting that can be found in my Always On VPN GitHub repository here. I have updated this script to validate the defined root certification authority certificate and warn the user if it does not match.

Additional Information

Set-Ikev2VpnRootCertificate.ps1 PowerShell script on GitHub

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN IKEv2 Load Balancing and NAT

Windows 10 Always On VPN IKEv2 Features and Limitations

Windows 10 Always On VPN IKEv2 Fragmentation

Windows 10 Always On VPN IKEv2 Certificate Requirements

Troubleshooting Always On VPN Error 691 and 812 – Part 3

When implementing Windows 10 Always On VPN, administrators may encounter errors 691 or 812 when establishing a VPN connection. There are several different configuration issues that will result in these errors. For example they may occur when TLS 1.0 has been disabled on the RRAS server when installed on servers prior to Windows Server 2016. It can also happen if a user’s Active Directory account is configured to deny dial-in access and the NPS server is not configured to ignore user account dial-in properties. Another scenario that can result in 691/812 errors is when the Active Directory security groups are configured as conditions on the Network Policy Server (NPS) Network Policy. See below for more details.

SSTP and Error 691

When attempting to establish an Always On VPN connection using the Secure Socket Tunneling Protocol (SSTP), administrators may encounter the following error message.

“The remote connection was denied because the user name and password combination you provided is not recognized, or the selected authentication protocol is not permitted on the remote access server.”

In addition, an error 691 with event ID 20227 from the RasClient source can be found in the Application event log on the client.

“The user <domain\user> dialed a connection named which has failed. The error code returned on failure is 691.”

IKEv2 and Error 812

When attempting to establish an Always On VPN connection using Internet Key Exchange version 2 (IKEv2), administrators may encounter the following error message.

“The connection as prevented because of a policy configured on your RAS/VPN server. Specifically, the authentication method used by the server to verify your username and password may not match the authentication method configured in your connection profile. Please contact the Administrator of the RAS server and notify them of this error.”

In addition, an error 812 with event ID 20227 from the RasClient source can be found in the Application event log on the client.

NPS Event Log

On the NPS server the administrator will find an entry in the application event log with event ID 6273 from the Microsoft Windows security auditing source and the Network Policy Server task category indicating the network policy server denied access to the user. Looking closely at this event log message shows Reason Code 48 and the following reason.

“The connection request did not match any configured network policy.”

Group Membership

As stated earlier, another scenario in which administrators will encounter errors 691 and/or 812 is when the Network Policy on the NPS server is configured incorrectly. Specifically, and administrator may wish to grant access to more than one group but intend for access to be granted to users who are a member of any of them. Conversely, they may wish to require access in all specified groups to gain access to the VPN. Configuring each of these conditions is subtly different, however.

Open the NPS management console on the NPS server and follow the steps below to configure user group conditions correctly for the following scenarios.

Any Group

1. Right-click the Always On VPN network policy and choose Properties.
2. Click on the Conditions tab.
3. Click the Add button.
4. Click User Groups.
5. Click Add.
6. Click Add Groups.
7. Enter the name of the group you want to grant access to.
8. Click Ok.
9. Repeat the steps 6-8 above to specify additional groups.

All Groups

1. Right-click the Always On VPN network policy and choose Properties.
2. Click on the Conditions tab.
3. Click the Add button.
4. Click User Groups.
5. Click Add.
6. Click Add Groups.
7. Enter the name of the group you want to grant access to.
8. Click Ok.
9. Repeat steps 3-8 above to specify additional groups (you must go back to the Add button on step 3!).

Additional Information

Troubleshooting Always On VPN Error 691 and 812 – Part 1

Troubleshooting Always On VPN Error 691 and 812 – Part 2

2 Comments

by Richard M. Hicks on July 29, 2020 • Permalink

Posted in administration, Always On VPN, AOVPN, Enterprise, enterprise mobility, IKEv2, Mobility, network policy server, NPS, Operational Support, Remote Access, Secure Socket Tunneling Protocol, SSTP, user tunnel, VPN, Windows 10, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019

Posted by Richard M. Hicks on July 29, 2020

https://directaccess.richardhicks.com/2020/07/29/troubleshooting-always-on-vpn-error-691-and-812-part-3/

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

Microsoft recently announced support for native Windows 10 Always On VPN device tunnel configuration in Intune. Previously administrators had to use the complicated and error-prone custom XML configuration to deploy the Windows 10 Always On VPN device tunnel to their clients. That is no longer required with this recent Intune update. In addition, administrators may now specify custom cryptography settings for IPsec Security Association (SA) parameters for IKEv2 for both device tunnel and user tunnel connections. This effectively eliminates the requirement to use custom ProfileXML for most deployment scenarios.

Device Tunnel Configuration in Intune

Follow the steps below to configure and deploy a Windows 10 Always On VPN device tunnel using the native Intune user interface.

Create Profile

1. Open the Microsoft Endpoint Manager admin center (devicemanagement.microsoft.com).
2. Navigate to Devices > Configuration Policies.
3. Click Create profile.
4. Choose Windows 10 and later from the Platform drop-down list.
5. Choose VPN from the Profile drop-down list.
6. Click Create.

Profile Settings

Proceed with the profile configuration as you would normally, providing the VPN connection name, VPN server name(s), and choosing the option to register IP addresses with internal DNS. Next use the following steps to define a device tunnel connection and specify custom cryptography for IPsec SA parameters for IKEv2.

Configure a Device Tunnel

1. Select IKEv2 from the Connection type drop-down list.
2. Click Enable in the Always On section.
3. Select Machine Certificates from the Authentication method section.
4. If the computer certificate is provisioned using Intune, select the client authentication certificate (not required if the computer certificate is provisioned using on-premises Active Directory).
5. Click Enable in the Device Tunnel section.

Define Custom Cryptography

Follow the steps below to implement minimum security baseline cryptography settings for IKEv2.

IKE Security Association Parameters

1. Select AES-128 from the Encryption algorithm drop-down list.
2. Select SHA2-256 from the Integrity check algorithm drop-down list.
3. Select 14 from the Diffie-Hellman group drop-down list.

Child Security Association Parameters

1. Select CBC-AES-128 from the Cipher transform algorithm drop-down list.
2. Select HMAC-SHA256-128 from the Authentication transform algorithm drop-down list.
3. Select 14 from the Perfect forward secrecy (pfs) group drop-down list.

Important Note: The IPsec security association parameters outlined above are the minimum recommend security baseline for IKEv2 and are compatible with all supported versions of Windows Server RRAS. It is recommended that authenticated cipher suites (GCM) be used whenever possible. However, GCM ciphers are not supported for encryption prior to Window Server 1803. Administrators should review these security settings and adjust the parameters to meet their specific security requirements.

Server Configuration

When defining custom cryptography settings for IKEv2 for device tunnel deployment, it is critical that the server be configured using identical parameters. Failure to use matching cryptography settings on the client and server will result in error code 13868, which indicates an IPsec policy mismatch.

A PowerShell script to configure IKEv2 security association parameter minimum security baselines on the RRAS server as outlined above can be found here. The commands to make these changes on the Azure VPN gateway can be found in this post.

Caveats

While Microsoft has made great strides to ensure better support for Always On VPN configuration using the native Intune UI, there are a few critical settings are still not supported. In these scenarios the administrator must deploy Always On VPN using custom XML, as described here and here.

Custom Cryptography

IKEv2 custom cryptography settings are only exposed when IKEv2 is selected as the connection type. It appears that defining custom cryptography settings for IKEv2 when the connection type is set to Automatic is not supported at this time. If you wish to specify the Automatic connection type and use custom cryptography settings for IKEv2 you will need to deploy the device tunnel using custom ProfileXML.

IPv6

IPv6 routing when configuring split tunneling for Always On VPN in Intune is not supported.

Additional Information

Windows 10 Always On VPN Policy Mismatch Error

Windows 10 Always On VPN Device Tunnel with Azure VPN Gateway

Windows 10 Always On VPN IKEv2 Load Balancing and NAT

Windows 10 Always On VPN IKEv2 Fragmentation

Windows 10 Always On VPN IKEv2 Security Configuration

15 Comments

by Richard M. Hicks on July 27, 2020 • Permalink

Posted in Always On VPN, AOVPN, cloud, Device Management, device tunnel, Enterprise, enterprise mobility, IKEv2, Manage Out, MEMCM, Microsoft Endpoint Manager, Microsoft Intune, Mobility, public cloud, Remote Access, Security, systems management, VPN, Windows 10

Tagged Always On VPN, Azure, cryptography, custom cryptography, device tunnel, enterprise mobility, IKEv2, InTune, IPsec, Microsoft, Microsoft Intune, Microsoft Windows, Mobility, security, VPN, VPN profile

Posted by Richard M. Hicks on July 27, 2020

https://directaccess.richardhicks.com/2020/07/27/always-on-vpn-device-tunnel-and-custom-cryptography-native-support-now-in-intune/

Always On VPN Bug in Windows 10 2004

While performing Always On VPN evaluation testing with the latest release of Windows 10 (2004), a bug was discovered that may result in failed VPN connections, but only under certain conditions. Specifically, the failure occurs when both the device tunnel and user tunnel are configured on the same client, and the user tunnel is configured to use IKEv2 exclusively.

Error 829

After upgrading to Windows 10 2004, and when the device tunnel and user tunnel are both deployed and the user tunnel is configured to use IKEv2, the administrator will notice that if the device tunnel connection is established, the user tunnel connects successfully but is then terminated abruptly with error code 829.

Note: This can happen in reverse if the user tunnel is established before the device tunnel for some reason. In this scenario the user tunnel would be connected but attempts to establish the device tunnel would result in failure.

Error 619

If the user tunnel connection is initiated using rasdial.exe or rasphone.exe, the error code returned is 619.

Workaround

The workaround for this issue is to either use a single tunnel, or if both user tunnel and device tunnel are required, configure the user tunnel to use the SSTP VPN protocol instead of IKEv2.

Additional Information

Windows 10 Always On VPN Device Tunnel Only Deployment Considerations

39 Comments

by Richard M. Hicks on June 25, 2020 • Permalink

Posted in Always On VPN, AOVPN, device tunnel, enterprise mobility, IKEv2, Mobility, Remote Access, Secure Socket Tunneling Protocol, SSTP, user tunnel, VPN, Windows 10

Tagged Always On VPN, bug, device tunnel, error 619, error 829, IKEv2, Microsoft, Mobility, RasClient 20226, Remote Access, user tunnel, VPN, Windows, Windows 10 2004, Windows10

Posted by Richard M. Hicks on June 25, 2020

https://directaccess.richardhicks.com/2020/06/25/always-on-vpn-bug-in-windows-10-2004/

Always On VPN IKEv2 Load Balancing and NAT

Over the last few weeks, I’ve worked with numerous organizations and individuals troubleshooting connectivity and performance issues associated with Windows 10 Always On VPN, and specifically connections using the Internet Key Exchange version 2 (IKEv2) VPN protocol. An issue that appears with some regularity is when Windows 10 clients fail to connect with error 809. In this scenario, the server will accept connections without issue for a period of time and then suddenly stop accepting requests. When this happens, existing connections continue to work without issue in most cases. Frequently this occurs with Windows Server Routing and Remote Access Service (RRAS) servers configured in a clustered array behind an External Load Balancer (ELB).

Network Address Translation

It is not uncommon to use Network Address Translation (NAT) when configuring Always On VPN. In fact, for most deployments the public IP address for the VPN server resides not on the VPN server, but on an edge firewall or load balancer connected directly to the Internet. The firewall/load balancer is then configured to translate the destination address to the private IP address assigned to the VPN server in the perimeter/DMZ or the internal network. This is known a Destination NAT (DNAT). Using this configuration, the client’s original source IP address is left intact. This configuration presents no issues for Always On VPN.

Source Address Translation

When troubleshooting these issues, the common denominator seems to be the use of Full NAT, which includes translating the source address in addition to the destination. This results in VPN client requests arriving at the VPN server as appearing not to come from the client’s original IP address, but the IP address of the network device (firewall or load balancer) that is translating the request. Full NAT may be explicitly configured by an administrator, or in the case of many load balancers, configured implicitly because the load balancer is effectively proxying the connection.

Known Issues

IKEv2 VPN connections use IPsec for encryption, and by default, Windows limits the number of IPsec Security Associations (SAs) coming from a single IP address. When a NAT device is performing destination/full NAT, the VPN server sees all inbound IKEv2 VPN requests as coming from the same IP address. When this happens, clients connecting using IKEv2 may fail to connect, most commonly when the server is under moderate to heavy load.

Resolution

The way to resolve this issue is to ensure that any load balancers or NAT devices are not translating the source address but are performing destination NAT only. The following is configuration guidance for F5, Citrix ADC (formerly NetScaler), and Kemp load balancers.

F5

On the F5 BIG-IP load balancer, navigate to the Properties > Configuration page of the IKEv2 UDP 500 virtual server and choose None from the Source Address Translation drop-down list. Repeat this step for the IKEv2 UDP 4500 virtual server.

Citrix ADC

On the Citrix ADC load balancer, navigate to System > Settings > Configure Modes and check the option to Use Subnet IP.

Next, navigate to Traffic Management > Load Balancing > Service Groups and select the IKEv2 UDP 500 service group. In the Settings section click edit and select Use Client IP. Repeat these steps for the IKEv2 UDP 4500 service group.

Kemp

On the Kemp LoadMaster load balancer, navigate to Virtual Services > View/Modify Services and click Modify on the IKEv2 UDP 500 virtual service. Expand Standard Options and select Transparency. Repeat this step for the IKEv2 UDP 4500 virtual service.

Caveat

Making the changes above may introduce routing issues in your environment. When configuring these settings, it may be necessary to configure the VPN server’s default gateway to use the load balancer to ensure proper routing. If this is not possible, consider implementing the workaround below.

Workaround

To fully resolve this issue the above changes should be made to ensure the VPN server can see the client’s original source IP address. If that’s not possible for any reason, the following registry key can be configured to increase the number of established SAs from a single IP address. Be advised this is only a partial workaround and may not fully eliminate failed IKEv2 connections. There are other settings in Windows that can prevent multiple connections from a single IP address which are not adjustable at this time.

To implement this registry change, open an elevated PowerShell command window on the RRAS server and run the following commands. Repeat these commands on all RRAS servers in the organization.

New-ItemProperty -Path ‘HKLM:SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters\’ -Name IkeNumEstablishedForInitialQuery -PropertyType DWORD -Value 50000 -Force

Restart-Service IKEEXT -Force -PassThru

Additional Information

IPsec Traffic May Be Blocked When A Computer is Behind a Load Balancer

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

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

Windows 10 Always On VPN IKEv2 Load Balancing with Kemp LoadMaster

72 Comments

by Richard M. Hicks on April 13, 2020 • Permalink

Posted by Richard M. Hicks on April 13, 2020

https://directaccess.richardhicks.com/2020/04/13/always-on-vpn-ikev2-load-balancing-and-nat/

Remote Access Questions and Answers Webinar Hosted by Kemp

Join me this Thursday, April 9 at 10:00AM EDT for a Remote Access Q&A session hosted by Kemp Technologies. During this free live webinar, I’ll be answering all your questions as they relate to enterprise mobility, remote access, scalability and performance, security, and much more. Topics are not limited to Kemp products at all, so feel free to join and ask me anything you like! Register now and submit your questions!

2 Comments

by Richard M. Hicks on April 7, 2020 • Permalink

Tagged Always On VPN, AOVPN, IKEv2, Kemp, load balancing, Microsoft, Mobility, QA, Remote Access, routing and remote access service, RRAS, security, SSTP, VPN, webinar, Windows 10, Windows Server 2019

Posted by Richard M. Hicks on April 7, 2020

https://directaccess.richardhicks.com/2020/04/07/remote-access-qa-webinar-hosted-by-kemp/

Always On VPN Device Tunnel Only Deployment Considerations

Recently I wrote about Windows 10 Always On VPN device tunnel operation and best practices, explaining its common uses cases and requirements, as well as sharing some detailed information about authentication, deployment recommendations, and best practices. I’m commonly asked if deploying Always On VPN using the device tunnel exclusively, as opposed to using it to supplement the user tunnel, is supported or recommended. I’ll address those topics in detail here.

Device Tunnel Only?

To start, yes, it is possible to deploy Windows 10 Always On VPN using only the device tunnel. In this scenario the administrator will configure full access to the network instead of limited access to domain infrastructure services and management servers.

Is It Recommended?

Generally, no. Remember, the device tunnel was designed with a specific purpose in mind, that being to provide pre-logon network connectivity to support scenarios such as logging on without cached credentials. Typically, the device tunnel is best used for its intended purpose, which is providing supplemental functionality to the user tunnel.

Deployment Considerations

The choice to implement Always On VPN using only the device tunnel is an interesting one. There are some potential advantages to this deployment model, but it is not without some serious limitations. Below I’ve listed some of the advantages and disadvantages to deploying the device tunnel alone for Windows 10 Always On VPN.

Advantages

Using the device tunnel alone does have some compelling advantages over the standard two tunnel (device tunnel/user tunnel) deployment model. Consider the following.

Single VPN Connection – Deploying the device tunnel alone means a single VPN connection to configure, deploy, and manage on the client. This also results in less concurrent connections and, importantly, less IP addresses to allocate and provision.
Reduced Infrastructure – The device tunnel is authenticated using only the device certificate. This certificate check is performed directly on the Windows Server Routing and Remote Access Service (RRAS) VPN server, eliminating the requirement to deploy Network Policy Server (NPS) servers for authentication.
User Transparency – The device tunnel does not appear in the modern Windows UI. The user will not see this connection if they click on the network icon in the notification area. In addition, they will not see the device tunnel connection in the settings app under Network & Internet > VPN. This prevents casual users from playing with the connection settings, and potentially deleting the connection entirely. It’s not that they can’t delete the device tunnel however, it’s just not as obvious.
Simplified Deployment – Deploying the device tunnel is less complicated than deploying the user tunnel. The device tunnel is provisioned once to the device and available to all users. This eliminates the complexity of having to deploy the user tunnel in each individual user’s profile.

Disadvantages

While there are some advantages to using the device tunnel by itself, this configuration is not without some serious limitations. Consider the following.

IKEv2 Only – The device tunnel uses the IKEv2 VPN protocol exclusively. It does not support SSTP. While IKEv2 is an excellent protocol in terms of security, it is commonly blocked by firewalls. This will prevent some users from accessing the network remotely depending on their location.
Limited OS Support – The device tunnel is only supported on Windows 10 Enterprise edition clients, and those clients must be joined to a domain. Arguably the device tunnel wouldn’t be necessary if the client isn’t domain joined, but some organizations have widely deployed Windows 10 Professional, which would then preclude them from being able to use the device tunnel.
Machine Certificate Authentication Only – The device tunnel is authenticated using only the certificate issued to the device. This means anyone who logs on to the device will have full access to the internal network. This may or may not be desirable, depending on individual requirements.
No Mutual Authentication – When the device tunnel is authenticated, the server performs authentication of the client, but the client does not authenticate the server. The lack of mutual authentication increases the risk of a man-in-the-middle attack.
CRL Checks Not Enforced – By default, RRAS does not perform certificate revocation checking for device tunnel connections. This means simply revoking a certificate won’t prevent the device from connecting. You’ll have to import the client’s device certificate into the Untrusted Certificates certificate store on each VPN server. Fortunately, there is a fix available to address this limitation, but it involves some additional configuration. See Always On VPN Device Tunnel and Certificate Revocation for more details.
No Support for Azure Conditional Access – Azure Conditional Access requires EAP authentication. However, the device tunnel does not use EAP but instead uses a simple device certificate check to authenticate the device.
No Support for Multifactor Authentication – As the device tunnel is authenticated by the RRAS VPN server directly and authentication requests are not sent to the NPS server, it is not possible to integrate MFA with the device tunnel.
Limited Connection Visibility – Since the device tunnel is designed for the device and not the user it does not appear in the list of active network connections in the Windows UI. There is no user-friendly connection status indicator, although the connection can be viewed using the classic network control panel applet (ncpa.cpl).

Summary

The choice to deploy Windows 10 Always On VPN using the device tunnel alone, or in conjunction with the user tunnel, is a design choice that administrators must make based on their individual requirements. Using the device tunnel alone is supported and works but has some serious drawbacks and limitations. The best experience will be found using the device tunnel as it was intended, as an optional component to provide pre-logon connectivity for an existing Always On VPN user tunnel.

Additional Information

Windows 10 Always On VPN Device Tunnel with Azure VPN Gateway

Windows 10 Always On VPN Device Tunnel and Certificate Revocation

Windows 10 Always On VPN Device Tunnel Configuration with Microsoft Intune

Windows 10 Always On VPN Device Tunnel Does Not Connect Automatically

Windows 10 Always On VPN Device Tunnel Missing in Windows 10 UI

Deleting a Windows 10 Always On VPN Device Tunnel

Windows 10 Always On VPN Device Tunnel Configuration using PowerShell

Windows 10 Always On VPN IKEv2 Features and Limitations

59 Comments

by Richard M. Hicks on April 6, 2020 • Permalink

Posted by Richard M. Hicks on April 6, 2020

https://directaccess.richardhicks.com/2020/04/06/always-on-vpn-device-tunnel-only-deployment-considerations/

Troubleshooting Always On VPN Error 691 and 812 – Part 2

A while back I wrote about troubleshooting and resolving Windows 10 Always On VPN errors 691 and 812. There are numerous issues that can result in these errors, and in that post I pointed out they can be caused by disabling TLS 1.0 on Windows Servers prior to Windows Server 2016. However, administrators may encounter a another scenario in which they receive errors 691 or 812 which is related to Active Directory user account configuration.

SSTP and Error 691

When attempting to establish an Always On VPN connection using the Secure Socket Tunneling Protocol (SSTP), administrators may encounter the following error message.

In addition, an error 691 with event ID 20227 from the RasClient source can be found in the Application event log on the client.

“The user <domain\user> dialed a connection named which has failed. The error code returned on failure is 691.”

IKEv2 and Error 812

When attempting to establish an Always On VPN connection using Internet Key Exchange version 2 (IKEv2), administrators may encounter the following error message.

In addition, an error 812 with event ID 20227 from the RasClient source can be found in the Application event log on the client.

NPS Event Log

“The Network Access Permission setting in the dial-in properties of the user account in Active Directory is set to Deny access to the user. To change the Network Access permission setting to either Allow access or Control access through NPS Network Policy, obtain the properties of the user account in Active Directory Users and Computers, click the Dial-in tab, and change Network Access Permission.”

Resolution

There are two options available to address this issue. The user account in Active Directory can be configured to grant access or allow access to be controlled via NPS network policy, or the NPS network policy can be configured to ignore user account dial-in properties.

User Account

Follow the steps below to change Network Access Permission on an individual user’s Active Directory account.

Open the Active Directory User and Computers (ADUC) management console (dsa.msc) and double-click the user’s account.
Select the Dial-in tab.
In the Network Access Permission section select the option to Allow access or Control access through NPS Network Policy.

Note: If you do not see the dial-in tab, open the ADUC console on a domain controller. The dial-in tab is not displayed when using the Remote Server Administration Tools (RSAT) for Windows clients.

Network Policy

Follow the steps below to configure NPS network policy to ignore user account dial-in properties.

Open the NPS management console (nps.msc) and double-click the Always On VPN network policy.
In the Access Permission section select Ignore user account dial-in properties.
Click Ok to save the changes.

Additional Information

Windows 10 Always On VPN Troubleshooting Error 691 and 812

1 Comment

by Richard M. Hicks on February 17, 2020 • Permalink

Posted in Always On VPN, AOVPN, Enterprise, enterprise mobility, IKEv2, Mobility, network policy server, NPS, Remote Access, routing and remote access service, RRAS, Security, troubleshooting, Windows 10, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019

Posted by Richard M. Hicks on February 17, 2020

https://directaccess.richardhicks.com/2020/02/17/troubleshooting-always-on-vpn-error-691-and-812-part-2/

Always On VPN IKEv2 Load Balancing with Citrix NetScaler ADC

The 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 (formerly NetScaler) 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.

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.

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.

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

Use Client IP

To ensure reliable connectivity for IKEv2 VPN connections it is necessary for the VPN server to see the client’s original source IP address. Follow the steps below to configure the Service Group to forward the client’s IP address to the VPN server.

In the Citrix ADC management console expand System, click Settings, and then click Configure Modes.
Select Use Subnet IP.
Click Ok.
Expand Traffic Management, click Load Balancing, and then click Service Groups.
Select the IKEv2 UDP 500 Service Group.
Click Edit in the Settings section.
Select Use Client IP.
Repeat these steps on the IKEv2 UDP 4500 Service Group.

Note: Making the above changes will require configuring the VPN server to use the Citrix ADC as its default gateway.

Additional Information

Windows 10 Always On VPN IKEv2 Load Balancing and NAT

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

22 Comments

by Richard M. Hicks on January 20, 2020 • Permalink

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/

Search for:
DirectAccess Book
NetMotion Mobility

DirectAccess-like Remote Access for Windows, Mac, iPhone, iPad, and Android

Learn More!
Recent Posts
Always On VPN Resources
DirectAccess Resources

Awards

Consulting

Connect

Mailing List

RSS Feed

Archives

Categories

Tag Cloud

All posts tagged IKEv2

KB5003703

No More Files

Additional Information

Share this:

Like this:

Multiple Root Certificates

Certificate Selection

Certificate Publishing

PowerShell Script

Additional Information

Share this:

Like this:

SSTP and Error 691

IKEv2 and Error 812

NPS Event Log

Any Group

All Groups

Additional Information

Share this:

Like this:

Device Tunnel Configuration in Intune

Create Profile

Profile Settings

Configure a Device Tunnel

Define Custom Cryptography

IKE Security Association Parameters

Child Security Association Parameters

Server Configuration

Caveats

Custom Cryptography

IPv6

Additional Information

Share this:

Like this:

Error 829

Error 619

Workaround

Additional Information

Share this:

Like this:

Network Address Translation

Source Address Translation

Known Issues

Resolution

F5

Citrix ADC

Kemp

Caveat

Workaround

Additional Information

Share this:

Like this:

Share this:

Like this:

Device Tunnel Only?

Is It Recommended?

Deployment Considerations

Advantages

Disadvantages

Summary

Additional Information

Share this:

Like this:

SSTP and Error 691

IKEv2 and Error 812

NPS Event Log

Resolution

User Account

Network Policy

Additional Information

Share this: