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