WEBVTT

1
00:00:00.160 --> 00:00:03.120
<v Speaker 1>Welcome back to the deep dive. Okay, so if you're

2
00:00:03.160 --> 00:00:06.519
<v Speaker 1>running a modern organization, you know your workforce isn't just

3
00:00:06.559 --> 00:00:10.560
<v Speaker 1>at their desks anymore. They're everywhere and securing that remote access.

4
00:00:10.640 --> 00:00:14.359
<v Speaker 1>It's absolutely mission critical. Today we are really digging into

5
00:00:14.400 --> 00:00:19.000
<v Speaker 1>the secure backbone that makes all this productive mobility possible.

6
00:00:19.039 --> 00:00:23.000
<v Speaker 1>We're talking always on VPN on Windows AOVPN, and look,

7
00:00:23.039 --> 00:00:25.359
<v Speaker 1>this isn't just some it plumbing issue. We're discussing this

8
00:00:25.399 --> 00:00:29.000
<v Speaker 1>as well. It's the essential infrastructure keeping sensitive data safe

9
00:00:29.039 --> 00:00:30.760
<v Speaker 1>when people work from anywhere.

10
00:00:30.800 --> 00:00:33.679
<v Speaker 2>That's exactly right. And for anyone out there needing to

11
00:00:33.679 --> 00:00:35.920
<v Speaker 2>get up to speed on this tech quickly, the basic

12
00:00:35.960 --> 00:00:38.000
<v Speaker 2>idea is still the same. You're setting up a secure

13
00:00:38.159 --> 00:00:42.000
<v Speaker 2>encrypted tunnel right over the public Internet. Simple concept. But

14
00:00:42.240 --> 00:00:46.399
<v Speaker 2>how Microsoft actually does that today, well, compared to even five,

15
00:00:46.880 --> 00:00:50.039
<v Speaker 2>certainly ten years ago, it's quite different. We're leaning on

16
00:00:50.119 --> 00:00:53.039
<v Speaker 2>Richard M. Hicks implementation guides here, really good stuff to

17
00:00:53.079 --> 00:00:55.520
<v Speaker 2>kind of cut through the noise. We'll focus on the architecture,

18
00:00:55.560 --> 00:00:58.479
<v Speaker 2>the protocols involved, and those key design choices you really

19
00:00:58.479 --> 00:00:59.240
<v Speaker 2>need to understand.

20
00:00:59.280 --> 00:01:02.039
<v Speaker 1>Okay, let's start with some context. Then, why do we

21
00:01:02.119 --> 00:01:04.599
<v Speaker 1>even need AOVPN? I mean, what was wrong with the

22
00:01:04.599 --> 00:01:07.799
<v Speaker 1>old waste Because let's be honest, the traditional VPN experience

23
00:01:07.920 --> 00:01:10.719
<v Speaker 1>was well, frankly, it could be pretty miserable.

24
00:01:10.879 --> 00:01:15.159
<v Speaker 2>Miserable is maybe putting it mildly. Sometimes, Yeah, the old

25
00:01:15.200 --> 00:01:18.400
<v Speaker 2>model it needed you to do something you had to remember, Okay,

26
00:01:18.439 --> 00:01:21.959
<v Speaker 2>click the button, then type your username, then your password,

27
00:01:22.560 --> 00:01:25.319
<v Speaker 2>and then often you know, manually punch in an MFA

28
00:01:25.400 --> 00:01:28.959
<v Speaker 2>code or pin. Sometimes that meant digging out a physical

29
00:01:28.959 --> 00:01:29.680
<v Speaker 2>hardware token.

30
00:01:29.719 --> 00:01:32.079
<v Speaker 1>Even oh, I remember those days fumbling for the token

31
00:01:32.760 --> 00:01:35.760
<v Speaker 1>and that friction. It's not just annoying for one person,

32
00:01:35.840 --> 00:01:40.040
<v Speaker 1>Multiply that across hundreds thousands of employees multiple times a day.

33
00:01:40.359 --> 00:01:42.120
<v Speaker 1>The lost productivity adds up fast.

34
00:01:42.200 --> 00:01:46.239
<v Speaker 2>It's huge, Chris precisely, and that's really why Microsoft first

35
00:01:46.239 --> 00:01:48.439
<v Speaker 2>tried to tackle those way back around two thousand and nine.

36
00:01:48.480 --> 00:01:52.879
<v Speaker 2>Actually with Direct Access DA, and DA was technologically quite

37
00:01:52.879 --> 00:01:54.959
<v Speaker 2>a leap at the time. It gave users that truly

38
00:01:55.000 --> 00:01:57.599
<v Speaker 2>transparent automatic connection. You didn't have to click anything. You

39
00:01:57.680 --> 00:02:00.280
<v Speaker 2>just you know, opened your laptop outside the office, boom

40
00:02:00.319 --> 00:02:01.680
<v Speaker 2>you were connected seamless.

41
00:02:01.799 --> 00:02:05.040
<v Speaker 1>Okay, that sounds like the dream, right, seamless access. So

42
00:02:06.200 --> 00:02:09.919
<v Speaker 1>if direct access worked so well conceptually, why is it now?

43
00:02:10.039 --> 00:02:12.560
<v Speaker 1>What did you call it? Effectively end of life? I

44
00:02:12.599 --> 00:02:15.159
<v Speaker 1>mean it's still supported in Server twenty twenty two technically,

45
00:02:15.520 --> 00:02:18.360
<v Speaker 1>So why the big shift, the big pivot over to AOVPN.

46
00:02:18.479 --> 00:02:21.360
<v Speaker 2>Yeah, effectively end of life is the phrase Microsoft uses.

47
00:02:21.479 --> 00:02:25.120
<v Speaker 2>The answer really boils down to the cloud and specifically

48
00:02:25.120 --> 00:02:26.759
<v Speaker 2>it's about architectural dependencies.

49
00:02:27.159 --> 00:02:30.639
<v Speaker 1>Direct access was deeply tied into classic Microsoft tech think

50
00:02:30.680 --> 00:02:34.240
<v Speaker 1>traditional active directory domains, group policy for management and this

51
00:02:34.879 --> 00:02:38.199
<v Speaker 1>complex piece called the Network Location Server or NLS. Okay,

52
00:02:38.199 --> 00:02:40.599
<v Speaker 1>hold on there, the NLS. What was that doing exactly?

53
00:02:40.639 --> 00:02:43.520
<v Speaker 1>Why was it so critical and as you say.

54
00:02:43.439 --> 00:02:46.800
<v Speaker 2>Complex, right, the NLS. It was basically a smart detector

55
00:02:46.840 --> 00:02:49.680
<v Speaker 2>for am I inside or outside the corporate network.

56
00:02:49.759 --> 00:02:52.240
<v Speaker 1>The direct axis client would constantly try to reach this

57
00:02:52.439 --> 00:02:55.280
<v Speaker 1>internal only nalyst web server. If it could reach it,

58
00:02:55.280 --> 00:02:58.919
<v Speaker 1>it knew, okay, I'm inside, no VPN needed. If it

59
00:02:58.960 --> 00:03:01.400
<v Speaker 1>couldn't reach it, it assumed it was external and automatically

60
00:03:01.439 --> 00:03:04.680
<v Speaker 1>fired up the DA tunnel. But this reliance on the NLS,

61
00:03:04.800 --> 00:03:07.159
<v Speaker 1>plus needing clients and servers to be joined to a

62
00:03:07.199 --> 00:03:11.360
<v Speaker 1>traditional AD domain, well it just doesn't fit Microsoft's modern strategy.

63
00:03:11.479 --> 00:03:15.039
<v Speaker 1>Their focus now is all Azure Active directory cloud identity,

64
00:03:15.159 --> 00:03:18.840
<v Speaker 1>modern management with tools like in tune DA didn't.

65
00:03:18.599 --> 00:03:21.960
<v Speaker 2>Align, got it. So direct access didn't fail because the

66
00:03:22.080 --> 00:03:25.240
<v Speaker 2>always on idea was bad. It failed because its underlying

67
00:03:25.280 --> 00:03:29.159
<v Speaker 2>structure couldn't adapt to the Azure cloud era. And AOVPN

68
00:03:29.400 --> 00:03:31.280
<v Speaker 2>is the leaner, more modern replacement.

69
00:03:31.520 --> 00:03:35.159
<v Speaker 1>Exactly right. AOVPN gives you that same seamless always on field,

70
00:03:35.159 --> 00:03:39.319
<v Speaker 1>but it's just simpler architecturally. Like take IPv six direct

71
00:03:39.360 --> 00:03:43.199
<v Speaker 1>access required IPv six configuration, it could be complex. With AOVPN,

72
00:03:43.280 --> 00:03:45.479
<v Speaker 1>IPD six is totally optional. You can use it, but

73
00:03:45.520 --> 00:03:48.039
<v Speaker 1>you don't have to. And that whole trusted network detection piece,

74
00:03:48.080 --> 00:03:50.319
<v Speaker 1>it does it much more simply now without needing that

75
00:03:50.360 --> 00:03:54.080
<v Speaker 1>dedicated NLS server at all. That makes a lot more sense. Okay,

76
00:03:54.080 --> 00:03:56.319
<v Speaker 1>so the why is clear. Now let's talk about the

77
00:03:56.360 --> 00:03:59.599
<v Speaker 1>actual plumbing before we get into protocols like SSTP and

78
00:03:59.680 --> 00:04:04.360
<v Speaker 1>IKA two. What are the core building blocks supporting AOVPN.

79
00:04:04.520 --> 00:04:05.840
<v Speaker 1>What's the architecture look like.

80
00:04:05.919 --> 00:04:08.960
<v Speaker 2>Well, first, it's worth remembering AOVPN as a concept isn't

81
00:04:09.000 --> 00:04:13.120
<v Speaker 2>strictly Microsoft only infrastructure. You could use third party VPN

82
00:04:13.199 --> 00:04:16.319
<v Speaker 2>gateways Cisco, pal Alto, Fortinet, whatever, as long as the

83
00:04:16.319 --> 00:04:20.439
<v Speaker 2>protocols match up. But focusing on the typical Windows based deployment,

84
00:04:20.800 --> 00:04:23.759
<v Speaker 2>the heart of it is the Windows VPN server role itself.

85
00:04:24.040 --> 00:04:26.759
<v Speaker 2>That's the Routing and Remote Access Service or our RAS

86
00:04:27.120 --> 00:04:28.079
<v Speaker 2>ah RAS.

87
00:04:28.480 --> 00:04:30.920
<v Speaker 1>Yeah, that's been part of Windows Server forever, it feels like,

88
00:04:31.240 --> 00:04:34.439
<v Speaker 1>and the source material, like Hicks's guides, they really highlight

89
00:04:34.480 --> 00:04:36.040
<v Speaker 1>how simple and cost effective it is.

90
00:04:36.439 --> 00:04:39.240
<v Speaker 2>Yeah, it's hard to argue with those points. It's pretty

91
00:04:39.279 --> 00:04:41.839
<v Speaker 2>easy to install and configure, it doesn't really require super

92
00:04:41.839 --> 00:04:45.439
<v Speaker 2>specialized networking skills, and critically for budgets, there are no

93
00:04:45.600 --> 00:04:48.600
<v Speaker 2>extra per user or per device license costs for the

94
00:04:48.639 --> 00:04:52.800
<v Speaker 2>VPN connection itself. Plus it scales out well. Need more capacity,

95
00:04:53.120 --> 00:04:56.240
<v Speaker 2>just add more RAS servers behind a load balancer. Simple.

96
00:04:56.519 --> 00:04:59.720
<v Speaker 1>Okay, But you hinted at a downside, a potential gap

97
00:04:59.800 --> 00:05:04.040
<v Speaker 1>in RAS. You mentioned it lacks built in modern security controls.

98
00:05:04.319 --> 00:05:06.560
<v Speaker 1>What's missing there? What does that mean in practice?

99
00:05:06.720 --> 00:05:09.399
<v Speaker 2>Right? RAS is essentially well, it's kind of a basic

100
00:05:09.439 --> 00:05:11.759
<v Speaker 2>router when you look at security features. Its main job

101
00:05:11.839 --> 00:05:14.800
<v Speaker 2>is just establishing the connection and routing packets. Once a

102
00:05:14.839 --> 00:05:18.399
<v Speaker 2>client authenticates and connects through RAS, by default, it can

103
00:05:18.439 --> 00:05:21.000
<v Speaker 2>basically reach anything on the internal network that iss IP

104
00:05:21.120 --> 00:05:24.720
<v Speaker 2>address allows RAS itself isn't doing things like health checks?

105
00:05:24.759 --> 00:05:28.160
<v Speaker 2>You know, is this device compliant? Doesn't have current patches

106
00:05:28.360 --> 00:05:31.920
<v Speaker 2>anti virus running. It doesn't have built in application layer

107
00:05:31.920 --> 00:05:35.360
<v Speaker 2>filtering either. And that lack of granular security control is

108
00:05:35.439 --> 00:05:38.639
<v Speaker 2>precisely why you need the second key component, the Network

109
00:05:38.639 --> 00:05:40.639
<v Speaker 2>Policy Server or NPSPF.

110
00:05:40.639 --> 00:05:44.160
<v Speaker 1>That's Microsoft's implementation of RADIUS right, remote authentication dial in

111
00:05:44.319 --> 00:05:47.240
<v Speaker 1>user service. So if RAS is the router opening the door,

112
00:05:47.600 --> 00:05:49.920
<v Speaker 1>NPS is the security guard checking credentials.

113
00:05:50.000 --> 00:05:52.480
<v Speaker 2>That's a great way to put it. Yeah, NPS handles

114
00:05:52.480 --> 00:05:56.360
<v Speaker 2>the authentication and authorization piece. But and this is important

115
00:05:56.399 --> 00:05:59.959
<v Speaker 2>specifically for user based VPN connections. When a user tries

116
00:06:00.199 --> 00:06:03.600
<v Speaker 2>to connect their tunnel, NPS checks their credentials against active

117
00:06:03.639 --> 00:06:06.600
<v Speaker 2>directory or maybe Azure AD nowadays, and then it looks

118
00:06:06.639 --> 00:06:09.519
<v Speaker 2>at network policies to decide, YEP, this user is allowed

119
00:06:09.519 --> 00:06:09.959
<v Speaker 2>to connect.

120
00:06:10.079 --> 00:06:13.160
<v Speaker 1>Right. That distinction is crucial, thanks for highlighting it. Because

121
00:06:13.199 --> 00:06:17.399
<v Speaker 1>AOVPN has two tunnel types, user tunnels and device tunnels.

122
00:06:18.240 --> 00:06:21.399
<v Speaker 1>So if the user tunnel relies on NPS and RADIUS

123
00:06:21.720 --> 00:06:25.360
<v Speaker 1>for on authorization, how does the device tunnel work? You know,

124
00:06:25.399 --> 00:06:27.240
<v Speaker 1>the one that connects the machine before it only even

125
00:06:27.240 --> 00:06:29.000
<v Speaker 1>logs in how does they get authorized?

126
00:06:29.160 --> 00:06:33.240
<v Speaker 2>Good question. The device tunnel actually bypasses MPs and radius

127
00:06:33.279 --> 00:06:38.240
<v Speaker 2>completely for authorization. Device based AOVPN tunnels rely exclusively on

128
00:06:38.319 --> 00:06:42.120
<v Speaker 2>machine certificates. The Windows client presents its unique computer certificate

129
00:06:42.120 --> 00:06:44.959
<v Speaker 2>to the RS server. If that certificate is valid and

130
00:06:45.000 --> 00:06:48.680
<v Speaker 2>trusted by your internal public key infrastructure your PKI, then

131
00:06:48.720 --> 00:06:52.040
<v Speaker 2>the RAS server says, okay, you're authorized. Access granted for

132
00:06:52.079 --> 00:06:54.839
<v Speaker 2>the tunnel. It simplifies that initial machine connection by cutting

133
00:06:54.839 --> 00:06:56.600
<v Speaker 2>out the need for a radius exchange.

134
00:06:56.800 --> 00:07:00.360
<v Speaker 1>Okay. That clarifies the main pieces RAS for routing, MPs,

135
00:07:00.439 --> 00:07:03.800
<v Speaker 1>radius for user off, searts for device off. Now we

136
00:07:03.800 --> 00:07:06.000
<v Speaker 1>get to that big tradeoff that really impains the user

137
00:07:06.040 --> 00:07:09.879
<v Speaker 1>experience and reliability. The protocol choice. Typically it's down to

138
00:07:10.079 --> 00:07:13.480
<v Speaker 1>SSTP versus I Cave two. What are the pros and cons?

139
00:07:13.560 --> 00:07:15.079
<v Speaker 1>What are we gaining or losing with each?

140
00:07:15.360 --> 00:07:17.519
<v Speaker 2>Yeah, this is often a key decision point. It really

141
00:07:17.560 --> 00:07:20.959
<v Speaker 2>comes down to that classic tension reliability versus let's say

142
00:07:21.000 --> 00:07:24.279
<v Speaker 2>top tier security standards. So first up, you've got SSTP

143
00:07:25.000 --> 00:07:28.879
<v Speaker 2>Secure Socket Tunneling Protocol. This one's Microsoft proprietary, but its

144
00:07:28.879 --> 00:07:31.759
<v Speaker 2>big advantage is that it uses HGDP over TLS, which

145
00:07:31.800 --> 00:07:35.040
<v Speaker 2>means it tunnels its traffic over the standard HTTPS TCP

146
00:07:35.120 --> 00:07:36.160
<v Speaker 2>four four three. Ah.

147
00:07:36.160 --> 00:07:39.199
<v Speaker 1>Okay, so because it looks just like regular secure web traffic. Yeah.

148
00:07:39.240 --> 00:07:41.600
<v Speaker 1>The big plus for sstps that it just sails through

149
00:07:41.639 --> 00:07:43.319
<v Speaker 1>most firewalls, even the restrictive ones.

150
00:07:43.680 --> 00:07:47.120
<v Speaker 2>Exactly. It's incredibly firewall friendly. You almost never have issues

151
00:07:47.120 --> 00:07:50.120
<v Speaker 2>with SSTP getting blocked at say a hotel or a

152
00:07:50.160 --> 00:07:53.240
<v Speaker 2>coffee shop network. Because of that, SSTP is often the

153
00:07:53.279 --> 00:07:56.519
<v Speaker 2>go to protocol if your main goal is maximum connection reliability,

154
00:07:56.560 --> 00:07:59.279
<v Speaker 2>especially if you users roam a lot. Then the other

155
00:07:59.319 --> 00:08:03.439
<v Speaker 2>main option is IKAV two Internet Key Exchange Version two. Now,

156
00:08:03.439 --> 00:08:06.160
<v Speaker 2>this is an open standard based on ip SC and

157
00:08:06.199 --> 00:08:09.199
<v Speaker 2>it's generally preferred if your absolute top priority is the

158
00:08:09.279 --> 00:08:11.079
<v Speaker 2>highest level of cryptographic security.

159
00:08:11.160 --> 00:08:14.360
<v Speaker 1>Okay, more secure, but you mentioned a catch. IKAV two

160
00:08:14.399 --> 00:08:17.800
<v Speaker 1>has a reputation for being less reliable. Sometimes it uses

161
00:08:17.959 --> 00:08:19.959
<v Speaker 1>DP ports five hundred and forty five hundred, which I

162
00:08:19.959 --> 00:08:22.240
<v Speaker 1>know can be blocked, but the source material also flags.

163
00:08:22.279 --> 00:08:24.600
<v Speaker 1>This thing called fragmentation is a major connection killer for

164
00:08:24.639 --> 00:08:25.279
<v Speaker 1>IKAV two.

165
00:08:25.680 --> 00:08:28.560
<v Speaker 2>What's that about, ugh fragmentation? Yes, that can be a

166
00:08:28.680 --> 00:08:32.360
<v Speaker 2>huge headache with KVE two. It relates to something called

167
00:08:32.480 --> 00:08:36.799
<v Speaker 2>path maximum transmission unit or path MTU. Basically, network packets

168
00:08:36.799 --> 00:08:39.919
<v Speaker 2>have a maximum size. They can be K two. Especially

169
00:08:39.960 --> 00:08:43.440
<v Speaker 2>during connection setup, can sometimes generate quite large packets. If

170
00:08:43.440 --> 00:08:45.799
<v Speaker 2>one of these packets hits a router somewhere between the

171
00:08:45.879 --> 00:08:49.360
<v Speaker 2>client and the VPN server, and that packet is bigger

172
00:08:49.440 --> 00:08:52.360
<v Speaker 2>than what that router allows, it's MTU. The packet has

173
00:08:52.399 --> 00:08:55.440
<v Speaker 2>to be broken up, fragmented into smaller pieces. The problem

174
00:08:55.519 --> 00:08:59.320
<v Speaker 2>is many firewalls, especially corporate ones but sometimes public ones too,

175
00:08:59.360 --> 00:09:02.600
<v Speaker 2>are often figured to just drop fragments at IP packets.

176
00:09:02.960 --> 00:09:05.200
<v Speaker 2>They see it as a potential security risk.

177
00:09:05.559 --> 00:09:07.360
<v Speaker 1>So it's like, you send a big package, the delivery

178
00:09:07.360 --> 00:09:08.799
<v Speaker 1>service has to break it down to fit through a

179
00:09:08.840 --> 00:09:12.159
<v Speaker 1>mail slop. Yeah, but the recipient's security system sees these

180
00:09:12.159 --> 00:09:14.960
<v Speaker 1>broken pieces arriving separately and just throws them in the bin,

181
00:09:15.240 --> 00:09:16.279
<v Speaker 1>thinking it's suspicious.

182
00:09:16.440 --> 00:09:18.639
<v Speaker 2>That's a perfect and animal way. The fragments get dropped,

183
00:09:18.799 --> 00:09:22.000
<v Speaker 2>the necessary pieces never arrive, the connection eventually times out,

184
00:09:22.480 --> 00:09:28.039
<v Speaker 2>and the user disease connecting then failed. Very frustrating. So yeah,

185
00:09:28.080 --> 00:09:31.960
<v Speaker 2>while ikave two offers potentially stronger security on paper, SSTP

186
00:09:32.159 --> 00:09:34.960
<v Speaker 2>often wins in real world deployments just because it's far

187
00:09:35.039 --> 00:09:36.919
<v Speaker 2>more dependable across different networks.

188
00:09:37.039 --> 00:09:40.639
<v Speaker 1>Makes sense. Dependability is key for an always on experience. Okay,

189
00:09:40.679 --> 00:09:42.960
<v Speaker 1>let's shift focus to the client side. Now they actually

190
00:09:43.039 --> 00:09:46.320
<v Speaker 1>user device. How we manage these VPN profiles and settings.

191
00:09:46.320 --> 00:09:48.480
<v Speaker 1>That's changed a lot too, hasn't it. We're moving away

192
00:09:48.879 --> 00:09:51.120
<v Speaker 1>from old school group policy scripts. Oh.

193
00:09:51.120 --> 00:09:55.320
<v Speaker 2>Absolutely. The shift is almost entirely towards modern management platforms.

194
00:09:55.559 --> 00:09:58.759
<v Speaker 2>Primarily that means Microsoft Endpoint Manager, which most people know

195
00:09:58.879 --> 00:10:01.480
<v Speaker 2>is in Tune. So instead of the client having to

196
00:10:01.519 --> 00:10:03.600
<v Speaker 2>check in with an on prem domain controller to get

197
00:10:03.600 --> 00:10:07.279
<v Speaker 2>its VPN settings via GPO dot, you now deploy configuration

198
00:10:07.360 --> 00:10:11.000
<v Speaker 2>profiles directly from the cloud using Intune. These profiles often

199
00:10:11.000 --> 00:10:14.879
<v Speaker 2>contain custom XML defining the AOVPN connection, or you can

200
00:10:14.960 --> 00:10:17.000
<v Speaker 2>use the built in UI and in Tune now too.

201
00:10:17.440 --> 00:10:22.000
<v Speaker 2>It really streamlines the administration and importantly completely decouples client

202
00:10:22.039 --> 00:10:25.399
<v Speaker 2>configuration from the traditional ady domain dependency.

203
00:10:25.080 --> 00:10:28.360
<v Speaker 1>Right cloud managed configuration and central to the security of

204
00:10:28.360 --> 00:10:33.240
<v Speaker 1>AOVPN is authentication. We mentioned certificates, especially for device tunnels.

205
00:10:33.320 --> 00:10:36.919
<v Speaker 1>The source material Hicks work really emphasizes one critical security

206
00:10:36.960 --> 00:10:39.960
<v Speaker 1>requirement when you deploy these searts to laptops or tablets

207
00:10:40.240 --> 00:10:43.320
<v Speaker 1>using the Trusted Platform Module the TPM. What's the practical

208
00:10:43.320 --> 00:10:46.399
<v Speaker 1>security benefit of forcing a certificate to use the TPM.

209
00:10:46.440 --> 00:10:47.440
<v Speaker 1>Why is that so important?

210
00:10:47.799 --> 00:10:50.759
<v Speaker 2>This is a massive security enhancement. It's really non negotiable

211
00:10:50.840 --> 00:10:54.159
<v Speaker 2>for a secure deployment in my opinion. So the TPM,

212
00:10:54.360 --> 00:10:58.360
<v Speaker 2>it's a dedicated physical microchip on the device's motherboard, a

213
00:10:58.399 --> 00:11:01.799
<v Speaker 2>hardware crypto processor. When you can figure a certificate template

214
00:11:01.799 --> 00:11:05.159
<v Speaker 2>in your PKI to require a TPM protection or use

215
00:11:05.200 --> 00:11:08.320
<v Speaker 2>intune to deploy a cert profile that mandates it, it

216
00:11:08.399 --> 00:11:11.879
<v Speaker 2>means the private key associated with that certificate is generated

217
00:11:11.960 --> 00:11:16.360
<v Speaker 2>inside the TPM chip itself, and crucially, that private key

218
00:11:16.440 --> 00:11:19.679
<v Speaker 2>is stored within the ttm's secure boundary and is designed

219
00:11:19.799 --> 00:11:21.639
<v Speaker 2>never to leave the chip in plain text.

220
00:11:22.120 --> 00:11:25.080
<v Speaker 1>So even if in a Docker completely compromises the operating

221
00:11:25.120 --> 00:11:27.120
<v Speaker 1>system gains full admin.

222
00:11:26.879 --> 00:11:30.080
<v Speaker 2>Rights, exactly, even with full admin rights on the machine,

223
00:11:30.120 --> 00:11:32.759
<v Speaker 2>they cannot export that private key. The key can be

224
00:11:32.879 --> 00:11:36.559
<v Speaker 2>used by authorized processes for cryptographic operations like authenticating the

225
00:11:36.639 --> 00:11:39.639
<v Speaker 2>VPN connection, but it can't be copied or stolen. It

226
00:11:39.720 --> 00:11:43.559
<v Speaker 2>drammatically increases the protection of that certificate. It basically turns

227
00:11:43.559 --> 00:11:46.399
<v Speaker 2>the physical hardware the laptop itself into something like a

228
00:11:46.440 --> 00:11:48.039
<v Speaker 2>hardware security token.

229
00:11:48.080 --> 00:11:51.360
<v Speaker 1>That's really powerful. The key is physically bound to that

230
00:11:51.440 --> 00:11:56.159
<v Speaker 1>specific machines hardware. Okay, so the connection is established, it's

231
00:11:56.200 --> 00:12:01.120
<v Speaker 1>authenticated securely using potentially a TPM back certificate. Now we

232
00:12:01.200 --> 00:12:04.840
<v Speaker 1>hit that final major configuration choice that dictates the user experience.

233
00:12:05.159 --> 00:12:07.039
<v Speaker 1>Split tunneling versus force tunneling.

234
00:12:07.320 --> 00:12:10.559
<v Speaker 2>Yep. This defines what traffic actually goes through the VPN

235
00:12:10.600 --> 00:12:13.480
<v Speaker 2>tunnel once it's up. Split tunneling is generally the recommended

236
00:12:13.480 --> 00:12:17.600
<v Speaker 2>approach these days, especially for performance and scalability. With split tunneling,

237
00:12:17.639 --> 00:12:20.200
<v Speaker 2>you can figure the VPN profiles so that only traffic

238
00:12:20.240 --> 00:12:23.360
<v Speaker 2>destined for your specific corporate network ranges your internal IP

239
00:12:23.480 --> 00:12:26.000
<v Speaker 2>addresses goes over the VPN tunnel.

240
00:12:25.720 --> 00:12:28.279
<v Speaker 1>Right, and everything else like traffic to Microsoft three sixty

241
00:12:28.279 --> 00:12:31.960
<v Speaker 1>five Salesforce General Web browsing that just goes directly out

242
00:12:32.000 --> 00:12:36.039
<v Speaker 1>the user's local Internet connection doesn't touch the VPN server, correct.

243
00:12:36.159 --> 00:12:39.440
<v Speaker 2>And that's much better for performance. You're not hair pinning

244
00:12:39.480 --> 00:12:42.120
<v Speaker 2>all that cloud and Internet traffic back through your corporate

245
00:12:42.200 --> 00:12:45.799
<v Speaker 2>data center and VPN servers. As organizations move more and

246
00:12:45.879 --> 00:12:49.080
<v Speaker 2>more apps and services to the cloud, split tunneling becomes

247
00:12:49.120 --> 00:12:52.679
<v Speaker 2>pretty critical to maintain a good user experience and avoid

248
00:12:52.720 --> 00:12:57.440
<v Speaker 2>bottlenecking your VPN infrastructure. Force tunneling is the complete opposite.

249
00:12:57.559 --> 00:13:00.120
<v Speaker 2>With force tunneling all network traffic from the cloud CI

250
00:13:00.559 --> 00:13:04.279
<v Speaker 2>literally everything Internet browsing included is force the VPN tunnel

251
00:13:04.399 --> 00:13:05.840
<v Speaker 2>back to the corporate network first.

252
00:13:05.919 --> 00:13:09.080
<v Speaker 1>Okay, why would anyone choose force tunneling then, if it

253
00:13:09.159 --> 00:13:11.279
<v Speaker 1>hurts performance and user experience so much?

254
00:13:11.360 --> 00:13:14.919
<v Speaker 2>The reason is usually central security, visibility and control. If

255
00:13:14.960 --> 00:13:19.519
<v Speaker 2>an organization has invested heavily and sophisticated security appliances on premises,

256
00:13:19.840 --> 00:13:24.600
<v Speaker 2>maybe advanced web filters, intrusion detection systems, data loss prevention scanners,

257
00:13:25.039 --> 00:13:28.080
<v Speaker 2>they might mandate force tunneling so that all remote user

258
00:13:28.080 --> 00:13:31.519
<v Speaker 2>traffic passes through those central security controls before going out

259
00:13:31.519 --> 00:13:34.200
<v Speaker 2>to the Internet. But you absolutely pay a price for

260
00:13:34.240 --> 00:13:38.200
<v Speaker 2>that significantly worse performance for cloud services, a potentially sluggish

261
00:13:38.200 --> 00:13:41.440
<v Speaker 2>browsing experience for users, and much higher load on your

262
00:13:41.519 --> 00:13:45.320
<v Speaker 2>VPN servers and your corporate internet bandwidth. It's a definite

263
00:13:45.360 --> 00:13:49.039
<v Speaker 2>trade off. Tighter control versus user experience and scalability.

264
00:13:49.399 --> 00:13:53.159
<v Speaker 1>Got it, a classic security versus usability balancing act. Okay,

265
00:13:53.320 --> 00:13:55.200
<v Speaker 1>so let's try and tie this all together now, connecting

266
00:13:55.279 --> 00:13:59.200
<v Speaker 1>it back to that modern security philosophy. AOVPN seems clearly

267
00:13:59.240 --> 00:14:03.200
<v Speaker 1>designed from much tighter integration with cloud services, especially Microsoft Azure.

268
00:14:03.399 --> 00:14:07.879
<v Speaker 2>Oh. Absolutely, that's a core design principle. AVPN has native

269
00:14:07.879 --> 00:14:11.399
<v Speaker 2>support for things like using Azure Active Directory for user authentication.

270
00:14:11.879 --> 00:14:15.960
<v Speaker 2>It integrates directly with Azure MFA for adding extra authentication factors,

271
00:14:16.360 --> 00:14:19.240
<v Speaker 2>and it works with Azure conditional access policies so you

272
00:14:19.240 --> 00:14:23.200
<v Speaker 2>can build really sophisticated rules like allow VPN connection only

273
00:14:23.279 --> 00:14:26.039
<v Speaker 2>if the user is authenticating via Azure MFA and the

274
00:14:26.080 --> 00:14:29.519
<v Speaker 2>device is marked as compliant in in Tune. This integration

275
00:14:29.639 --> 00:14:32.440
<v Speaker 2>is what really enables organizations to move towards a proper

276
00:14:32.559 --> 00:14:35.240
<v Speaker 2>zero trust security model for remote access.

277
00:14:34.960 --> 00:14:39.200
<v Speaker 1>Right zero trust, verify explicitly use least privileged access, and

278
00:14:39.279 --> 00:14:42.679
<v Speaker 1>supporting that. AOVPN offers much more granular security features than

279
00:14:42.759 --> 00:14:45.480
<v Speaker 1>direct access ever. Did we talked about RAS being basic,

280
00:14:45.480 --> 00:14:49.440
<v Speaker 1>but AOVPN itself, through configuration profiles, can add filtering layers.

281
00:14:49.720 --> 00:14:52.759
<v Speaker 2>It can, Yes, you can implement traffic filtering roles within

282
00:14:52.799 --> 00:14:56.559
<v Speaker 2>the VPN profile pushed down by Intune. This lets admins

283
00:14:56.600 --> 00:14:59.399
<v Speaker 2>control network access over the VPN tunnel at a pretty

284
00:14:59.399 --> 00:15:03.080
<v Speaker 2>detailed level based on protocol like TCP or UDP specific

285
00:15:03.120 --> 00:15:06.440
<v Speaker 2>ports or destination IP address ranges. So you could say

286
00:15:06.759 --> 00:15:08.799
<v Speaker 2>users in this group can connect, but they can only

287
00:15:08.840 --> 00:15:12.360
<v Speaker 2>reach these specific servers on these specific ports. There's also

288
00:15:12.399 --> 00:15:15.320
<v Speaker 2>application filtering. This gets even more specific. You can actually

289
00:15:15.360 --> 00:15:18.279
<v Speaker 2>restrict VPN access so it only works for certain applications,

290
00:15:18.279 --> 00:15:21.600
<v Speaker 2>like maybe you only allow the remote desktop client mstsc

291
00:15:21.720 --> 00:15:26.000
<v Speaker 2>dot exc to use the tunnel, or perhaps only specific

292
00:15:26.080 --> 00:15:27.720
<v Speaker 2>approved Windows Store app.

293
00:15:27.960 --> 00:15:30.399
<v Speaker 1>Wow, okay, so you can let a whole department connect,

294
00:15:30.440 --> 00:15:32.600
<v Speaker 1>but ensure they can only use the VPN tonnel for

295
00:15:32.600 --> 00:15:35.159
<v Speaker 1>that one legacy internal app they still need access to. Yeah,

296
00:15:35.279 --> 00:15:39.159
<v Speaker 1>very granular. And then there's the ultimate lockdown mode lockdown VPN.

297
00:15:39.360 --> 00:15:42.360
<v Speaker 2>Yeah, lockdown VPN. It's typically deployed as part of a

298
00:15:42.399 --> 00:15:45.320
<v Speaker 2>device tunnel configuration, and the name really says it all.

299
00:15:45.360 --> 00:15:48.360
<v Speaker 2>It's a highly secure configuration where the Windows device is

300
00:15:48.360 --> 00:15:51.240
<v Speaker 2>prevented from making any network connections. It doesn't matter if

301
00:15:51.240 --> 00:15:55.200
<v Speaker 2>it's Wi Fi, Ethernet, cellular, unless the always on VPN

302
00:15:55.240 --> 00:15:58.759
<v Speaker 2>device tunnel is successfully connected and active. If that secure

303
00:15:58.759 --> 00:16:01.120
<v Speaker 2>tunnel isn't up for any reason, and the device is

304
00:16:01.159 --> 00:16:05.639
<v Speaker 2>effectively bricked from a networking perspective, completely offline. Very high

305
00:16:05.679 --> 00:16:07.759
<v Speaker 2>security posture for specific use cases.

306
00:16:08.200 --> 00:16:10.279
<v Speaker 1>Okay, quite a journey we've taken there. Let's try and

307
00:16:10.279 --> 00:16:13.200
<v Speaker 1>summarize this deep dive. We started with the frustrations of

308
00:16:13.200 --> 00:16:16.440
<v Speaker 1>old manual VPNs, saw how direct access tried to solve

309
00:16:16.440 --> 00:16:19.759
<v Speaker 1>it but got tied to legacy architecture, and then arrived

310
00:16:19.759 --> 00:16:24.519
<v Speaker 1>at always on VPN as the modern streamline successor architecturally simpler,

311
00:16:24.600 --> 00:16:28.240
<v Speaker 1>built around RAS servers, using MPs for user off and

312
00:16:28.360 --> 00:16:32.200
<v Speaker 1>leveraging protocols like the reliable SSTP or the secure ie

313
00:16:32.399 --> 00:16:33.399
<v Speaker 1>too exactly.

314
00:16:33.440 --> 00:16:36.240
<v Speaker 2>And the really crucial modern elements are that deep integration

315
00:16:36.360 --> 00:16:39.279
<v Speaker 2>with Azure for identity and policy, and the emphasis on

316
00:16:39.360 --> 00:16:43.039
<v Speaker 2>modern management through in tune, and critically that hardware based

317
00:16:43.039 --> 00:16:46.159
<v Speaker 2>security for authentication. We spent a fair bit of time

318
00:16:46.200 --> 00:16:49.879
<v Speaker 2>on why securing those AOVPN client certificates using the device's

319
00:16:49.919 --> 00:16:53.120
<v Speaker 2>TPM is so important because it provides that really high

320
00:16:53.200 --> 00:16:56.960
<v Speaker 2>level of assurance that the device itself, the hardware connecting,

321
00:16:57.120 --> 00:16:59.360
<v Speaker 2>is legitimate and hasn't had its credential stolen.

322
00:16:59.440 --> 00:17:02.080
<v Speaker 1>Right. High level of assurance from the TPM brings us

323
00:17:02.080 --> 00:17:04.880
<v Speaker 1>neatly to our final provocative thought for you, our listener,

324
00:17:05.160 --> 00:17:08.799
<v Speaker 1>to chew on using these TPM back certificates for AOVPN

325
00:17:08.839 --> 00:17:12.920
<v Speaker 1>device or user authentication, it's already incredibly strong. You could

326
00:17:13.000 --> 00:17:15.960
<v Speaker 1>argue it inherently provides two factors. Something you have the

327
00:17:15.960 --> 00:17:19.279
<v Speaker 1>physical device with its TPM locked key, and something you know,

328
00:17:19.680 --> 00:17:22.480
<v Speaker 1>the user's Windows log in credentials or maybe a PI

329
00:17:22.680 --> 00:17:25.279
<v Speaker 1>protecting the key use. So it functions almost like a

330
00:17:25.319 --> 00:17:27.880
<v Speaker 1>built in hardware level multi factor authentication.

331
00:17:28.119 --> 00:17:31.119
<v Speaker 2>Yeah, it's a strong argument. Yet we see organizations very

332
00:17:31.119 --> 00:17:35.640
<v Speaker 2>frequently layering additional MFA prompts, usually Azure MFA on top

333
00:17:35.680 --> 00:17:39.720
<v Speaker 2>of the AOVPN connection process anyway, which leads to the

334
00:17:39.799 --> 00:17:42.200
<v Speaker 2>question we want you to think about. In a remote

335
00:17:42.240 --> 00:17:45.119
<v Speaker 2>access scenario where you already have that high assurance from

336
00:17:45.279 --> 00:17:49.039
<v Speaker 2>TPM back to certificate authentication, is forcing users through another

337
00:17:49.160 --> 00:17:53.359
<v Speaker 2>separate MFA challenge always providing meaningful additional security or does

338
00:17:53.400 --> 00:17:57.759
<v Speaker 2>it perhaps risk contributing to MFA fatigue? You know, training

339
00:17:57.839 --> 00:18:01.920
<v Speaker 2>users to just reflexively approve any MFA prompt they see

340
00:18:02.160 --> 00:18:06.000
<v Speaker 2>without really thinking. Could that habit ironically make them less

341
00:18:06.039 --> 00:18:08.559
<v Speaker 2>likely to spot and properly react to a real malicious

342
00:18:08.640 --> 00:18:10.319
<v Speaker 2>MFA phishing attempt down the line.

343
00:18:10.440 --> 00:18:13.119
<v Speaker 1>It's a really interesting tension isn't it that balancing act

344
00:18:13.119 --> 00:18:16.160
<v Speaker 1>between piling on security layers and maintaining user vigilance and

345
00:18:16.240 --> 00:18:19.480
<v Speaker 1>usability something definitely all over. Thank you for joining us

346
00:18:19.480 --> 00:18:21.240
<v Speaker 1>so this deep dive into the nuts and bolts Windows

347
00:18:21.279 --> 00:18:23.240
<v Speaker 1>always on VPN. We hope this was valuable and we'll

348
00:18:23.240 --> 00:18:24.079
<v Speaker 1>catch on the next one.