1 00:00:02,040 --> 00:00:05,340 So now that we have our baseline server configuration completed, 2 00:00:05,340 --> 00:00:08,590 we need to move on to the task of fine tuning and optimization. 3 00:00:08,590 --> 00:00:09,800 As I mentioned before, 4 00:00:09,800 --> 00:00:12,330 the default configuration leaves a little bit to be desired. 5 00:00:12,330 --> 00:00:16,120 It's probably not quite ready for production deployment just yet. 6 00:00:16,120 --> 00:00:19,710 We're going to pay specific attention to detail on a couple of different things. 7 00:00:19,710 --> 00:00:21,840 So first of all, we want to perform some additional 8 00:00:21,840 --> 00:00:26,260 configuration, specifically on VPN ports. So by default, 9 00:00:26,260 --> 00:00:31,960 the number of VPN ports supported is 128, and that may or may not work for you. 10 00:00:31,960 --> 00:00:35,830 I don't know. If you're going to support 2000 concurrent connections, then 11 00:00:35,830 --> 00:00:39,440 obviously that's not going to work, so we will need to change those numbers a 12 00:00:39,440 --> 00:00:44,760 bit. Also, you may only be supporting 10 or 15 connections; 128 is certainly 13 00:00:44,760 --> 00:00:48,980 going to work, but maybe not necessary, so we'll adjust those to meet our 14 00:00:48,980 --> 00:00:52,850 specific requirements. And we're going to disable a bunch of the other 15 00:00:52,850 --> 00:00:57,050 protocols and ports that we are not using just as a kind of a security 16 00:00:57,050 --> 00:00:59,240 hardening exercise. 17 00:00:59,240 --> 00:01:05,150 IPsec policy, so IPsec policy by default and out of the box, 18 00:01:05,150 --> 00:01:08,510 even in Windows Server 2022 is really, 19 00:01:08,510 --> 00:01:11,130 really poor, and I'm going to demonstrate that a little bit later. 20 00:01:11,130 --> 00:01:14,070 We're going to update these default security parameters so that 21 00:01:14,070 --> 00:01:17,910 they are using kind of industry standard best practices there, 22 00:01:17,910 --> 00:01:20,240 minimum best practices for that. 23 00:01:20,240 --> 00:01:25,100 The root certificate needs to be defined, specifically for device‑based 24 00:01:25,100 --> 00:01:30,850 connections, because the VPN server performs authentication for those. And it 25 00:01:30,850 --> 00:01:36,230 will accept a device certificate from any issuing CA or root CA, I should say, 26 00:01:36,230 --> 00:01:41,420 that it trusts. By default, Windows ships with a bunch of root CA certificates 27 00:01:41,420 --> 00:01:45,550 that you may or may not trust, and it's certainly not going to ship with your 28 00:01:45,550 --> 00:01:47,460 enterprise PKI root certificate. 29 00:01:47,460 --> 00:01:51,380 So we're going to make sure that we tell our RRAS, hey, when 30 00:01:51,380 --> 00:01:53,720 a device‑based connection is established, 31 00:01:53,720 --> 00:01:59,240 it must present a certificate from our internal trusted private 32 00:01:59,240 --> 00:02:03,510 PKI, and we're going to do that by defining the root 33 00:02:03,510 --> 00:02:06,680 certificate, or the Root of Trust there. Also, we're going to 34 00:02:06,680 --> 00:02:10,070 enable IKEv2 fragmentation support. 35 00:02:10,070 --> 00:02:14,930 IKEv2 fragmentation is a real challenge because during the IKE 36 00:02:14,930 --> 00:02:20,200 authentication exchange, initial handshake, some of those packets can 37 00:02:20,200 --> 00:02:25,890 get quite large, and they can exceed the path MTU. So something in the 38 00:02:25,890 --> 00:02:31,730 path doesn't expect or doesn't allow a packet of that size. Let's say 39 00:02:31,730 --> 00:02:36,230 it exceeds 1500 bytes, let's say it's 17, 40 00:02:36,230 --> 00:02:40,530 1800, maybe even 2 or 3 K, we don't know. But they can be 41 00:02:40,530 --> 00:02:44,140 quite large, and generally what happens is when UDP sends 42 00:02:44,140 --> 00:02:46,640 these packets down the stack, 43 00:02:46,640 --> 00:02:50,880 the IP layer has to fragment them, and it chops it up and sends it on its way. 44 00:02:50,880 --> 00:02:56,000 The problem here is that many firewalls block fragmented IP packets 45 00:02:56,000 --> 00:03:01,430 because it's a security risk. And so in this case, IKEv2 fails. And it 46 00:03:01,430 --> 00:03:04,610 may not work reliably; sometimes it works, 47 00:03:04,610 --> 00:03:07,490 sometimes it doesn't. It really depends on what path 48 00:03:07,490 --> 00:03:09,360 you're taking to get to the VPN server. 49 00:03:09,360 --> 00:03:14,540 So by enabling IKEv2 fragmentation support on the RRAS server, 50 00:03:14,540 --> 00:03:19,520 we tell IKE to perform the fragmentation as opposed to the IP layer. 51 00:03:19,520 --> 00:03:21,010 So IKE realizes, 52 00:03:21,010 --> 00:03:26,210 hey I'm going to exchange all of these packets with my peer and they're really, 53 00:03:26,210 --> 00:03:26,880 really large, 54 00:03:26,880 --> 00:03:30,720 so I'm going to go ahead and chop it up and send it down to IP so that IP 55 00:03:30,720 --> 00:03:36,170 does not have to fragment it, and then it works much more stably. And then 56 00:03:36,170 --> 00:03:38,160 finally, we're going to enable revocation checking. 57 00:03:38,160 --> 00:03:41,250 This is interesting because there's going to be a time when 58 00:03:41,250 --> 00:03:44,760 a device with a valid certificate is in the field and you 59 00:03:44,760 --> 00:03:47,240 may not want it to connect. 60 00:03:47,240 --> 00:03:50,600 So maybe it's a terminated employee. Maybe it's an endpoint that's been 61 00:03:50,600 --> 00:03:56,100 compromised or lost or stolen, and you want to prevent it from accessing the 62 00:03:56,100 --> 00:03:59,210 infrastructure, but it still has a valid certificate. 63 00:03:59,210 --> 00:04:01,780 So in this case, the administrator will go to the 64 00:04:01,780 --> 00:04:04,840 issuing CA, revoke the device certificate, 65 00:04:04,840 --> 00:04:11,380 clear the revocation caches everywhere, and then, of course, expect that the 66 00:04:11,380 --> 00:04:15,540 device will not be able to connect. But there's an additional step. In RRAS, 67 00:04:15,540 --> 00:04:20,180 you must explicitly enable revocation checking because it's not enabled by 68 00:04:20,180 --> 00:04:22,870 default, and that's obviously problematic. 69 00:04:22,870 --> 00:04:27,330 Also, there are some updates required to support that. So it's 70 00:04:27,330 --> 00:04:31,810 supported all the way back to Windows Server 2016, but there are 71 00:04:31,810 --> 00:04:33,560 some updates that are required for that. 72 00:04:33,560 --> 00:04:39,200 If you have an even remotely updated Windows server, you're in good shape. 73 00:04:39,200 --> 00:04:42,650 These updates for revocation checking came out quite a 74 00:04:42,650 --> 00:04:44,500 long time ago. But at the end of the day, 75 00:04:44,500 --> 00:04:47,400 just know if you have a server that you've built 76 00:04:47,400 --> 00:04:54,000 recently and it's fully up to date, you've got all the updates that you need to support that.