So now that we have our baseline server configuration completed,
we need to move on to the task of fine tuning and optimization.
As I mentioned before,
the default configuration leaves a little bit to be desired.
It's probably not quite ready for production deployment just yet.
We're going to pay specific attention to detail on a couple of different things.
So first of all, we want to perform some additional
configuration, specifically on VPN ports. So by default,
the number of VPN ports supported is 128, and that may or may not work for you.
I don't know. If you're going to support 2000 concurrent connections, then
obviously that's not going to work, so we will need to change those numbers a
bit. Also, you may only be supporting 10 or 15 connections; 128 is certainly
going to work, but maybe not necessary, so we'll adjust those to meet our
specific requirements. And we're going to disable a bunch of the other
protocols and ports that we are not using just as a kind of a security
hardening exercise.
IPsec policy, so IPsec policy by default and out of the box,
even in Windows Server 2022 is really,
really poor, and I'm going to demonstrate that a little bit later.
We're going to update these default security parameters so that
they are using kind of industry standard best practices there,
minimum best practices for that.
The root certificate needs to be defined, specifically for device‑based
connections, because the VPN server performs authentication for those. And it
will accept a device certificate from any issuing CA or root CA, I should say,
that it trusts. By default, Windows ships with a bunch of root CA certificates
that you may or may not trust, and it's certainly not going to ship with your
enterprise PKI root certificate.
So we're going to make sure that we tell our RRAS, hey, when
a device‑based connection is established,
it must present a certificate from our internal trusted private
PKI, and we're going to do that by defining the root
certificate, or the Root of Trust there. Also, we're going to
enable IKEv2 fragmentation support.
IKEv2 fragmentation is a real challenge because during the IKE
authentication exchange, initial handshake, some of those packets can
get quite large, and they can exceed the path MTU. So something in the
path doesn't expect or doesn't allow a packet of that size. Let's say
it exceeds 1500 bytes, let's say it's 17,
1800, maybe even 2 or 3 K, we don't know. But they can be
quite large, and generally what happens is when UDP sends
these packets down the stack,
the IP layer has to fragment them, and it chops it up and sends it on its way.
The problem here is that many firewalls block fragmented IP packets
because it's a security risk. And so in this case, IKEv2 fails. And it
may not work reliably; sometimes it works,
sometimes it doesn't. It really depends on what path
you're taking to get to the VPN server.
So by enabling IKEv2 fragmentation support on the RRAS server,
we tell IKE to perform the fragmentation as opposed to the IP layer.
So IKE realizes,
hey I'm going to exchange all of these packets with my peer and they're really,
really large,
so I'm going to go ahead and chop it up and send it down to IP so that IP
does not have to fragment it, and then it works much more stably. And then
finally, we're going to enable revocation checking.
This is interesting because there's going to be a time when
a device with a valid certificate is in the field and you
may not want it to connect.
So maybe it's a terminated employee. Maybe it's an endpoint that's been
compromised or lost or stolen, and you want to prevent it from accessing the
infrastructure, but it still has a valid certificate.
So in this case, the administrator will go to the
issuing CA, revoke the device certificate,
clear the revocation caches everywhere, and then, of course, expect that the
device will not be able to connect. But there's an additional step. In RRAS,
you must explicitly enable revocation checking because it's not enabled by
default, and that's obviously problematic.
Also, there are some updates required to support that. So it's
supported all the way back to Windows Server 2016, but there are
some updates that are required for that.
If you have an even remotely updated Windows server, you're in good shape.
These updates for revocation checking came out quite a
long time ago. But at the end of the day,
just know if you have a server that you've built
recently and it's fully up to date, you've got all the updates that you need to support that.