It is fairly common when starting work with the new Remote Access role for administrators to choose the Deploy DirectAccess only option. Maybe you initially thought this box was only going to be used for DA, or that all of your client connections would be handled by only the DA role. While this is true for some organizations, it is pretty common to get some benefit from having both DirectAccess and VPN configured on your remote access entry point. Maybe you have some mobile phones or personal tablets that you want connected to the corporate network. Or perhaps you want to give the ability for home computers, or even Macs, to connect remotely. These are scenarios that are outside the scope of Direct Access and require some other form of VPN connectivity.
Making significant changes on a production server can be intimidating, and you want to make sure that you select the right options. Also, IP addressing remote access servers isn't always a cakewalk, and so it would be natural to assume that turning a DirectAccess server into a DirectAccess plus VPN server would involve some additional IP addressing. You would actually be wrong about that last one. VPN can share the public IP address already configured and running for your DA clients, so thankfully when you decide to add VPN to your server, you don't have to reconfigure the NICs in any way. Since we don't have to make networking changes first, let's jump right into taking our production DA server and adding the VPN role to it.
We are working today from our new DirectAccess server, which is a Windows Server 2016 that has the Remote Access role installed.
To add VPN functionality to your existing 2016 DirectAccess server, follow these steps:
- Open Remote Access Management Console from the Tools menu inside Server Manager.
- In the left window pane, navigate to Configuration | DirectAccess and VPN. This is the screen where you see the four setup steps listed in the middle.
- Now over on the right, you see a section of buttons related to VPN. Go ahead and click on Enable VPN.
- You will receive a pop-up message asking you to make sure you intend to configure VPN settings on this server. Go ahead and click OK. This will cause your remote access server to spin through some processes, reaching out to the GPOs and reconfiguring the necessary settings so that they include VPN connectivity.
- VPN is now enabled on our server, but we have yet to configure IP addressing that will be handed out to the client computers. Once you are back at the main Configuration screen, click the Edit… button listed under step 2.
- There is now a fourth screen available inside this mini-wizard called VPN Configuration. Go ahead and click on that.
- If you want VPN clients to pull IP addresses from an internal DHCP server, leave the radio button set to the top option. If you would rather specify a particular range of IP addresses that should be handed out to client computers, choose Assign addresses from a static address pool and specify the range of addresses in the given fields.
When you specify a static range like this, your remote access server will start handing out these addresses to the client computers that connect using VPN. However, these client computers will most likely not be able to connect to any internal resources without a little additional networking consideration. When you create a static address pool for assigning IP addresses to VPN clients, there are two rules you need to keep in mind:
- The pool of addresses to be handed out to clients should come from a subnet that does not exist in the remote access server's internal routing table. For example, my network is 10.0.0.x and I am going to assign VPN client licenses from 10.0.1.x.
- You need to set the default route for this other subnet so that it points back to the internal IP address of the remote access server. Without doing this, traffic from the VPN clients might make its way into the 10.0.1.x subnet, but responses from that subnet aren't going to know how to get back to the VPN client computers. By setting a default route on the 10.0.1.x subnet to point back to the Internal NIC of the remote access server, you fix this.
The act of enabling VPN on a DirectAccess server is a single action, but without a couple of extra configuration steps, that VPN enablement isn't going to do much for you. With this recipe, you should now have the information you need to enable and configure a VPN on your remote access server and get those machines connected that do not meet the requirements to be DirectAccess-connected. In the field, I find that most companies try to get all the computers they can connected via DirectAccess, because it is a much easier technology to deal with on the client side and is better for managing domain joined systems. When faced with the need to connect computers that aren't Windows 7, 8, or 10, or are not domain joined, it is nice to know that traditional VPN connectivity options exist right in our Server 2016 operating system.