Welcome back to the deep dive. Okay, so if you're running a modern organization, you know your workforce isn't just at their desks anymore. They're everywhere and securing that remote access. It's absolutely mission critical. Today we are really digging into the secure backbone that makes all this productive mobility possible. We're talking always on VPN on Windows AOVPN, and look, this isn't just some it plumbing issue. We're discussing this
as well. It's the essential infrastructure keeping sensitive data safe when people work from anywhere.
That's exactly right. And for anyone out there needing to get up to speed on this tech quickly, the basic idea is still the same. You're setting up a secure encrypted tunnel right over the public Internet. Simple concept. But how Microsoft actually does that today, well, compared to even five, certainly ten years ago, it's quite different. We're leaning on Richard M. Hicks implementation guides here, really good stuff to
kind of cut through the noise. We'll focus on the architecture, the protocols involved, and those key design choices you really need to understand.
Okay, let's start with some context. Then, why do we even need AOVPN? I mean, what was wrong with the old waste Because let's be honest, the traditional VPN experience was well, frankly, it could be pretty miserable.
Miserable is maybe putting it mildly. Sometimes, Yeah, the old model it needed you to do something you had to remember, Okay, click the button, then type your username, then your password, and then often you know, manually punch in an MFA code or pin. Sometimes that meant digging out a physical hardware token.
Even oh, I remember those days fumbling for the token and that friction. It's not just annoying for one person, Multiply that across hundreds thousands of employees multiple times a day. The lost productivity adds up fast.
It's huge, Chris precisely, and that's really why Microsoft first tried to tackle those way back around two thousand and nine. Actually with Direct Access DA, and DA was technologically quite a leap at the time. It gave users that truly transparent automatic connection. You didn't have to click anything. You just you know, opened your laptop outside the office, boom you were connected seamless.
Okay, that sounds like the dream, right, seamless access. So if direct access worked so well conceptually, why is it now? What did you call it? Effectively end of life? I mean it's still supported in Server twenty twenty two technically, So why the big shift, the big pivot over to AOVPN.
Yeah, effectively end of life is the phrase Microsoft uses. The answer really boils down to the cloud and specifically it's about architectural dependencies.
Direct access was deeply tied into classic Microsoft tech think traditional active directory domains, group policy for management and this complex piece called the Network Location Server or NLS. Okay, hold on there, the NLS. What was that doing exactly? Why was it so critical and as you say.
Complex, right, the NLS. It was basically a smart detector for am I inside or outside the corporate network.
The direct axis client would constantly try to reach this internal only nalyst web server. If it could reach it, it knew, okay, I'm inside, no VPN needed. If it couldn't reach it, it assumed it was external and automatically fired up the DA tunnel. But this reliance on the NLS, plus needing clients and servers to be joined to a traditional AD domain, well it just doesn't fit Microsoft's modern strategy.
Their focus now is all Azure Active directory cloud identity, modern management with tools like in tune DA didn't.
Align, got it. So direct access didn't fail because the always on idea was bad. It failed because its underlying structure couldn't adapt to the Azure cloud era. And AOVPN is the leaner, more modern replacement.
Exactly right. AOVPN gives you that same seamless always on field, but it's just simpler architecturally. Like take IPv six direct access required IPv six configuration, it could be complex. With AOVPN, IPD six is totally optional. You can use it, but you don't have to. And that whole trusted network detection piece, it does it much more simply now without needing that dedicated NLS server at all. That makes a lot more sense. Okay,
so the why is clear. Now let's talk about the actual plumbing before we get into protocols like SSTP and IKA two. What are the core building blocks supporting AOVPN. What's the architecture look like.
Well, first, it's worth remembering AOVPN as a concept isn't strictly Microsoft only infrastructure. You could use third party VPN gateways Cisco, pal Alto, Fortinet, whatever, as long as the protocols match up. But focusing on the typical Windows based deployment, the heart of it is the Windows VPN server role itself. That's the Routing and Remote Access Service or our RAS ah RAS.
Yeah, that's been part of Windows Server forever, it feels like, and the source material, like Hicks's guides, they really highlight how simple and cost effective it is.
Yeah, it's hard to argue with those points. It's pretty easy to install and configure, it doesn't really require super specialized networking skills, and critically for budgets, there are no extra per user or per device license costs for the VPN connection itself. Plus it scales out well. Need more capacity, just add more RAS servers behind a load balancer. Simple.
Okay, But you hinted at a downside, a potential gap in RAS. You mentioned it lacks built in modern security controls. What's missing there? What does that mean in practice?
Right? RAS is essentially well, it's kind of a basic router when you look at security features. Its main job is just establishing the connection and routing packets. Once a client authenticates and connects through RAS, by default, it can basically reach anything on the internal network that iss IP address allows RAS itself isn't doing things like health checks? You know, is this device compliant? Doesn't have current patches anti virus running. It doesn't have built in application layer
filtering either. And that lack of granular security control is precisely why you need the second key component, the Network Policy Server or NPSPF.
That's Microsoft's implementation of RADIUS right, remote authentication dial in user service. So if RAS is the router opening the door, NPS is the security guard checking credentials.
That's a great way to put it. Yeah, NPS handles the authentication and authorization piece. But and this is important specifically for user based VPN connections. When a user tries to connect their tunnel, NPS checks their credentials against active directory or maybe Azure AD nowadays, and then it looks at network policies to decide, YEP, this user is allowed to connect.
Right. That distinction is crucial, thanks for highlighting it. Because AOVPN has two tunnel types, user tunnels and device tunnels. So if the user tunnel relies on NPS and RADIUS for on authorization, how does the device tunnel work? You know, the one that connects the machine before it only even logs in how does they get authorized?
Good question. The device tunnel actually bypasses MPs and radius completely for authorization. Device based AOVPN tunnels rely exclusively on machine certificates. The Windows client presents its unique computer certificate to the RS server. If that certificate is valid and trusted by your internal public key infrastructure your PKI, then the RAS server says, okay, you're authorized. Access granted for
the tunnel. It simplifies that initial machine connection by cutting out the need for a radius exchange.
Okay. That clarifies the main pieces RAS for routing, MPs, radius for user off, searts for device off. Now we get to that big tradeoff that really impains the user experience and reliability. The protocol choice. Typically it's down to SSTP versus I Cave two. What are the pros and cons? What are we gaining or losing with each?
Yeah, this is often a key decision point. It really comes down to that classic tension reliability versus let's say top tier security standards. So first up, you've got SSTP Secure Socket Tunneling Protocol. This one's Microsoft proprietary, but its big advantage is that it uses HGDP over TLS, which means it tunnels its traffic over the standard HTTPS TCP four four three. Ah.
Okay, so because it looks just like regular secure web traffic. Yeah. The big plus for sstps that it just sails through most firewalls, even the restrictive ones.
Exactly. It's incredibly firewall friendly. You almost never have issues with SSTP getting blocked at say a hotel or a coffee shop network. Because of that, SSTP is often the go to protocol if your main goal is maximum connection reliability, especially if you users roam a lot. Then the other
main option is IKAV two Internet Key Exchange Version two. Now, this is an open standard based on ip SC and it's generally preferred if your absolute top priority is the highest level of cryptographic security.
Okay, more secure, but you mentioned a catch. IKAV two has a reputation for being less reliable. Sometimes it uses DP ports five hundred and forty five hundred, which I know can be blocked, but the source material also flags. This thing called fragmentation is a major connection killer for IKAV two.
What's that about, ugh fragmentation? Yes, that can be a huge headache with KVE two. It relates to something called path maximum transmission unit or path MTU. Basically, network packets have a maximum size. They can be K two. Especially during connection setup, can sometimes generate quite large packets. If one of these packets hits a router somewhere between the client and the VPN server, and that packet is bigger than what that router allows, it's MTU. The packet has
to be broken up, fragmented into smaller pieces. The problem is many firewalls, especially corporate ones but sometimes public ones too, are often figured to just drop fragments at IP packets. They see it as a potential security risk.
So it's like, you send a big package, the delivery service has to break it down to fit through a mail slop. Yeah, but the recipient's security system sees these broken pieces arriving separately and just throws them in the bin, thinking it's suspicious.
That's a perfect and animal way. The fragments get dropped, the necessary pieces never arrive, the connection eventually times out, and the user disease connecting then failed. Very frustrating. So yeah, while ikave two offers potentially stronger security on paper, SSTP often wins in real world deployments just because it's far more dependable across different networks.
Makes sense. Dependability is key for an always on experience. Okay, let's shift focus to the client side. Now they actually user device. How we manage these VPN profiles and settings. That's changed a lot too, hasn't it. We're moving away from old school group policy scripts. Oh.
Absolutely. The shift is almost entirely towards modern management platforms. Primarily that means Microsoft Endpoint Manager, which most people know is in Tune. So instead of the client having to check in with an on prem domain controller to get its VPN settings via GPO dot, you now deploy configuration profiles directly from the cloud using Intune. These profiles often contain custom XML defining the AOVPN connection, or you can use the built in UI and in Tune now too.
It really streamlines the administration and importantly completely decouples client configuration from the traditional ady domain dependency.
Right cloud managed configuration and central to the security of AOVPN is authentication. We mentioned certificates, especially for device tunnels. The source material Hicks work really emphasizes one critical security requirement when you deploy these searts to laptops or tablets using the Trusted Platform Module the TPM. What's the practical security benefit of forcing a certificate to use the TPM. Why is that so important?
This is a massive security enhancement. It's really non negotiable for a secure deployment in my opinion. So the TPM, it's a dedicated physical microchip on the device's motherboard, a
hardware crypto processor. When you can figure a certificate template in your PKI to require a TPM protection or use intune to deploy a cert profile that mandates it, it means the private key associated with that certificate is generated inside the TPM chip itself, and crucially, that private key is stored within the ttm's secure boundary and is designed never to leave the chip in plain text.
So even if in a Docker completely compromises the operating system gains full admin.
Rights, exactly, even with full admin rights on the machine, they cannot export that private key. The key can be used by authorized processes for cryptographic operations like authenticating the VPN connection, but it can't be copied or stolen. It drammatically increases the protection of that certificate. It basically turns the physical hardware the laptop itself into something like a hardware security token.
That's really powerful. The key is physically bound to that specific machines hardware. Okay, so the connection is established, it's authenticated securely using potentially a TPM back certificate. Now we hit that final major configuration choice that dictates the user experience. Split tunneling versus force tunneling.
Yep. This defines what traffic actually goes through the VPN tunnel once it's up. Split tunneling is generally the recommended approach these days, especially for performance and scalability. With split tunneling, you can figure the VPN profiles so that only traffic destined for your specific corporate network ranges your internal IP addresses goes over the VPN tunnel.
Right, and everything else like traffic to Microsoft three sixty five Salesforce General Web browsing that just goes directly out the user's local Internet connection doesn't touch the VPN server, correct.
And that's much better for performance. You're not hair pinning all that cloud and Internet traffic back through your corporate data center and VPN servers. As organizations move more and more apps and services to the cloud, split tunneling becomes pretty critical to maintain a good user experience and avoid bottlenecking your VPN infrastructure. Force tunneling is the complete opposite.
With force tunneling all network traffic from the cloud CI literally everything Internet browsing included is force the VPN tunnel back to the corporate network first.
Okay, why would anyone choose force tunneling then, if it hurts performance and user experience so much?
The reason is usually central security, visibility and control. If an organization has invested heavily and sophisticated security appliances on premises, maybe advanced web filters, intrusion detection systems, data loss prevention scanners, they might mandate force tunneling so that all remote user traffic passes through those central security controls before going out
to the Internet. But you absolutely pay a price for that significantly worse performance for cloud services, a potentially sluggish browsing experience for users, and much higher load on your VPN servers and your corporate internet bandwidth. It's a definite trade off. Tighter control versus user experience and scalability.
Got it, a classic security versus usability balancing act. Okay, so let's try and tie this all together now, connecting it back to that modern security philosophy. AOVPN seems clearly designed from much tighter integration with cloud services, especially Microsoft Azure.
Oh. Absolutely, that's a core design principle. AVPN has native support for things like using Azure Active Directory for user authentication. It integrates directly with Azure MFA for adding extra authentication factors, and it works with Azure conditional access policies so you can build really sophisticated rules like allow VPN connection only if the user is authenticating via Azure MFA and the
device is marked as compliant in in Tune. This integration is what really enables organizations to move towards a proper zero trust security model for remote access.
Right zero trust, verify explicitly use least privileged access, and supporting that. AOVPN offers much more granular security features than direct access ever. Did we talked about RAS being basic, but AOVPN itself, through configuration profiles, can add filtering layers.
It can, Yes, you can implement traffic filtering roles within the VPN profile pushed down by Intune. This lets admins control network access over the VPN tunnel at a pretty detailed level based on protocol like TCP or UDP specific ports or destination IP address ranges. So you could say users in this group can connect, but they can only reach these specific servers on these specific ports. There's also
application filtering. This gets even more specific. You can actually restrict VPN access so it only works for certain applications, like maybe you only allow the remote desktop client mstsc dot exc to use the tunnel, or perhaps only specific approved Windows Store app.
Wow, okay, so you can let a whole department connect, but ensure they can only use the VPN tonnel for that one legacy internal app they still need access to. Yeah, very granular. And then there's the ultimate lockdown mode lockdown VPN.
Yeah, lockdown VPN. It's typically deployed as part of a device tunnel configuration, and the name really says it all. It's a highly secure configuration where the Windows device is prevented from making any network connections. It doesn't matter if it's Wi Fi, Ethernet, cellular, unless the always on VPN device tunnel is successfully connected and active. If that secure tunnel isn't up for any reason, and the device is
effectively bricked from a networking perspective, completely offline. Very high security posture for specific use cases.
Okay, quite a journey we've taken there. Let's try and summarize this deep dive. We started with the frustrations of old manual VPNs, saw how direct access tried to solve it but got tied to legacy architecture, and then arrived at always on VPN as the modern streamline successor architecturally simpler, built around RAS servers, using MPs for user off and leveraging protocols like the reliable SSTP or the secure ie too exactly.
And the really crucial modern elements are that deep integration with Azure for identity and policy, and the emphasis on modern management through in tune, and critically that hardware based security for authentication. We spent a fair bit of time on why securing those AOVPN client certificates using the device's TPM is so important because it provides that really high level of assurance that the device itself, the hardware connecting, is legitimate and hasn't had its credential stolen.
Right. High level of assurance from the TPM brings us neatly to our final provocative thought for you, our listener, to chew on using these TPM back certificates for AOVPN device or user authentication, it's already incredibly strong. You could argue it inherently provides two factors. Something you have the physical device with its TPM locked key, and something you know, the user's Windows log in credentials or maybe a PI
protecting the key use. So it functions almost like a built in hardware level multi factor authentication.
Yeah, it's a strong argument. Yet we see organizations very frequently layering additional MFA prompts, usually Azure MFA on top of the AOVPN connection process anyway, which leads to the question we want you to think about. In a remote access scenario where you already have that high assurance from TPM back to certificate authentication, is forcing users through another separate MFA challenge always providing meaningful additional security or does
it perhaps risk contributing to MFA fatigue? You know, training users to just reflexively approve any MFA prompt they see without really thinking. Could that habit ironically make them less likely to spot and properly react to a real malicious MFA phishing attempt down the line.
It's a really interesting tension isn't it that balancing act between piling on security layers and maintaining user vigilance and usability something definitely all over. Thank you for joining us so this deep dive into the nuts and bolts Windows always on VPN. We hope this was valuable and we'll catch on the next one.