Introduction

This blog post is slightly different from my usual content which focuses on how-to walkthroughs. I am going to open up about my experience/frustrations and maybe some love of Microsofts Always On VPN technology and how this feels like a pinnacle part of my project experience as a technical consultant.

I have had the joy of rolling out a number of these projects in the educational sector from a simple single-site to multi-site deployments with multi-tier PKI infrastructure etc. This blog post has come about as I face a new deployment in the financial sector which ups the security notch to factor 10 where everything will be scrutinized and carefully cross-examined before any potential sign-offs.

What is Always On VPN

Always On VPN allows your corporate users on mobile corporate devices to automatically connect to your internal network from outside (as if they never left the domain network/LAN). Direct Access was a legacy version of this that utilised IPv6 technology and wasn't as flexible or powerful as Always On for Windows 10/11. But was easier to deploy, to a degree!

Always On has no fancy server role dedicated to it or flash configuration GUI, you need to plan and configure all the individual components (listed below) with a bunch of PowerShell scripts/VPN policy configuration required here and there.

Theres two tunnel types with Always ON, Device Tunnel and User Tunnel.

Device Tunnel allows for a tunnel to form in the device context before a user even logs in to the machine. This can allow for connectivity to backend systems such as domain controllers/DNS/WSUS and management systems (limited).

User tunnel connects in the user context after login to the OS and allows more access to required backend systems (file/application servers).

All these tunnels seamlessly work when the machine is outside of the internal network.

The pinnacle of system administration Projects?

When I first got introduced to this it blew my mind and it sure was a test of my skills. I am nowhere near perfect and out of everything on the lists below, and if my managers ever read this (one in particular), they will strongly agree my Certificate Authority skills can be somewhat lacking, especially when it comes to publishing CRLS via IIS in two-tier PKI infrastructures. (I am slowly getting over this hurdle).

I think for many, working with this technology is like a love/hate relationship, maybe, and I believe this is near the pinnacle of system administration experience as far as my consultancy projects experience has taken me (Thus far).

This technology comes with so many moving parts that if you can effectively pull this off you prove your expertise/mastery in most areas. You need a firm grasp of the following topics to stand a chance with this beast the below is purely from a Windows Server standpoint:

• Active Directory Domain Services/GPO Management

  • Security Groups

  • GPO deployments (Legacy Method)

• Active Directory Certificate Services - PKI infrastructures

  • Root CA

  • Subordinate CA (2-tier PKI)

  • CRL Distributions

  • Certificate templates

• IIS Web server

  • External/Internal CRL Distribution Sites

• RRAS

  • VPN Endpoints

  • VPN Policy Profiles

  • IKEv2/SSTP

• Network Policy Server (NPS)

  • Network Policy

  • NPS Extension into Azure (Optional MFA capabilities)

  • Radius Clients

Theres then the networking considerations such as:

• Firewall policies

• Front End/Backend DMZ configurations

• NAT translation to Internal Services

• External DNS publishing

• NLS Detection

• External SSL certificates (Optional)

• VPN tunnels (Device Tunnel/User Tunnel)

• Load traffic balancing - Azure Traffic Manager?

• VPN profiles

But wait! that's not all if you make use of Intune/SCCM device management for your client endpoints the list continues:

• PKCS/SCEP certificate deployments

• Intune device configurations (VPN profiles/tunnel types)

I've probably missed a few off the list, but as you can see, this requires knowledge of ALOT of different areas and it's not something you can just walk in without a solid thought process and plan.

It can then get far more complicated based on what a customer wants or needs. Take the financial sector, for example, a single-tier ROOT CA is not going to suffice from a security standpoint. Best Practice? Take that Root Offline and have subordinate CAs. Straight away you're adding tiers of complexity. Do you need a failover with that sir/ma'am? Well, in that case, you're also going to need 2x NPS and 2x RASS servers. How do you wish to distribute your traffic, Azure traffic manager? oh, there are three sites? Times all the above by three. How many VPN tunnels do you require? Do you require device tunnel capability (pre-logon) or just user VPN (post-logon)? The number of tunnels = the number of VPN profiles required and deployments.

Summary

But despite the daunting task of even getting this running and then the potentially painful troubleshooting of all the moving parts in the machine, I have this sick love for the technology. How it works and what you achieve as the end goal is pretty damn cool. It also catapults your understanding of the above and how it all fits together to form a well-oiled machine. It's not so bad for the troubleshooting skills either when trying to pinpoint the exact location of the broken cog in a wider machine.

So what do you think? Is Always On a pinnacle of Sys Administration projects? Do you know any other projects that are far more daunting with this complexity? let me know in the comments section

I do hope to bring some walkthroughs to my Blog for Always On VPN so watch this space.