My guide to setting up Windows Server 2019 for VPN (with no guarantees that it will work) (2024)

Sadly, I can remember setting up my first Remote Access Service (RAS) on Windows NT Server 4.0. It was a very simple process: First you added the Remote Access Service in network settings as a new service, specifying how many ports you wanted and of what types (dial-up, PPTP), then you checked a box on each account that you wanted to allow access. There were very few options, and you could set it up pretty quickly.

How times have changed. While typically you would expect this sort of thing to get easier over time, that’s certainly not the case. Sure, there are lots of additional features and capabilities, but the result is a seven-step process, where the (optional) 7th step has 5 sub-steps. So it could be a 12-step process that drives you to want to complete a different sort of 12-step process.

Technically, this process is specifically to set up the device for Always On VPN, but if you do all the steps mostly as documented (with a few tweaks) you can end up with a server that supports various types of VPN connections, authentication, etc. (The same server can support DirectAccess too, but that’s not high on my list at the moment, so I’ll skip that.)

In my case, I will set up one new server running Windows Server 2019 (fully patched). It will be joined to my existing Active Directory domain as a member server (not a DC). It has two network connections, an “internal” one with a static IP address, and an “internet” one with a DHCP-assigned address that can access anything on the internet. (The docs mention in several places to do things while logged onto a domain controller, which is kind of silly. Instead, I installed the RSAT feature on the server and did all of this while signed on as a domain admin account that had sufficient privileges for all steps.)

Before we start, I will point out one thing: Even though I’ve done this four separate times now, it has never gone smoothly. In fact, every attempt has been followed by hours or days of troubleshooting. And this case is no exception. So the documentation below describes exactly what I did, but at the end of it, nothing worked. Caveat lector.

If you aren’t the certificate person, find the certificate person. If you’re not the networking person, find the networking person. If you don’t have sufficient AD rights (e.g. Domain Admin rights), find someone that does.

Step 1

The documentation for setting all of this up is decent, but there’s a lot of it. Read through it all once before you start. Then read through step #1 again, as it’s just preparation and start off with Step 2, getting thrown right into the weeds of certificate management. Hopefully you have a working Active Directory Certificate Services infrastructure in place. If not, take a diversion and come back later.

Step 2

You can choose to follow the “Configure certificate autoenrollment in Group Policy” if you want. Personally, I manage (or co-manage) my devices with Intune, so I ignored this section because I will deploy device certs (when needed) using Intune and NDES/SCEP. I also therefore don’t care about non-domain joined computers, because they too can be managed by Intune.

That takes us to the “Create the VPN Users, VPN Servers, and NPS Servers Groups.” I have skipped these before, because it’s possible to use existing groups (e.g. Domain Users) and a specific server instead of a group, but as I’ve skipped all the other sections so far, I might as well follow this one (it prepares you for a possible future where you have multiple servers and a desire to selectively allow access) creating three groups:

• VPN Users, which I’ll put my test users in.
• VPN Servers, which will contain one server, my RRAS server.
• NPS Servers, which will have that same server in it. (You read all the docs, right? So you know that the NPS service is a RADIUS server that is used to authenticate users/devices connecting into RRAS. It can be on the same server as RRAS, and since I don’t care about scale or resiliency, that works well.)

Now back to skipping stuff. The next section, “Create the User Authentication template,” is needed specifically if you are doing GPO-driven cert auto-enrollment. I’m using Intune, so I already have an equivalent template as that’s needed for SCEP, so I’ll skip that.

But the next two steps, “Create the VPN Server Authentication template” and “Create the NPS Server Authentication template,” are essential. Make sure you follow those steps. (I don’t understand why the VPN and NPS servers need two separate certs, but there are times when you just do things anyway.)

Again, I’ll skip the user cert piece (Intune can do that later) and move on to “Enroll and validate the server certificates.” This is one of those points where you can cost yourself hours of troubleshooting if you don’t do it properly: when you enroll the VPN server certificate, it needs to use the *external* name that will be used to make the VPN connection. It can (and probably should) list any other names that it can go by, but that external name really matters. So decide what it will be. In my case, I decided to use “vpn.contosomn.com,” which I’ve defined in the external “contosomn.com” domain, pointing to the IP address of the “internet” network (which is DHCP-assigned, so if that DHCP address ever changes you’ll need to update DNS).

Also, if you haven’t rebooted your server since you added it to the VPN and NPS groups above, you might as well do that now – the cert enrollment will fail if you haven’t because the server’s computer account token doesn’t yet contain those groups otherwise.

Finally, done with step #2. Now it’s time to set up the RRAS.

Step 3

Finally, some “installing” instead of just “configuring.” And all of that is done for RRAS using a single PowerShell command (or if you really want, using Server Manager):

But then it’s back to configuring, with “Configure Remote Access as a VPN Server.” And since that is started from Server Manager, you have to launch it anyway. The docs suggest “Deploy VPN only” and that’s what I said earlier I was going to do, but if you wanted a combined DirectAccess and VPN server, you would go down a slightly different path here. You’re on your own for that one.

After you choose “Deploy VPN only” you are then in the RRAS MMC, where you need to start the configuration wizard by right-clicking on the VPN server name:

Next, you have to configure RRAS to use RADIUS, a.k.a. NPS:

I’m not entirely sure it’s necessary to put in the server name and secret, as RRAS will complain about this when NPS is running on the same server. But other than logging an event, it doesn’t hurt anything, so following the instructions is safe. (Remember the shared secret, you’ll need it later.)

The IPv4 configuration is simplest when you use internal DHCP – just select your internal network adapter at the bottom of the dialog:

Step #16 that talks about optionally configuring a certificate should select the “vpn.contosocm.com” cert enrolled previously. That saves some troubles later.

The rest of the steps are reasonably straight-forward (even if you don’t understand what they are asking). Fortunately, the “maximum ports” values are easy to change later. I chose 10 ports for L2TP, PPTP, and IKEv2, which gives me plenty of capacity to play:

Step 4

On to NPS. Again, you can use PowerShell to install it:

And then you can configure it using the NPS admin tool. I didn’t need to register it with Active Directory as that option was greyed out (perhaps an improvement in Windows Server 2019?). You’ll probably want to configure accounting (for troubleshooting) – logging to a file is the easiest.

Add the RRAS server as a RADIUS client in NPS. Since these are both on the same server, it’s just pointing the server to itself. And here’s where the shared secret comes in, so hopefully you remembered what you configured earlier.

The next step is to configure NPS to do RADIUS for VPN connections. Another wizard to start:

Follow the instructions as described. Then skip the “Autoenroll the NPS server certificate.” (It was manually enrolled earlier, it will auto-enroll on the next reboot.)

Step 5

In my case, I need to do nothing for this step. I already created the “vpn.contosomn.com” entry earlier, and I have no firewalls to worry about, my server has access to everything on the internet and intranet.

Step 6

This step is absolutely absurd. Who wants to go through all that work just to create a VPN profile on a client? This can be done later via Intune.

Step 7

This step is all about conditional access. With the “wizard fatigue” from all the previous steps, I’ll leave this one alone for now. It can be done later if needed.

Finally

Now, the question is whether it will actually work. And the answer is no, as I already pointed out. I manually joined a Windows 10 to Active Directory (while on the corporate network) and enrolled a user and device cert (nothing special, just using the standard user and computer templates). I manually create a VPN connection via Settings (PowerShell works too), and then tried to connect. And that connection failed. For any VPN troubleshooting, it seems all paths eventually lead to Richard Hicks’ website, https://directaccess.richardhicks.com/. The items that I expected to run into, because I’ve experienced them in the past:

• Always On VPN IKEv2 Policy Mismatch Error. The Windows 10 VPN security defaults are not the same as the Windows Server defaults, so you have to make sure both sides match.
• Always On VPN and Windows Server 2019 NPS Bug. While I made this adjustment, I don’t think it matters in my specific configuration, with NPS and RRAS on the same server. But I made the change anyway.

My problems were weirder: I could tell that the NPS server was getting the authentication requests, but always rejecting them. Nothing I did changed that. I could change the error (e.g. disabling my network policy), but it never successfully authenticated a client. But I certainly learned plenty from the process:

• Look in the Security event log for NPS events on the NPS server. They can get lost in the noise, but if you filter the event log on event source “Microsoft Windows security auditing.” (yes, there is a period at the end of it) and then specify task category of “Network Policy Server” you can see the interesting ones.
• Look in the Application event log for VPN (RasClient)-related events. These are very useful in cases where the connection failed, as you can see the actual error code (e.g. 812 or 691).
• Look at the System event log for RRAS-related events. These can have some useful info, but don’t be led astray – even if it says “Specifically” it’s not giving you a specific cause for the error (hence the “may not” piece of the text).
• You can manually initiate a VPN connection from the command line using RASDIAL.EXE. It might be from the early days of Windows NT 4.0, but it still works today, just specify the name of the VPN connection as a parameter, e.g. RASDIAL.EXE “CONTOSO” (without the smart quotes – use normal quotes).
• You can turn on CAPI2 event logging to get more details about certs, but generally the problem isn’t with the certs – if Windows 10 doesn’t like the cert it will ask you if you want to connect anyway (at least when you do the manual connection test from Settings).

So how did I end up fixing it? First, I installed NPS on a domain controller and configured it as described above. I used NTRadPing, a very old tool to try it out. Assuming you open up some really poorly-secured protocols (e.g. PAP, CHAP), you can use it to make sure your rules look OK. And they did.

Next, I tried to get RRAS on the original server to talk to NPS on the DC. And even after reconfiguring it to point to that new server, there were no requests being sent to the new server, and events on the RRAS server still pointing to the local machine for NPS. So I removed RRAS altogether from Server Manager and reinstalled it, then configured it to point to NPS on the DC. And it worked immediately: my Windows 10 client could authenticate and connect, using any protocol I enabled. PPTP, L2TP, and IKEv2 worked fine. User certs, device certs (with an appropriate NPS tweak to allow Domain Computers to authenticate), and username/password combinations worked. Exactly as I expected the first time I went through this process.

Next up, I’ll do the same thing using Azure VPN, just to spite RRAS and NPS, because I suspect it will take only an hour or two to set up the equivalent in the cloud. Until then, if you want to set up RRAS and NPS, you have my pity.