Implementing and Managing Always On VPN

Introduction: The Modern Perimeter

In the traditional office environment, networking was straightforward: you connected your computer to a wall jack or the office Wi-Fi, and you were inside the trusted network. Security policies were enforced at the edge of the building, and once you were "inside," you had access to internal resources like file shares, printers, and internal web applications. However, the rise of remote work, mobile computing, and the cloud has rendered this "castle-and-moat" security model largely obsolete. Employees now work from coffee shops, home offices, and airport terminals, requiring secure access to corporate resources from anywhere in the world.

Always On VPN (AOVPN) represents a fundamental shift in how we handle remote connectivity. Unlike traditional virtual private network (VPN) solutions that require a user to manually launch an application and click "Connect" every time they need to access a resource, AOVPN is designed to be transparent and persistent. It establishes a secure tunnel as soon as the user’s device detects an internet connection, often before the user even logs into their Windows profile. This capability ensures that management tasks, group policy updates, and authentication requests can occur without human intervention, effectively extending the corporate network to the employee's location regardless of where they are.

Understanding and implementing AOVPN is critical for IT professionals because it bridges the gap between security and user experience. When users find connectivity difficult, they often resort to insecure workarounds, such as emailing sensitive files to personal accounts or using unauthorized cloud storage services. By making the remote connection invisible and automatic, you not only improve productivity but also ensure that all remote traffic is subject to the same security inspection and access controls as traffic generated from within the office.

Core Architecture and Prerequisites

To understand how Always On VPN functions, you must first recognize that it relies on a combination of existing technologies: Windows 10/11 native VPN clients, IKEv2 (Internet Key Exchange version 2) tunneling, and certificate-based authentication. Unlike older VPNs that relied on SSL/TLS, IKEv2 is highly resilient to network changes—such as moving from Wi-Fi to cellular data—and provides a stable, high-performance connection that is ideal for persistent tunnels.

The Components of AOVPN

A robust AOVPN implementation typically consists of three primary components: the VPN Gateway (usually a Windows Server running Routing and Remote Access), the Public Key Infrastructure (PKI) for issuing certificates, and the client devices managed via mobile device management (MDM) or Group Policy.

1. VPN Gateway: This server acts as the entry point for incoming connections. It terminates the IKEv2 tunnel and inspects incoming traffic. It must have a public IP address and be configured to handle traffic from the internet.
2. PKI (Active Directory Certificate Services): AOVPN relies heavily on machine and user certificates. Machine certificates are used to authenticate the device to the VPN server before the user even logs in, while user certificates provide an extra layer of identity verification.
3. Client Configuration: Using a platform like Microsoft Intune or Group Policy, you define how the client behaves. This includes the VPN profile, the DNS search suffixes, and the traffic routing rules (split tunneling vs. forced tunneling).

Callout: Traditional VPN vs. Always On VPN A traditional VPN is a reactive tool; the user decides when to connect, and the session is often fragile. If the user loses their Wi-Fi signal, the connection drops, and the user must reconnect manually. Always On VPN is proactive. It treats the remote device as if it were constantly plugged into the office network, automatically reconnecting whenever the internet signal is restored. This creates a state of "always-managed" security.

Configuring the VPN Gateway

The VPN gateway is the heartbeat of your remote access architecture. You will typically deploy this using the Routing and Remote Access Service (RRAS) on a Windows Server. The configuration process involves setting up the server to accept IKEv2 connections and ensuring it can communicate with your internal domain controllers for authentication.

Step-by-Step Server Setup

1. Install the Role: Start by installing the "Remote Access" server role, specifically selecting "DirectAccess and VPN (RAS)."
2. Configure RRAS: Once installed, launch the Routing and Remote Access console. Right-click the server name and select "Configure and Enable Routing and Remote Access." Choose the "Remote access (dial-up or VPN)" option.
3. Define Address Pool: You need to define a pool of IP addresses that will be assigned to remote clients. These should be on a subnet that is routable to your internal network but distinct from your office Wi-Fi or wired subnets.
4. Radius Authentication: For enterprise environments, you should configure RRAS to use a RADIUS server, such as the Network Policy Server (NPS) role. This allows you to centralize policy management and log connection attempts for auditing purposes.

Note: Always ensure that your VPN gateway is behind a firewall that only allows specific ports (typically UDP 500 and UDP 4500 for IKEv2/IPsec) from the internet to the gateway. Exposing the full server to the internet is a significant security risk.

Managing Client Connectivity: The XML Profile

The "magic" of AOVPN happens on the client side. The Windows operating system uses an XML-based VPN profile to dictate how the connection behaves. You can deploy this profile using PowerShell or an MDM tool like Intune.

Understanding the XML Profile

The XML profile contains settings for the server address, the authentication method, and the routing logic. Below is an example of a core section of an AOVPN XML profile:

<VPNProfile>
  <NativeProfile>
    <Servers>vpn.yourcompany.com</Servers>
    <NativeProtocolType>IKEv2</NativeProtocolType>
    <Authentication>
      <MachineCertificate>true</MachineCertificate>
      <UserCertificate>true</UserCertificate>
    </Authentication>
    <RoutingPolicyType>SplitTunnel</RoutingPolicyType>
  </NativeProfile>
</VPNProfile>

Explanation of the Code:

• Servers: This is the FQDN (Fully Qualified Domain Name) of your VPN gateway.
• NativeProtocolType: IKEv2 is the industry standard for AOVPN because it supports "MOBIKE," which allows the connection to persist even if the client's IP address changes.
• Authentication: By requiring both a machine certificate and a user certificate, you ensure that only company-owned devices can initiate a connection, and only authorized users can complete it.
• RoutingPolicyType: Split tunneling is generally preferred. It sends only corporate-bound traffic through the VPN, while general internet traffic (like streaming or personal browsing) goes directly out of the user's local internet connection. This reduces the load on your corporate bandwidth.

Implementing Split Tunneling vs. Forced Tunneling

One of the most frequent architectural decisions you will make is whether to implement split tunneling or forced tunneling. This decision impacts both your network performance and your security posture.

Split Tunneling

In a split-tunnel configuration, the client device maintains two simultaneous network paths. Traffic destined for internal resources (e.g., \\fileserver\data) is routed through the VPN tunnel, while traffic destined for the public internet (e.g., google.com) goes directly to the user's ISP.

• Pros: Significantly reduces latency for end-users and prevents the VPN gateway from becoming a bottleneck for non-essential traffic.
• Cons: The device is technically connected to two networks at once. If the device is compromised, an attacker could potentially use the client as a bridge to reach internal assets.

Forced Tunneling

In a forced-tunnel configuration, all traffic—including internet traffic—is routed through the VPN tunnel.

• Pros: Maximum security. All traffic is subject to the company's web filtering, firewalls, and data loss prevention (DLP) solutions.
• Cons: Can create massive bandwidth usage on your corporate internet connection. If the office internet is slow, the user's entire web experience will be slow.

Tip: Most organizations adopt a "hybrid" approach. They use split tunneling for performance but enforce strict endpoint security (like EDR and web content filtering) on the client device to mitigate the risks associated with the device being on both the VPN and the public internet.

Best Practices for Secure Deployment

Implementing AOVPN is not just a technical task; it is a security project. Because you are effectively opening a door into your internal network, you must adhere to strict security standards.

1. Enforce Certificate-Based Authentication

Never rely on passwords for VPN authentication. Passwords can be phished, shared, or brute-forced. Certificates are tied to the hardware of the device (if you use a Trusted Platform Module or TPM), making them much harder to steal.

2. Implement Device Compliance

Before allowing a connection, the VPN gateway should verify that the device is "healthy." This means checking if the antivirus is active, if the OS is patched, and if the firewall is enabled. If a device fails these checks, it should be denied access to the internal network.

3. Use Network Policy Server (NPS) for Granular Control

NPS allows you to define policies based on Active Directory groups. For example, you can create a policy that only allows members of the "Remote-Access-Users" group to connect, and even then, only during business hours or from specific IP ranges if necessary.

4. Continuous Monitoring

Logs are your best friend. Monitor your VPN gateway logs for patterns such as:

• High rates of failed authentication (potential brute-force).
• Connections from unexpected geographic locations.
• Unusual traffic volume from a single user.

Common Pitfalls and Troubleshooting

Even with careful planning, AOVPN implementations can face challenges. Here are the most common issues administrators encounter and how to resolve them.

Issue 1: Certificate Mismatch

The VPN client will fail to connect if it does not trust the certificate presented by the VPN gateway, or if the client does not have a valid certificate to present to the server.

• Fix: Ensure that the Root CA (Certificate Authority) certificate is pushed to the "Trusted Root Certification Authorities" store on all client machines. Use Group Policy or Intune to automate this distribution.

Issue 2: MTU (Maximum Transmission Unit) Problems

Sometimes, users complain that they can connect to the VPN but cannot load certain web pages or access large files. This is often caused by MTU size discrepancies. The VPN tunnel adds a small overhead to every packet. If the packet is too large, it gets fragmented or dropped.

• Fix: Adjust the MTU setting on the client’s VPN interface. A common value to try is 1350 or 1400 bytes to account for the overhead of the IKEv2 tunnel.

Issue 3: DNS Resolution

If a user can ping the IP address of an internal server but cannot access it by name, you have a DNS issue.

• Fix: Ensure your VPN profile is configured to push the correct internal DNS suffixes to the client. The client needs to know that requests for *.yourcompany.com should be sent to the internal DNS servers rather than the ISP’s DNS.

Warning: Avoid using Split DNS if possible. If you use Split DNS, ensure that the internal DNS server is configured to resolve external names as well, or you will create a scenario where the client cannot resolve public websites while connected to the VPN.

Comparison of Remote Access Technologies

To help you decide if AOVPN is the right choice for your specific use case, consider the following comparison of common remote access technologies.

As seen in the table, AOVPN is the superior choice for enterprise-managed environments where devices are under the control of the IT department. If you have a workforce using company-issued laptops, AOVPN provides the best balance of security and user experience.

Advanced Management: PowerShell for Automation

While you can configure many settings through the GUI, PowerShell is essential for scaling your AOVPN deployment. You can use the Add-VpnConnection cmdlet to push configurations to client machines during the onboarding process.

Scripting the VPN Profile

Below is a PowerShell snippet that creates a basic VPN profile on a Windows client:

Add-VpnConnection -Name "CorporateVPN" `
                  -ServerAddress "vpn.company.com" `
                  -TunnelType IKEv2 `
                  -EncryptionLevel Required `
                  -AuthenticationMethod MachineCertificate `
                  -SplitTunneling $true `
                  -RememberCredential $true

Breaking down the script:

• Name: The identifier the user will see in their network settings.
• TunnelType: Specifically sets the protocol to IKEv2.
• EncryptionLevel Required: Forces the connection to use high-strength encryption, rejecting any insecure fallback attempts.
• SplitTunneling $true: Enables the split-tunneling behavior discussed earlier.

You can wrap this in a script that checks for the existence of the profile first, preventing duplicate entries. Automation like this is vital when you have hundreds or thousands of devices to manage.

Maintaining the Infrastructure

Once your AOVPN is live, it is not a "set it and forget it" system. You must maintain the PKI, the gateway servers, and the client configurations.

1. Certificate Lifecycle Management

Certificates expire. If your machine certificates expire, your entire VPN infrastructure will stop working for those devices. Automate the renewal process through Auto-Enrollment in Active Directory. Monitor your CA (Certificate Authority) to ensure it is healthy and that you have a backup of your Root CA private key in a secure, offline location.

2. Updating Gateway Software

VPN gateways are high-value targets for attackers. Stay on top of security patches for your Windows Server environment. Use a staging environment to test patches before deploying them to your production VPN gateways to ensure that a security update doesn't accidentally break the IKEv2 negotiation process.

3. Reviewing Access Policies

Periodically audit your NPS or firewall policies. Remove users who have left the organization, and ensure that service accounts used for VPN authentication have the least amount of privilege necessary.

Common Questions (FAQ)

Q: Can I use Always On VPN for BYOD (Bring Your Own Device) equipment? A: It is technically possible, but generally not recommended. AOVPN works best when you have full control over the device, including the ability to push machine certificates and manage the OS configuration. For BYOD, a clientless SSL VPN or a managed tunnel within a containerized application is often more appropriate.

Q: Does AOVPN support Multi-Factor Authentication (MFA)? A: Yes. You can integrate your VPN gateway with solutions like Azure AD MFA or on-premises RADIUS-based MFA providers. When the user attempts to connect, they receive a push notification on their mobile device to approve the connection.

Q: Why does my connection drop when I switch from Wi-Fi to Ethernet? A: This usually indicates an issue with the IKEv2 "MOBIKE" implementation. Check your VPN gateway settings to ensure that MOBIKE is enabled and that your firewall is not dropping the packets during the transition period where the client's source IP address changes.

Q: Is AOVPN compatible with third-party firewalls? A: Yes, as long as the firewall supports IKEv2/IPsec pass-through. Most modern firewalls (Palo Alto, Fortinet, Cisco) handle this natively.

Summary and Key Takeaways

Implementing Always On VPN is a transformative step for any organization moving toward a flexible, remote-first workforce. It moves the security focus from the physical office perimeter to the individual device, providing a consistent and secure experience for the end-user.

Key Takeaways:

1. Transparency is Productivity: AOVPN succeeds because it is invisible to the user. By removing the need for manual connection steps, you reduce support tickets and minimize the likelihood of users bypassing security controls.
2. Certificate-Based Security is Non-Negotiable: Relying on passwords for remote access is a significant risk. Always use machine and user certificates to ensure that only trusted devices and verified identities can access your network.
3. IKEv2 is the Standard: When choosing a tunneling protocol, IKEv2 is the clear winner for AOVPN due to its resilience, performance, and support for roaming between network interfaces.
4. Balance Performance and Security: Split tunneling offers the best performance, but it requires that you maintain a strong security posture on the endpoint itself to prevent the device from becoming a conduit for threats.
5. Automation is Essential: Use PowerShell and MDM tools (like Intune) to manage your VPN profiles. Manual configuration is prone to error and impossible to scale as your organization grows.
6. Lifecycle Management Matters: AOVPN is a living system. You must proactively manage certificate renewals, gateway patches, and access policies to keep the system secure and reliable over time.
7. Monitor and Audit: The VPN gateway is the front door to your network. Use detailed logging and centralized monitoring to detect anomalies and respond to potential threats before they escalate into breaches.

By following these principles, you can build a remote access solution that is as reliable as the office network while providing the flexibility that modern employees demand. Always remember that the goal is to make the remote connection feel like a natural extension of the office, effectively removing the barriers to secure work.