Please review Part 1: here for an overview.
In this part we will discuss the Architecture and design that is needed to support the always on VPN. It is very important the the underlying cloud and on-premise networking routing is efficient enough to support this. Also, this will work if all your virtual machines are in azure as well.
Where do certificates come from?
This is a simple question, and it isn’t the stork, we will need to set up some form of certificate authority. In this particular case, a 2-tier Windows Certificate Authority (Most environments will use a 2-tier architecture, but a 3-tier architecture will work here as well. I’d never recommend a 1-tier design, ever). However, if you have Intune Suite, I fully recommend using the Intune Certificate Authority that is part of that (will touch on the configuration on another post). I set up 4 total servers for this environment. 1 Server is an Offline Root, 2 Issuing Certificate Authorities and there is a server that is used for Network Device Enrollment Service.
Build it and they will come?
There are things that need to be in place first. I already had set up an Express Route, Virtual WAN, and had the routing set. On the topic of routing, when I set this up
Route Maps was only private preview with no SLA. I wasn’t going to deploy something that didn’t have support, but now, I recommend using Route Maps, will make your life easier in regards to routing.
How do we secure the CRL DP? Good question! Since we need to make sure the end clients can see the CRL DP what do we do? We leverage a
Entra ID App Proxy. This will negate the need for opening up ports and natting to the server holding the CRL DP. This increases security. How so? You don’t have to open any ports in your firewall. We will go through the specific configuration for the CA in another post.
Once the CA environment is stood up and tested, we need to then decide on the End Point. In our case it was a Point 2 Site (User VPN) in an Azure Virtual WAN Hub. Here I am assuming you have an active VWAN all ready connected. I will be going through the set up and security of VWAN, Hubs, etc in a later post series. The routing (I will touch on that later and I did previously) and the express route is already in place. I used
this tutorial roughly to set up the P2S Connection.
Neat, so it works and is tested manually, how do I get the machines to get the certificates, the vpn profile and everything else that is needed to each machine? There is an easy way right? Easy, eh, but there is a way… That way is Intune. I started with Microsoft tech docs
here and
here. Also since this is a device tunnel I used this tutorial
here. Now here is one caveat. The Enterprise version of Windows 10/11 are the only versions that support Device Tunnel, it will absolutely not work with any other version. You can either get the enterprise version via OEM or through your E5/A5 bundle or the addon.
So… What’s next?
The next part of this series will deal with the configuration of Intune and the CA templates to support deployment.
