Editor’s note: In response to the coronavirus crisis gripping the world, TechGenix is republishing a selection of recent articles, tutorials, and product reviews that contain relevant information for IT pros as their jobs change dramatically. In this article, originally published Nov. 11, 2016, we show you how to use DHCP services in Windows Server 2016 to facilitate your VPN.
If you use DHCP services — and let’s face it, who doesn’t these days — you may be running DHCP on Windows Server. If you use VPN, you probably wanted to set up DHCP relay, but maybe found your network security posture in the way of this, either because the VPN server’s internal interface was on the wrong subnet for what you wanted clients to do, or because you had to support multiple client subnets for different security levels. That’s a common problem that usually leads to configuring static pools on the VPN concentrator for clients, which means more work and no centralized DHCP services. If this has been a problem in your environment, you should take a look at Windows Server 2016, because the improved DHCP services in Server 2016 address exactly these issues!
The problem
You have a DHCP server on the internal network, and a Windows RRAS or other VPN concentrator in a screened subnet that must provision clients on multiple subnets. The DHCP relay agent alone cannot solve the second scenario, as it will obtain ip.addrs from DHCP based on the agent’s source ip.addr as defined in RFC 2131, which is not going to be on the same subnet as most or all of the VPN clients. To address this, many admins have no choice but to configure multiple VPN servers or preallocate ranges of ip.addrs to each client subnet. Neither situation is ideal.
The solution
There are two RFCs that propose enhancements to DHCP services on networks. In both cases, the need to provision clients includes a separation between the clients and the server that simple DHCP relay alone does not handle. This could include multiple VPN subnets on the same concentrator acting as the DHCP relay agent or other complex network arrangements between the DHCP server and clients. The Windows Server 2016 DHCP service includes support for both RFC 3011 and 3527. RFC 3011 — the IPv4 Subnet Selection Option for DHCP — provides a solution for selecting a subnet for a DHCP assignment when the normal methods, either the subnet of the relay agent or the subnet of the interface on which the request was received, are not suitable. The second, RFC 3527 —Link Selection sub-option for the Relay Agent Information Option for DHCPv4 — enables a DHCP proxy to specify the subnet from which an address is assigned.
While both of these scenarios are perhaps fringe, they are common enough that RFCs were written to address these, and Windows Server 2016 now supports them, so they are likely going to be good news for some of you.
What’s missing?
But now the downside. Completely unrelated to the new supported capabilities mentioned above, but also significant if you are considering Windows Server 2016 for DHCP, note that the ability to support Network Access Protection (NAP) is now gone. This was deprecated in Windows Server 2012 R2 but still existed. In Server 2016, it’s gone. If you’ve been using NAP to protect access to subnets, you’re going to need to do something else, like EMS or Intune.
The DHCP service in Server 2016 works very much like it does in 2012 R2 and 2008 R2, with a familiar look and feel to the MSC and very recognizable steps to set up options and scopes. If you are looking to start upgrading your servers and want to start with your DHCP services, you should be good to go as long as you don’t need NAP.
windows server 2016