It is with great pleasure that I announce Richard M. Hicks Consulting, Inc. has been included in Enterprise Networking Magazine’s Top 10 VPN consulting services for 2020! Enterprise Networking Magazine is a leading magazine and web site dedicated to the enterprise networking industry and its professionals.
You can read the full write-up on Richard M. Hicks Consulting, Inc. at Enterprise Networking’s web site here.
Posted by Richard M. Hicks on May 18, 2020
https://directaccess.richardhicks.com/2020/05/18/enterprise-networking-magazine-top-10-vpn-consulting-services-2020/
During the planning phase of a Windows 10 Always On VPN implementation the administrator must decide between two tunneling options for VPN client traffic – split tunneling or force tunneling. When split tunneling is configured, only traffic for the on-premises network is routed over the VPN tunnel. Everything else is sent directly to the Internet. With force tunneling, all client traffic, including Internet traffic, is routed over the VPN tunnel. There’s been much discussion recently on this topic, and this article serves to outline the advantages and disadvantages for both tunneling methods.
Force tunneling is typically enabled to meet the following requirements.
By routing all the client’s Internet traffic over the VPN tunnel, administrators can inspect, filter, and log Internet traffic using existing on-premises security solutions such as web proxies, content filters, or Next Generation Firewalls (NGFW).
Enabling force tunneling ensures privacy and protection of all Internet communication. By routing all Internet traffic over the VPN, administrators can be certain that all communication from the Always On VPN client is encrypted, even when clients access unencrypted web sites or use untrusted or insecure wireless networks.
While configuring force tunneling for Always On VPN has some advantages, it comes with some serious limitations as well.
User experience is often degraded when all Internet traffic is routed over the VPN. These suboptimal network paths increase latency, and VPN encapsulation and encryption overhead increase fragmentation, leading to reduced throughput. Most Internet traffic is already encrypted in some form, and encrypting traffic that is already encrypted makes the problem even worse. In addition, force tunneling short-circuits geographic-based Content Delivery Networks (CDNs) further reducing Internet performance. Further, location-based services are often broken which can lead to improper default language selection or inaccurate web search results.
Additional resources may need to be provisioned to support force tunneling. With corporate and Internet traffic coming over the VPN, more CPU, memory, and network resources may be required. Deploying additional VPN servers and higher throughput load balancers to support the increase in network traffic may also be necessary. Force tunneling also places higher demands on Internet Service Provider (ISP) links to the corporate datacenter.
The alternative to force tunneling is “split tunneling”. With split tunneling configured, only traffic destined for the internal corporate network is routed over the VPN. All other traffic is sent directly to the Internet. Administrators define IP networks that should be routed over the VPN, and those networks are added to the routing table on the VPN client.
The challenge of providing visibility and control of Internet traffic with split tunneling enabled can be met using a variety of third-party security solutions. Microsoft Defender ATP recently introduced support for web content filtering. Also, there are numerous cloud-based security offerings from many vendors that allow administrators to monitor and control client-based Internet traffic. Zscaler and Cisco Umbrella are two popular solutions, and no doubt there are many more to choose from.
The general guidance I provide customers is to use split tunneling whenever possible, as it provides the best user experience and reduces demands on existing on-premises infrastructure. Enabling split or force tunneling is ultimately a design decision that must be made during the planning phase of an Always On VPN implementation project. Both configurations are supported, and they each have their merits.
In today’s world, with many applications accessible via public interfaces, force tunneling is an antiquated method for providing visibility and control for managed devices in the field. If required, investigate the use of Microsoft or other third-party solutions that enforce security policy in place without the requirement to backhaul client Internet traffic to the datacenter over VPN for inspection, logging, and filtering.
Whitepaper: Enhancing VPN Performance at Microsoft
Whitepaper: How Microsoft Is Keeping Its Remote Workforce Connected
Posted by Richard M. Hicks on April 14, 2020
https://directaccess.richardhicks.com/2020/04/14/always-on-vpn-split-vs-force-tunneling/
With the COVID-19 global pandemic forcing nearly everyone to work from home these days, organizations that implemented force tunneling for their VPN clients are likely encountering unexpected problems. When force tunneling is enabled, all client traffic, including Internet traffic, is routed over the VPN tunnel. This often overloads the VPN infrastructure and causes serious slowdowns, which degrades the user experience and negatively impacts productivity. This is especially challenging because so many productivity applications like Microsoft Office 365 are optimized for Internet accessibility. It is one of the main reasons that force tunneling is not generally recommended.
When enabling split tunneling is not an option, administrators frequently ask about enabling force tunneling with some exceptions. The most common configuration is enabling force tunneling while still allowing Office 365 traffic to go outside of the tunnel. While this is something that third-party solutions do easily, it has been a challenge for Always On VPN. Specifically, Always On VPN has no way to route traffic by hostname or Fully-Qualified Domain Name (FQDN).
To address this challenge, the administrator can configure Exclusion Routes. Exclusion Routes are supported in Windows 10 1803 with update KB4493437, Windows 10 1809 with update KB4490481, and Windows 10 1903/1909.
Exclusion routes are defined in the client routing table that are excluded from the VPN tunnel. The real challenge here is determining all the required IP addresses required for Office 365.
Given current events and the heavy demands placed on enterprises supporting exclusively remote workforces, Microsoft has recently published guidance for configuring Always On VPN force tunneling while excluding Office 365 traffic. Their documentation includes all the required IP addresses to configure exclusions for. This will make it much simpler for administrators to configure Always On VPN to support this unique scenario. The following links provide detailed configuration guidance for enabling force tunneling for Always On VPN with exceptions.
Windows 10 Always On VPN Split vs. Force Tunneling
Posted by Richard M. Hicks on April 9, 2020
https://directaccess.richardhicks.com/2020/04/09/always-on-vpn-force-tunneling-with-office-365-exclusions/
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!
Posted by Richard M. Hicks on April 7, 2020
https://directaccess.richardhicks.com/2020/04/07/remote-access-qa-webinar-hosted-by-kemp/
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.
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.
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.
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.
Using the device tunnel alone does have some compelling advantages over the standard two tunnel (device tunnel/user tunnel) deployment model. Consider the following.
While there are some advantages to using the device tunnel by itself, this configuration is not without some serious limitations. Consider the following.
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.
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
Posted by Richard M. Hicks on April 6, 2020
https://directaccess.richardhicks.com/2020/04/06/always-on-vpn-device-tunnel-only-deployment-considerations/
Unlike DirectAccess, Windows 10 Always On VPN settings are deployed to the individual user, not the device. As such, there is no support for logging on without cached credentials using the default configuration. To address this limitation, and to provide feature parity with DirectAccess, Microsoft later introduced the device tunnel option in Windows 10 1709.
The device tunnel is designed to allow the client device to establish an Always On VPN connection before the user logs on. This enables important scenarios such as logging on without cached credentials. This feature is crucial for organizations who expect users to log on to devices the first time remotely. The device tunnel can also be helpful for remote support, allowing administrators to manage remotely connected Always On VPN clients without having a user logged on. In addition, the device tunnel can alleviate some of the pain caused by administrators resetting remote worker’s passwords, or by users initiating a Self-Service Password Reset (SSPR).
The device tunnel requires Windows 10 Enterprise edition 1709 or later, and the client device must be joined to the domain. The device tunnel must be provisioned in the context of the local system account. Guidance for configuring and deploying a Windows 10 Always On VPN device tunnel can be found here.
The device tunnel is authenticated using a certificate issued to the client device, much the same as DirectAccess does. Authentication takes place on the Routing and Remote Access Service (RRAS) VPN server. It does not require a Network Policy Server (NPS) to perform authentication for the device tunnel.
Eventually an administrator may need to deny access to a device configured with an Always On VPN device tunnel connection. In theory, revoking the client device’s certificate and terminating their IPsec Security Associations (SAs) on the VPN server would accomplish this. However, Windows Server RRAS does not perform certificate revocation checking for Windows 10 Always On VPN device tunnel connections by default. Thankfully an update is available to enable this functionality. See Always On VPN Device Tunnel and Certificate Revocation for more details.
As the device tunnel is designed only to support domain authentication for remote clients, it should be configured with limited access to the on-premises infrastructure. Below is a list of required and optional infrastructure services that should be reachable over the device tunnel connection.
Limiting access over the Always On VPN device tunnel can be accomplished in one of the following two ways.
The administrator can configure traffic filters on the device tunnel to restrict access only to those IP addresses required. However, be advised that when a traffic filter is enabled on the device tunnel, all inbound access will be blocked. This effectively prevents any remote management of the device from an on-premises system over the device tunnel.
An alternative to using traffic filters to limit access over the device tunnel is using host routes. Host routes are configured with a /32 prefix size and define a route to a specific individual host. The following is an example of host route configuration in ProfileXML.
Note: A PowerShell script that enumerates all enterprise domain controllers and outputs their IP addresses in XML format for use in ProfileXML can be found here.
Some organizations may have hundreds or even thousands of domain controllers, so creating individual host route entries for all domain controllers in profileXML may not be practical. In this scenario it is recommended to add host routes only for the domain controllers that belong to the Active Directory site where the VPN server resides.
The device tunnel can be safely deployed in conjunction with the user tunnel whenever its functionality is required.
If the device tunnel and user tunnel are both deployed, it is recommended that only one of the tunnels be configured to register in DNS. If the device tunnel is configured to register its IP address in DNS, be advised that only those devices with routes configured in the device tunnel VPN profile will be able to connect remotely to Always On VPN clients.
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
Posted by Richard M. Hicks on March 30, 2020
https://directaccess.richardhicks.com/2020/03/30/always-on-vpn-device-tunnel-operation-and-best-practices/
NetMotion 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 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.
More information about the NetMotion Software and Microsoft Endpoint Manager and Intune partnership here.
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
Interested in learning more about NetMotion Mobility? Complete the form below and I’ll provide you with more information.
Posted by Richard M. Hicks on March 11, 2020
https://directaccess.richardhicks.com/2020/03/11/netmotion-mobility-with-microsoft-endpoint-manager-and-intune/
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.
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.”
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.
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.”
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.
Follow the steps below to change Network Access Permission on an individual user’s Active Directory account.
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.
Follow the steps below to configure NPS network policy to ignore user account dial-in properties.
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/
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 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.
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.
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.
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.
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.
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.
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.
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.
Note: Making the above changes will require configuring the VPN server to use the Citrix ADC as its default gateway.
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
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/
One 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.
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.
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.
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.
The virtual server is configured to use TCP port 443. It is recommended to use SSLSESSION persistence.
The LEASTCONNECTION load balancing method is the recommend option for load balancing method.
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.
Once complete, bind the new service monitor to the load balancing services or service groups accordingly.
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.
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
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.
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
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/
