Security Considerations for Always on VPN (AOVPN) Deployments
Introduction
Microsoft Always on VPN (AOVPN) is a remote access technology included as part of the Unified Remote Access role in Windows Server 2012 R2/2016/2019. Starting from Windows Server 2016, Routing and Remote Access server (RRAS) role is designed to be used remote access server as well as router supporting wide range of features. For AOVPN deployment the required features are support for IKEv2 VPN connections, Secure Socket Tunneling Protocol (SSTP), and LAN routing.
IKEv2 is a VPN tunneling protocol described in IEFT RFC 7296 and its main advantages is that it can tolerate interruptions in the undelaying network connections, for example if network connectivity is lot temporarily or if user moves its end point from one network to another, IKEv2 automatically restores the VPN Connection when network connection is reestablished.
It represents a paradigm shift in the way remote access is provided to corporate-managed Windows devices. AOVPN is fundamentally built using existing, widely deployed industry standard protocols for which security configuration is will understood. However, many organizations want to better understand the specific security features incorporated with AOVPN.
This whitepaper serves to provide an overview of security features in AOVPN. It will explain in detail how the authentication process works, provide insight into optional security configurations, its integration with Azure Cloud and advanced features, explore the differences between split and force tunneling, and outline how to address lost or stolen AOVPN devices. Finally, the benefits of using the Celestix E Series hardware appliance platform and its additional features and enhancements can provide the best experience for AOVPN deployments.
What is Always on VPN (AOVPN)
AOVPN is a collection of Windows platform technologies that are assembled to provide secure, seamless, and transparent, always on, bi-directional network connectivity for remote Windows 10 machines. AOVPN leverages authenticated IPsec encryption for mutual authentication, confidentiality, data integrity, access control and establishing along with data source authentication for IP datagrams. AOVPN supports both IPv6 and IPv4 protocols. AOVPN leverages variety of Authentication options such as Digital Certificate, EAP, smart cards, Windows Hello for Business, and OTP through MFA by way of EAP radius configuration. AOVPN provides two types of tunnels; Device Tunnel and User Tunnels and these tunnels can be provisioned via SCCM, Microsoft Endpoint configuration manager and Intune, or running PowerShell script on the windows 10 end point.
Always on VPN (AOVP) Authentication
When a AOVPN client is outside of the corporate network and has an active
Internet connection, the client will attempt to establish connectivity with the AOVPN gateway using IKEv2 or SSTP (if tunnel type is set to Automatic then VPN client will cycle through all available tunnel types and connect to either IKEv2 or SSTP as these two tunnels are configured for AOVPN) type. In a typical configuration, two distinct AOVPN tunnels are established in an orderly fashion– a Device tunnel and a user tunnel.
Device tunnel – Enables Windows 10 AOVPN enable device to connect with specified VPN servers prior to users log on to the device using Machine certificate always present on the endpoint. Organizations require remote device management and Pre-login connectivity scenarios use device tunnel connectivity options. AOVPN Device Tunnel can be compared with DirectAccess Infrastructure tunnel. Device tunnel use IKEv2 tunnel type and can be configured to meet highest level of security and protection for remote connections.
User tunnel – Enables windows 10 AOVPN enabled device to connect only after Active Directory based user has successfully logged on to the device. After User tunnel connected with the specified VPN severs, it allows users to access organization corporate resources through VPN servers.
Device and User tunnels can work independently with their configured VPN profiles, can be configured to use different authentication methods, can be connected at the simultaneously, and can use appropriate VPN configuration settings.
Always on VPN (AOVP) Network Configuration
AOVPN in Windows Server 2012 R2/2016/2019 can now be configured behind an existing edge firewall for additional protection. Using this deployment model, the AOVPN server is configured using private IPv4 addresses. The server can be configured with two network interfaces in parallel with existing perimeter networks, or with a single network interface either in the DMZ or on the LAN.
Perimeter/DMZ deployments reduce the exposure of the AOVPN server to untrusted networks. When the AOVPN server is located behind a device performing NAT, it supports only the IKEV2 and SSTP tunnel type for AOVPN clients. SSTP is an alternative to IKEv2 which uses industry standard TLS enabling it accessible from Internet and provides good security out of box. TLS used by SSTP tunnel type also support offloading feature using a third-party application delivery controller such as KEMP to reduce resource utilization on the AOVPN server. AOVPN client can be configured to connect as Always on, application triggering, and name-based triggering.
Always on VPN (AOVP) Security Configuration
To provide even higher levels of assurance for AOVPN clients, strong user authentication can be implemented using Digital certificates, Windows Hello for business, smart cards (physical or virtual), One-time password of MFA support by utilizing EAP Radius integration. Custom configuration can be employed to provide additional security. For example, with additional configuration, IPsec custom crypto settings can be customized to meet higher security requirements.
Windows information protection (WIP) enables separation and protection of enterprise date against disclosure across corporate issued and personal devices. The EdpModelId node in the AOVPN VPNv2 configuration service provider (CSP) allows a windows 10 VPN client to work with WIP and extends its protection to remote devices. WIP use be used for File Encryption and file access blocking, restricting copy/paste, sharing and drag/drop operations, protect intranet resources over VPN, and protecting SMB and Internet cloud resources over the VPN.
AOVPN also support use traffic filters which provides enterprise the ability to decide what traffic is allowed into the corporate network based on their policy. Traffic filters can effectively be used for interface specific firewall rules on VPN interface and they are of two types; App-based (traffic from applications can be set to allow/deny) rules and traffic based rules (based on 5-tuple ports, addresses, and protocols).
AOVPN also support LockDown VPN which only allows the device to send network traffic over the VPN interface. Its enforces this by keeping VPN connected all times, user’s ability to disable/disconnect/Delete VPN Connection, applying force tunnel mode, and if VPN connection is not available then disable all outbound access.
To further enhance the overall security of AOVPN, a third-party Application
Delivery Controller (ADC) can be deployed to provide a level of pre authentication for AOVPN clients. Also, encryption methods using stronger cipher suites and Hashing algorithms.
Comparing Always on VPN (AOVP) with DirectAccess
DirectAccess Functionality | AOVPN equivalent |
Transparent connectivity to corporate network | Always on VPN can be used to support; application launch based auto-triggering, namespace resolution requests or permanent Always ON VPN |
Managing remotely connected DA clients via Manage-out from management workstations | Device Tunnel can be configured to achieve this functionality |
Dedicated Tunnel (Infrastructure) to provide corporate access prior to user login | Device Tunnel can be configured to achieve this functionality |
Use of Network Location service (NLS) to determine the inside / outside corporate location | Trusted Network detection can be used to achieve the similar compatibility, which is based on connection specific DNS suffix assigned to NIC |
HTTPS Connectivity | SSTP can be used as fall-back option from IKEv22 |
DirectAccess operational status monitoring | Windows server 2016 Remote access console provides the operational status of VPN services |
DirectAccess connected clients operational status | Windows server 2016 Remote access console provides the operational status of AOVPN clients |
Inbox or Radius accounting for DA connections reporting | Windows server 2016 Remote access console provides the reporting for AOVPN clients |
Enable Access to Management servers prior to user login | Device Tunnel with traffic filters can be configured to achieve similar functionality |
Load balancing support using Windows NLB or third-party load balancer | AOVPN support the use of Windows NLB and third-party load balancer for load balancing SSTP and IKEv2 tunnel types |
DirectAccess security groups to limit remote access functionality to specific domain joined devices | RADIUS can be used to configure granular authorisation access by the way of security groups in User Tunnel type |
DirectAccess support behind edge firewall or NAT device | AOVPN can be configured to use protocols IKev2 or SSTP which fully support the use of VPN server behind NAT device or perimeter firewall |
Multiple domains and forest support | AOVPN doesn’t depend on AD domain services forests and domain topology. AD authorisation can be achieved via RADIUS by way of EAP. |
Split tunnel and force tunnel support for intranet/internet separation | AOVPN can be used to configure Split and force tunnel natively with additional application specific granular routing policies |
Use of Network Connectivity assistant (NCA) to provide corporate connectivity status | AOVPN is integrated with native NCA and offers connectivity status from NIC |
DirectAccess Multisite to provide multiple remote access entry points | AOVPN doesn’t offer this feature natively, however this functionality can be achieved by way of third-party global server load balancing (GSLB) |
DirectAccess client configuration via Group Policy | AOVPN configuration can be applied using PowerShell, SCCM, Intune |
Split Tunneling vs. Force Tunneling
By default, AOVPN is configured with split tunneling enabled. This allows the
AOVPN client to connect to the public Internet and the corporate network simultaneously. Some security administrators believe this to be a security risk, but closer evaluation reveals this risk to be more perceived than actual.
One concern with split tunneling is that a compromised device could allow an attacker to tunnel from the Internet through the connected AOVPN client to access resources on the corporate network. However, the authenticated nature of the AOVPN IPsec tunnels makes this impossible.
If a AOVPN client is infected with a virus or malicious software, it may be possible for it to infect other hosts on the corporate network via the AOVPN connection. However, this scenario also applies to traditional VPN clients. The risk is reduced with AOVPN because they are always managed, and this maintenance of client security posture allows for better malware defense and client protection.
With split tunneling, AOVPN clients have unrestricted access to the public Internet. This lack of filtering is a valid concern for security administrators, but again, this problem exists for traditional VPN clients too. A VPN client with split tunneling disabled may not be able to access the Internet freely while connected to the VPN, but once the user disconnects the VPN session they will once again has full unrestricted Internet access. AOVPN also use force tunnel with exclusions which enable enterprises to exclude office 356 or any other traffic from VPN tunnel by way of network addresses.
There are several ways to mitigate this issue. AOVPN can be configured to enable force tunneling, which requires AOVPN clients to use the on-premises corporate proxy servers to access the Internet. Force tunneling has some potential negative side effects, however. By forcing all of the client’s Internet traffic over the AOVPN connection, the user experience is often degraded by additional network latency introduced by encryption and web proxy traffic inspection. Also, the added network load can degrade performance and limit scalability of the AOVPN server. With AOVPN force tunnel is not supported in dual tunnel deployment and only supported on User tunnel type deployment.
A better solution is to enable remote filtering on existing on-premises secure web gateways (if available) or to investigate the use of cloud-based web content filtering solutions for remote/mobile clients.
Lost or stolen AOVPN Enabled Devices
AOVPN RRAS server can be configured to enforce revocation of VPNs that’s uses IKEv2 and machine certificates for device tunnel authentication. If a AOVPN enabled device is compromised or stolen then its machine issued certificate can be revoked and its access can be denied on the VPN server after its revocation list has been updated.
Concerns that always-on AOVPN clients represent an increased security risk are unfounded. Like a device configured for client-based VPN, an attacker would need valid user credentials to gain access to the network, but AOVPN includes additional safeguards. Clients use computer accounts that can be disabled in Active Directory to prevent connectivity, even if valid user credentials are supplied. If real-time remediation is necessary, terminating an active client session forces authentication, which will fail after the computer account is disabled.
The AOVPN client presents the same risks as a client configured with client-based VPN. Many of these risks can be mitigated using a combination of operational security techniques and technologies commonly used today. Mobile clients should be configured with full disk encryption and require a PIN to boot the device. They should be configured to require a password to be entered when waking from sleep or hibernation. Strong user authentication using smart cards or dynamic passwords can also be leveraged.
Security and the Celestix SecureAccess Appliance Platform
The AOVPN solution is improved by additional security measures included with the Celestix appliance platform (physical, virtual and AWS edition). Based on Microsoft and industry standard security best practices, the Celestix appliance platform has undergone extensive hardening and attack surface reduction. These processes disable or remove unnecessary services, applications, roles, and features for a stronger security posture. Additional measures include updating the default configuration of the Windows firewall to further restrict remote access to services running on the host and improving default encryption algorithms used by applications and services.
While augmenting the security, the Celestix appliance platform also offers simplified deployment and centralized management features. The platform lowers the total cost of ownership and maintenance overhead presented in other deployment options.
Conclusion
AOVPN is a compelling remote access solution that can be used to better manage remote Windows clients and dramatically improve their security posture, while at the same time securely providing ubiquitous and familiar remote access to on-premises applications and data. AOVPN leverages mature, well understood, and commonly deployed Windows platform technologies and works with Azure conditional access. Client connections are fully authenticated using a combination of digital certificates, in addition to machine and user authentication. The solution provides significantly higher levels of assurance when compared to DirectAccess, and security can be further enhanced with custom configuration. AOVPN provides support for both split and force tunneling and lost or stolen devices can be denied remote access administratively. The Celestix E Series hardware appliance platform increases the solution’s security through service hardening and attack surface reduction and simplifies feature installation with streamlined management interface.