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/

Troubleshooting Always On VPN Error 691 and 812 – Part 2

Troubleshooting Always On VPN Error 691 and 812 – Part 2A 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.

“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.”

Troubleshooting Always On VPN Error 691 and 812 – Part 2

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.”

Troubleshooting Always On VPN Error 691 and 812 – Part 2

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.”

Troubleshooting Always On VPN Error 691 and 812 – Part 2

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

Troubleshooting Always On VPN Error 691 and 812 – Part 2

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 65 and the following reason.

“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.”

Troubleshooting Always On VPN Error 691 and 812 – Part 2

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.

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

Troubleshooting Always On VPN Error 691 and 812 – Part 2

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.

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

Troubleshooting Always On VPN Error 691 and 812 – Part 2

Additional Information

Windows 10 Always On VPN Troubleshooting Error 691 and 812

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

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

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

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.

  1. In the Citrix ADC management console expand System, click Settings, and then click Configure Modes.
  2. Select Use Subnet IP.
  3. Click Ok.Always On VPN IKEv2 Load Balancing and NAT
  4. Expand Traffic Management, click Load Balancing, and then click Service Groups.
  5. Select the IKEv2 UDP 500 Service Group.
  6. Click Edit in the Settings section.
  7. Select Use Client IP.
  8. Repeat these steps on the IKEv2 UDP 4500 Service Group.Always On VPN IKEv2 Load Balancing and NAT

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

15 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 Device Tunnel with Azure VPN Gateway

Always On VPN Device Tunnel with Azure VPN GatewayAlways On VPN is infrastructure independent, which allows for many different deployment scenarios including on-premises and cloud-based. In Microsoft Azure, the Azure VPN gateway can be configured to support Windows 10 Always On VPN client connections in some scenarios. Recently I wrote about using the Azure VPN gateway for Always On VPN user tunnels. In this post I’ll describe how to configure the Azure VPN gateway to support an Always On VPN device tunnel.

Limitations

There are a few crucial limitations that come with using the Azure VPN gateway for Always On VPN. Importantly, the Azure VPN gateway can support either user tunnels or device tunnels, not both at the same time. In addition, Azure supports only a single VPN gateway per VNet, so deploying an additional VPN gateway in the same VNet to support Always On VPN user tunnels is not an option.

Root CA Certificate

The Always On VPN device tunnel is authenticated using a machine certificate issued to domain-joined Windows 10 Enterprise edition clients by the organization’s internal Certification Authority (CA). The CA’s root certificate must be uploaded to Azure for the VPN gateway to authorize device tunnel connections. The root CA certificate can be exported using the Certification Authority management console (certsrv.msc) or via the command line.

Export Certificate – GUI

Follow the steps below to export a root CA certificate using the Certification Authority management console.

1. On the root CA server, open the Certification Authority management console.
2. Right-click the CA and choose Properties.
3. Select the CA server’s certificate and choose View Certificate.
4. Select the Details tab and click Copy to File.
5. Click Next.
6. Choose Base-64 encoded X.509 (.CER).

Always On VPN Device Tunnel with Azure VPN Gateway

7. Click Next.
8. Enter a location to save the file to.
9. Click Next, Finish, and Ok.

Export Certificate – Command Line

Follow the steps below to export a root CA certificate using the command line.

1. On the root CA server, open an elevated command window (not a PowerShell window).
2. Enter certutil.exe -ca.cert root_certificate.cer.
3. Enter certutil.exe -encode root.cer root_certificate_base64.cer.

Copy Public Key

1. Open the saved root certificate file using Notepad.
2. Copy the file contents between the BEGIN CERTIFICATE and END CERTIFICATE tags, as shown here. Use caution and don’t copy the carriage return at the end of the string.

Always On VPN Device Tunnel with Azure VPN Gateway

Point-to-Site Configuration

The Azure VPN gateway must be deployed as a Route-Based gateway to support point-to-site VPN connections. Detailed requirements for the gateway can be found here. Once the VPN gateway has been provisioned, follow the steps below to enable point-to-site configuration for Always On VPN device tunnels.

1. In the navigation pane of the Azure VPN gateway settings click Point-to-site configuration.
2. Click the Configure now link 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 an IP address ranges defined in the Azure virtual network.
3. From the Tunnel type drop-down list select IKEv2.
4. In the Root certificates section enter a descriptive name for the certificate in the Name field.
5. Copy and paste the Base64 encoded public key copied previously into the Public certificate data field.
6. Click Save to save the configuration.

Always On VPN Device Tunnel with Azure VPN Gateway

VPN Client Configuration

To support the Always On VPN device tunnel, the client must have a certificate issued by the internal CA with the Client Authentication Enhanced Key Usage (EKU). Detailed guidance for deploying a Windows 10 Always On VPN device tunnel can be found here.

Download VPN Configuration

1. Click Point-to-site configuration.
2. Click Download VPN client.
3. Click Save.
4. Open the downloaded zip file and extract the VpnSettings.xml file from the Generic folder.
5. 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.

Create a Test VPN Connection

It is recommended to create a test VPN connection to perform validation testing of the Azure VPN gateway before provisioning an Always On VPN device tunnel broadly. On a domain-joined Windows 10 enterprise client, create a new VPN connection using IKEv2 with machine certificate authentication. Use the VPN server FQDN copied from the VpnSettings.xml file previously.

Always On VPN Device Tunnel with Azure VPN Gateway

Create an Always On VPN Connection

Once the VPN has been validated using the test profile created previously, an Always On VPN profile can be created and deployed using Intune, SCCM, or PowerShell. The following articles can be used for reference.

Deploy Always On VPN device tunnel using PowerShell

Deploy Always On VPN device tunnel using Intune

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 Diffie-Hellman (DH) key (Group 2 – 1024 bit) is used during IPsec phase 1 negotiation.

Always On VPN Device Tunnel with Azure VPN 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

Windows 10 Always On VPN User Tunnel with Azure VPN Gateway

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN Device Tunnel Configuration using Microsoft Intune

Windows 10 Always On VPN Device Tunnel Configuration using PowerShell

Windows 10 Always On VPN Options for Azure Deployments

Windows 10 Always On VPN IKEv2 Features and Limitations

19 Comments
by Richard M. Hicks on January 6, 2020  •  Permalink
Posted in Always On VPN, AOVPN, Azure, Azure VPN, Azure VPN Gateway, certificates, device tunnel, Encryption, Enterprise, enterprise mobility, IKEv2, Microsoft Intune, Mobility, PowerShell, ProfileXML, public cloud, Remote Access, Security, Windows 10, XML
Tagged , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on January 6, 2020

https://directaccess.richardhicks.com/2020/01/06/always-on-vpn-device-tunnel-with-azure-vpn-gateway/

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/

Always On VPN Error Code 858

Always On VPN Error Code 858When configuring Windows 10 Always On VPN using Extensible Authentication Protocol (EAP), the administrator may encounter a scenario in which the client connection fails. The event log will include an event ID 20227 from the RasClient source that includes the following error message.

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

Always On VPN Error Code 858

RasClient Error 858

RasClient error code 858 translates to ERROR_EAP_SERVER_CERT_EXPIRED. Intuitively, this indicates that the Server Authentication certificate installed on the Network Policy Server (NPS) has expired. To resolve this issue, renew the certificate on the NPS server.

Additional Information

Windows 10 Always On VPN Network Policy Server (NPS) Load Balancing

Windows 10 Always On VPN and Windows Server 2019 NPS Bug

Windows 10 Always On VPN Error Code 864

Leave a comment
by Richard M. Hicks on December 17, 2019  •  Permalink
Posted in Always On VPN, AOVPN, authentication, certificates, Encryption, Enterprise, enterprise mobility, 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
Tagged , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on December 17, 2019

https://directaccess.richardhicks.com/2019/12/17/always-on-vpn-error-code-858/

Always On VPN RRAS Monitoring and Reporting

Always On VPN RRAS Monitoring and ReportingWindows Server with the Routing and Remote Access Service (RRAS) role installed is a popular choice for Windows 10 Always On VPN deployments. Configuring RRAS is commonly performed using the RRAS management console but it can also be configured using PowerShell and/or netsh. In addition, there are a few different options for natively monitoring server health and client connection status.

RRAS Management Console

After installing the RRAS role, the administrator uses the RRAS management console (rrasmgmt.msc) to perform initial configuration. The RRAS management console can also be used to view client connection status by expanding the server and highlighting Remote Access Clients.

Connection Details

To view connection details for a specific connection, the administrator can right-click a connection and choose Status, or simply double-click the connection.

High level information about the connection including duration, data transfer, errors, and IP address assignment can be obtained here. In addition, the administrator can terminate the VPN connection by clicking the Disconnect button.

RRAS Management Console Limitations

Using the RRAS management console has some serious limitations. It offers only limited visibility into client connectivity status, for example. In addition, the client connection status does not refresh automatically. Also, the RRAS management console offers no historical reporting capability.

Remote Access Management Console

The Remote Access Management console (ramgmtui.exe) will be familiar to DirectAccess administrators and is a better option for viewing VPN client connectivity on the RRAS server. It also offers more detailed information on connectivity status and includes an option to enable historical reporting.

Dashboard

The Dashboard node in the Remote Access Management console provides high-level status for various services associated with the VPN server. It also provides a high-level overview of aggregate VPN client connections.

Operations Status

The Operations Status node in the Remote Access Management console provides more detailed information regarding the status of crucial VPN services. Here the administrator will find current status and information about service uptime.

Remote Client Status

The Remote Client Status node in the Remote Access Management console is where administrators will find detailed information about client connectivity. Selecting a connection will provide data about the connection including remote IP addresses, protocols, and ports accessed by the remote client, in addition to detailed connection information such as authentication type, public IP address (if available), connection start time, and data transferred.

Always On VPN RRAS Monitoring and Reporting

Double-clicking an individual connection brings up a detailed client statistics page for the connection, as shown here.

Always On VPN RRAS Monitoring and Reporting

Custom View

The Remote Access Management console includes the option to customize the data presented to the administrator. To view additional details about client connections, right-click anywhere in the column headings to enable or disable any of the fields as required.

Always On VPN RRAS Monitoring and Reporting

Recommended Columns

From personal experience I recommend adding the following columns in the Remote Access Management console.

  • IPv4 Address (this is the IP address assigned to the VPN clients by RRAS)
  • Connection Start Time
  • Authentication Method
  • Total Bytes In
  • Total Bytes Out
  • Rate

Always On VPN RRAS Monitoring and Reporting

Drawbacks

The only real drawback to using the Remote Access Management console is that it supports viewing connections from just one VPN server at a time. If you have multiple RRAS servers deployed, you must retarget the Remote Access Management console each time to view connections on different VPN servers in the organization.

You can retarget the Remote Access Management console at any time by highlighting the Configuration node in the navigation pane and then clicking the Manage a Remote Server link in the Tasks pane.

Always On VPN RRAS Monitoring and Reporting

Reporting

Remote Access reporting is not enabled by default on the RRAS VPN server. Follow the steps below to enable historical reporting for RRAS VPN connections.

1. Highlight the Reporting node in the Remote Access Management console.
2. Click Configure Accounting.
3. Uncheck Use RADIUS accounting.
4. Check Use inbox accounting.
5. Review the settings for data retention and make changes as required.
6. Click Apply.

Always On VPN RRAS Monitoring and Reporting

Optionally, historical reporting can be enabled using PowerShell by opening and elevated PowerShell command window and running the following command.

Set-RemoteAccessAccounting -EnableAccountingType Inbox -PassThru

Important Note! There is a known issue with the inbox accounting database that can result in high CPU utilization for very busy RRAS VPN servers. Specifically, a crucial index is missing from one of the tables in the logging database. To correct this issue, download and run the Optimize-InboxAccountingDatabase.ps1 script on each RRAS VPN server in the organization.

Additional Information

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

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

Windows 10 Always On VPN and RRAS with Single NIC

Windows 10 Always On VPN and RRAS in Microsoft Azure

18 Comments
by Richard M. Hicks on December 15, 2019  •  Permalink
Posted in administration, Always On VPN, AOVPN, Enterprise, enterprise mobility, Mobility, Operational Support, PowerShell, Remote Access, reporting, routing and remote access service, RRAS, VPN, Windows 10, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
Tagged , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on December 15, 2019

https://directaccess.richardhicks.com/2019/12/15/always-on-vpn-rras-monitoring-and-reporting/

Microsoft Intune NDES Connector Error 0x80004003

Microsoft Intune NDES Connector Error 0x80004003To support certificate deployment for non-domain Windows 10 Always On VPN clients, a Windows Server with the Network Device Enrollment Service (NDES) role can be provisioned on-premises. 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.

Connection Status Error

After installing the Microsoft Intune Connector, the administrator may encounter the following error message.

“An error occurred while connecting to the Intune Service. Error code is 0x80004003. The NDES Connector will retry the connection as soon as possible.”

 Microsoft Intune NDES Connector Error 0x80004003

IE Enhanced Security Configuration

This error can occur if Internet Explorer Enhanced Security Configuration (ESC) is enabled. To resolve this issue, disable ESC for administrators and users by opening the Server Manager on the NDES server and performing the following steps.

1. In the navigation pane click Local Server.
2. Click the On link next to IE Enhanced Security Configuration.
3. Click Off in the Administrators section.
4. Click Off in the Users section
5. Click Ok.

Microsoft Intune NDES Connector Error 0x80004003

Once complete, restart the NDES Connector service using the following PowerShell command.

Restart-Service NDESConnectorSvc -PassThru

Additional Configuration

Microsoft Intune NDES Connector Setup Wizard Ended Prematurely

2 Comments
by Richard M. Hicks on November 25, 2019  •  Permalink
Posted in Always On VPN, AOVPN, authentication, Azure, Enterprise, enterprise mobility, Microsoft Intune, Mobility, NDES, Network Device Enrollment Service, Network Device Enrollment Services, PKI, public cloud, public key infrastructure, Remote Access, Security, troubleshooting, VPN, Windows 10, Windows Server 2012 R2, Windows Server 2019
Tagged , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on November 25, 2019

https://directaccess.richardhicks.com/2019/11/25/microsoft-intune-ndes-connector-error-0x80004003/

Always On VPN IKEv2 Load Balancing Issue with Kemp LoadMaster

Always On VPN IKEv2 Load Balancing Issue with Kemp LoadMasterA recent update to the Kemp LoadMaster load balancer may cause failed connections for Always On VPN connections using IKEv2. SSTP VPN connections are unaffected.

Load Balancing IKEv2

When using the Kemp LoadMaster load balancer to load balance IKEv2, custom configuration is required to ensure proper operation. Specifically, the virtual service must be configured to use “port following” to ensure both the initial request on UDP port 500 and the subsequent request on UDP port 4500 are sent to the same real server. This requires the virtual service to be configured to operate at layer 7. Detailed configuration guidance for load balancing IKEv2 on the Kemp LoadMaster load balancer can be found here.

Always On VPN IKEv2 Load Balancing Issue with Kemp LoadMaster

Issues with LMOS 7.2.48.0

A recent release of the Load Master Operating System (LMOS) v7.2.48.0 introduced a bug that affects UDP services configured to operate at layer 7, which includes IKEv2. This bug breaks Always On VPN connections using IKEv2, resulting in failed connections. When this occurs, the administrator may encounter an error 809 message for device tunnel or user tunnel.

Always On VPN IKEv2 Load Balancing Issue with Kemp LoadMaster

Update Available

Administrators who use the Kemp LoadMaster load balancer to load balance Always On VPN IKEv2 connections and have updated to LMOS 7.2.48.0 are encouraged to update to LMOS 7.2.48.1 immediately. This latest update includes a fix that resolves broken IKEv2 load balancing for Always On VPN. Once the LoadMaster has been updated to 7.2.48.1, Always On VPN connections using IKEv2 should complete successfully.

Additional Information

Windows 10 Always On VPN IKEv2 Load Balancing and NAT

Windows 10 Always On VPN IKEv2 Load Balancing with Kemp LoadMaster Load Balancer

Windows 10 Always On VPN SSTP Load Balancing with Kemp LoadMaster Load Balancer

Windows 10 Always On VPN Load Balancing with Kemp LoadMaster in Azure

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

13 Comments
by Richard M. Hicks on November 18, 2019  •  Permalink
Posted in ADC, Always On VPN, AOVPN, application delivery controller, device tunnel, enterprise mobility, High Availability, Hotfix, IKEv2, Kemp, Load Balancing, LoadMaster, Mobility, Remote Access, routing and remote access service, RRAS, troubleshooting, Update, user tunnel, VPN, Windows 10, Windows Server 2016, Windows Server 2019
Tagged , , , , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on November 18, 2019

https://directaccess.richardhicks.com/2019/11/18/always-on-vpn-ikev2-load-balancing-issue-with-kemp-loadmaster/

« Older Posts
Newer Posts »
%d bloggers like this: