1 00:00:00,040 --> 00:00:00,750 At its core, 2 00:00:00,750 --> 00:00:04,110 the Windows VPN server really is nothing more than a 3 00:00:04,110 --> 00:00:06,340 networking device; it's a router fundamentally. 4 00:00:06,340 --> 00:00:09,390 And so when you connect to the VPN server, 5 00:00:09,390 --> 00:00:11,980 that traffic needs to be routed to the internal network, 6 00:00:11,980 --> 00:00:13,140 and so forth. 7 00:00:13,140 --> 00:00:16,140 So there are some important networking considerations that have to be made 8 00:00:16,140 --> 00:00:19,910 when considering where and how to deploy our VPN server. 9 00:00:19,910 --> 00:00:21,500 First is network placement. 10 00:00:21,500 --> 00:00:24,140 Where are we going to put this VPN server? 11 00:00:24,140 --> 00:00:27,000 Well, we can put the VPN server directly on the LAN, 12 00:00:27,000 --> 00:00:29,090 put it on the internal network and call it a day, 13 00:00:29,090 --> 00:00:32,750 but you may also want to put it in a perimeter or DMZ network, 14 00:00:32,750 --> 00:00:35,160 and there are advantages and disadvantages to that, 15 00:00:35,160 --> 00:00:38,490 either way, and we'll talk about that in more detail shortly. 16 00:00:38,490 --> 00:00:42,070 Network interface configuration, again, you can do one network interface, 17 00:00:42,070 --> 00:00:43,860 which is the standard for a Windows server, 18 00:00:43,860 --> 00:00:47,810 but you can also support multi‑home with multiple network interfaces. 19 00:00:47,810 --> 00:00:51,310 For VPN client addressing, when VPN clients connect, 20 00:00:51,310 --> 00:00:52,940 they obviously need an IP address, 21 00:00:52,940 --> 00:00:57,340 we need to consider whether or not to use DHCP or a static address pool. 22 00:00:57,340 --> 00:01:00,000 And for VPN client IP subnet assignments, 23 00:01:00,000 --> 00:01:02,930 we need to decide what those subnets look like, 24 00:01:02,930 --> 00:01:07,540 what those prefixes looks like, and also make accommodations for routing. 25 00:01:07,540 --> 00:01:08,740 And finally, 26 00:01:08,740 --> 00:01:11,530 our edge firewall needs to be configured to allow traffic from 27 00:01:11,530 --> 00:01:15,440 the public internet into the VPN server itself. 28 00:01:15,440 --> 00:01:18,940 So let's talk a little bit about VPN server network placement. 29 00:01:18,940 --> 00:01:23,150 The simplest way to do this is just to put this VPN server on your network, 30 00:01:23,150 --> 00:01:24,180 join it to your domain, 31 00:01:24,180 --> 00:01:26,730 and then translate that traffic in from the 32 00:01:26,730 --> 00:01:29,760 internet from from your edge firewall, and and call it a day. 33 00:01:29,760 --> 00:01:32,060 That's probably not the best deployment model, 34 00:01:32,060 --> 00:01:34,030 and we'll talk a little bit more about that shortly. 35 00:01:34,030 --> 00:01:35,880 But in this scenario, a LAN‑based, 36 00:01:35,880 --> 00:01:39,150 domain‑joined, single‑network interface server is very simple, 37 00:01:39,150 --> 00:01:41,840 very easy to deploy, and easy to manage. 38 00:01:41,840 --> 00:01:45,160 You can also put the VPN server in a DMZ or a perimeter network, 39 00:01:45,160 --> 00:01:48,140 and here you could join it to your domain if you wish. 40 00:01:48,140 --> 00:01:49,990 That's optional in this scenario. 41 00:01:49,990 --> 00:01:53,290 Always On VPN does support workgroup‑ joined machines; you 42 00:01:53,290 --> 00:01:54,710 don't have to join it to the domain. 43 00:01:54,710 --> 00:01:57,440 And arguably, if you're going to put it in a DMZ network, 44 00:01:57,440 --> 00:01:59,590 you probably shouldn't join it to a domain anyway, 45 00:01:59,590 --> 00:02:01,940 but that's a design decision you have to make. 46 00:02:01,940 --> 00:02:04,620 But in that scenario, you can do this with a single network interface, 47 00:02:04,620 --> 00:02:06,540 and it works quite well. 48 00:02:06,540 --> 00:02:09,330 Another option available to you is to do multi‑home, 49 00:02:09,330 --> 00:02:12,930 and there's a variety of different ways you can do this. 50 00:02:12,930 --> 00:02:17,300 Some customers will put the server on the LAN with the 51 00:02:17,300 --> 00:02:19,540 network interface in the internal network, 52 00:02:19,540 --> 00:02:23,630 and then another network interface in the perimeter or DMZ network, 53 00:02:23,630 --> 00:02:26,340 and in this scenario, it's usually domain‑joined. 54 00:02:26,340 --> 00:02:29,170 Another scenario that works quite well for high‑security 55 00:02:29,170 --> 00:02:32,520 environments is when the VPN server is in a perimeter or 56 00:02:32,520 --> 00:02:34,320 DMZ network with two interfaces, 57 00:02:34,320 --> 00:02:38,200 and the external interfaces in an external‑facing DMZ, 58 00:02:38,200 --> 00:02:42,360 and the internal interface is in an internal‑facing DMZ. 59 00:02:42,360 --> 00:02:46,170 This forces traffic leaving the firewall to cross a perimeter, 60 00:02:46,170 --> 00:02:47,770 or internal firewall, 61 00:02:47,770 --> 00:02:52,740 for traffic inspection and logging before it reaches the internal network. 62 00:02:52,740 --> 00:02:55,790 Now, when our VPN clients connect to the VPN server, 63 00:02:55,790 --> 00:02:56,980 they're going to need an IP address. 64 00:02:56,980 --> 00:03:00,800 They get a virtual interface and establish a virtual 65 00:03:00,800 --> 00:03:04,230 tunnel link from the client to the gateway. 66 00:03:04,230 --> 00:03:07,260 And there are a couple of ways to perform client IP addressing. 67 00:03:07,260 --> 00:03:11,320 The first is DHCP, and while it sounds like that might work well, 68 00:03:11,320 --> 00:03:14,730 DHCP is not recommended for a couple of reasons. 69 00:03:14,730 --> 00:03:17,540 First of all, you have very limited addressing options. 70 00:03:17,540 --> 00:03:21,640 You can only assign addresses from the subnet for 71 00:03:21,640 --> 00:03:24,660 which the VPN server belongs to. 72 00:03:24,660 --> 00:03:28,930 And so, that subnet might not have enough IP addresses. 73 00:03:28,930 --> 00:03:31,390 If you're going to support a couple of thousand 74 00:03:31,390 --> 00:03:33,640 endpoints or connections per server, 75 00:03:33,640 --> 00:03:38,440 you may not have the space available in that DHCP scope to support that. 76 00:03:38,440 --> 00:03:41,480 Also, DHCP introduces another dependency, 77 00:03:41,480 --> 00:03:44,590 and if DHCP is down or fails, 78 00:03:44,590 --> 00:03:47,260 no clients will be able to connect or route or anything like that, 79 00:03:47,260 --> 00:03:48,850 so it tends to be problematic. 80 00:03:48,850 --> 00:03:51,670 Also, there's no real advantage to using it, 81 00:03:51,670 --> 00:03:56,940 simply because the clients don't lease IP addresses from the DHCP server, 82 00:03:56,940 --> 00:03:58,620 the VPN server does. 83 00:03:58,620 --> 00:04:02,890 So there's no way to do any sort of of logging or tracing to find out, 84 00:04:02,890 --> 00:04:06,190 well, who leased this specific IP address from the DHCP server? 85 00:04:06,190 --> 00:04:07,900 If you go to the DHCP server, 86 00:04:07,900 --> 00:04:11,040 you'll see that the VPN server leased a block of 25 or 87 00:04:11,040 --> 00:04:14,540 50 or 100 IP addresses and that's it. 88 00:04:14,540 --> 00:04:20,000 Also, the VPN server, by default, discards all of the options that are in DHCP, 89 00:04:20,000 --> 00:04:22,480 so there's no real advantage there to using it. 90 00:04:22,480 --> 00:04:25,480 So the recommendation is to use a static pool. 91 00:04:25,480 --> 00:04:30,150 A static pool provides you the flexibility to deploy 92 00:04:30,150 --> 00:04:32,590 as many IP addresses as you want, 93 00:04:32,590 --> 00:04:37,110 and then you're not limited by the space available on the internal subnet. 94 00:04:37,110 --> 00:04:40,720 You can also use a static address pool with a unique IP subnet, 95 00:04:40,720 --> 00:04:44,910 and this is really recommended because it does allow you to 96 00:04:44,910 --> 00:04:48,810 very easily determine where VPN client traffic is coming 97 00:04:48,810 --> 00:04:50,950 from, it's easier to see in logs, 98 00:04:50,950 --> 00:04:56,120 and identify in logs; it's also easier to just intuitively know that this 99 00:04:56,120 --> 00:04:59,470 particular traffic is coming from a VPN client subnet. 100 00:04:59,470 --> 00:05:04,940 That can be helpful for ACL and log searching and things like that. 101 00:05:04,940 --> 00:05:09,100 My recommendation also is to over provision here. 102 00:05:09,100 --> 00:05:11,400 You're carving out a unique subnet, 103 00:05:11,400 --> 00:05:14,780 a unique IP subnet that is not in use in your network. 104 00:05:14,780 --> 00:05:18,340 If you're expecting a few thousand connections, 105 00:05:18,340 --> 00:05:22,930 try not to provision, you know, 2000 client IP addresses. 106 00:05:22,930 --> 00:05:25,270 My suggestion is to over provision that. 107 00:05:25,270 --> 00:05:27,820 Provision 3000 or 4000 even, for that matter. 108 00:05:27,820 --> 00:05:30,090 Give yourself from some room for growth, 109 00:05:30,090 --> 00:05:36,340 also give yourself some room to support spikes and things like that. 110 00:05:36,340 --> 00:05:41,200 IPv6 is supported for Always On VPN; it is optional. 111 00:05:41,200 --> 00:05:47,040 The only option here is to use a static IP address pool with a unique prefix. 112 00:05:47,040 --> 00:05:50,670 It's also important to know that your internal network must be configured 113 00:05:50,670 --> 00:05:56,180 to route VPN client IP subnets back to each individual VPN server, if you 114 00:05:56,180 --> 00:05:58,770 have more than one VPN server. This is crucial. 115 00:05:58,770 --> 00:06:02,320 Sometimes it's going to involve setting a static route on an internal 116 00:06:02,320 --> 00:06:04,670 firewall, or if you're using routing protocols, 117 00:06:04,670 --> 00:06:07,240 you may need to publish those routes internally. 118 00:06:07,240 --> 00:06:08,870 In terms of the edge firewall, 119 00:06:08,870 --> 00:06:13,820 it needs to be configured to allow inbound TCP port 443 to support the 120 00:06:13,820 --> 00:06:18,100 SSTP protocol. It also needs to be configured to allow inbound UDP 121 00:06:18,100 --> 00:06:22,880 ports 500 and 4500 for the IKEv2 protocol. 122 00:06:22,880 --> 00:06:26,310 These are the only protocols and ports that are required to 123 00:06:26,310 --> 00:06:30,040 be allowed inside from the edge firewall. 124 00:06:30,040 --> 00:06:31,650 Also, when you're configuring that, 125 00:06:31,650 --> 00:06:35,980 ensure that the public IP address translates to the private IP address 126 00:06:35,980 --> 00:06:39,630 of the VPN server, and make sure when you're setting up this NAT rule 127 00:06:39,630 --> 00:06:44,010 that you are translating only the destination address. Do not translate 128 00:06:44,010 --> 00:06:47,900 the source address; this causes problems for VPN servers. It also makes 129 00:06:47,900 --> 00:06:51,140 the logs rather meaningless because all the traffic appears to come from 130 00:06:51,140 --> 00:06:56,350 the edge firewall, and again, it can also cause problems for IKEv2, and 131 00:06:56,350 --> 00:06:58,910 it also causes serious problems when you're doing load balancing, 132 00:06:58,910 --> 00:07:00,680 So avoid source NAT‑ing, 133 00:07:00,680 --> 00:07:05,550 perform only destination NAT. Administrators also need to decide on a 134 00:07:05,550 --> 00:07:09,770 tunneling model for their endpoints. The two options are split tunneling and 135 00:07:09,770 --> 00:07:13,720 force tunneling. With split tunneling, only traffic bound for the internal 136 00:07:13,720 --> 00:07:18,360 network is routed over the VPN, and this is the recommended model. It 137 00:07:18,360 --> 00:07:20,330 provides the best user experience. 138 00:07:20,330 --> 00:07:25,730 It also ensures best performance and also reduces the traffic burden on your 139 00:07:25,730 --> 00:07:30,460 internal infrastructure. Force tunneling is used if you want to perform 140 00:07:30,460 --> 00:07:34,270 traffic inspection and do those types of things for your internet traffic 141 00:07:34,270 --> 00:07:36,430 for your remote or field‑based clients. 142 00:07:36,430 --> 00:07:39,610 All traffic, including internet traffic, is routed 143 00:07:39,610 --> 00:07:42,040 over the VPN tunnel in this scenario. 144 00:07:42,040 --> 00:07:44,270 Again, you can use this to, you know, 145 00:07:44,270 --> 00:07:48,440 provide visibility and control, to perform traffic inspection and content 146 00:07:48,440 --> 00:07:51,240 filtering, and things like that for internet traffic. 147 00:07:51,240 --> 00:07:55,530 It generally ends up resulting in a rather poor user experience, 148 00:07:55,530 --> 00:07:59,320 mostly because you now have suboptimal network paths, 149 00:07:59,320 --> 00:08:03,490 additional latency, and a variety of things that conspire 150 00:08:03,490 --> 00:08:05,290 to make that a rather, again, 151 00:08:05,290 --> 00:08:09,690 poor user experience. It does require many more resources on the back end. 152 00:08:09,690 --> 00:08:11,640 You need better internet pipe, 153 00:08:11,640 --> 00:08:16,110 you need more servers provisioned with more CPU and memory. 154 00:08:16,110 --> 00:08:17,740 Generally speaking, 155 00:08:17,740 --> 00:08:22,720 this is a model that we want to avoid, mostly because there are 156 00:08:22,720 --> 00:08:25,020 better options or better alternatives to that. 157 00:08:25,020 --> 00:08:29,350 There are more elegant ways to perform traffic inspection, 158 00:08:29,350 --> 00:08:32,100 internet traffic inspection, and you know, 159 00:08:32,100 --> 00:08:35,660 provide visibility and control for those endpoints when they're in their field, 160 00:08:35,660 --> 00:08:40,000 rather than being heavy handed and tunneling all that traffic back over the VPN tunnel.