- SmartDeploy: Rethinking software deployment to remote workers in times of a pandemic - Thu, Jul 30 2020
- Outlook attachments now blocked in Office 365 - Tue, Nov 19 2019
- PolicyPak MDM Edition: Group Policy and more for BYOD - Tue, Oct 29 2019
Welcome back to the Always On VPN configuration guide. In part 1 of this series, we explored what Always On VPN can do and how it works. In that article, I also kind of lied to you by stating we would have everything neatly tied up into four separate articles (on an overview, servers, networking, and client configuration).
Unfortunately, I had to break up the server configuration portion into two smaller sections. In the first section, you configured certificate services and prepared your NPS and VPN servers. Today, we are going to create our NPS connection rules, configure Remote Access, and tie our servers together.
Configuring Network Policy Server for Always On VPN
Network Policy Server (NPS), sometimes called a RADIUS or AAA server, enforces your authentication rules against clients connecting through your Always On VPN setup. You can use any existing NPS server. If you haven't implemented NPS before, run the following on your new server and then register your server with Active Directory by using the NPS console.
Install-WindowsFeature NPAS -IncludeManagementTools
NPS configuration consists of three areas: RADIUS clients, connection request policies (CRPs), and network policies. If you launch the NPS console, you will actually see these three items in order. Launch the NPS console if you haven't.
For an object to even talk with your NPS server, it must first be in the RADIUS client list. Expand RADIUS Clients and Servers. Right click on RADIUS Clients and select New.
Set the Friendly name value to the fully qualified domain name (FQDN) of your Always On VPN server. Enter the internal IP address of the VPN server in the second box. Generate a shared secret and copy it down. You will need it during the Remote Access server configuration. You will not need it after that though.
Next, we need to configure the connection request policy. On the Getting Started page of the NPS console, change the Standard Configuration drop-down box from Network Access Protection (NAP) to RADIUS server for Dial-Up or VPN Connections. Select the Configure VPN or Dial-Up button now.
Starting the Configure VPN or Dial Up wizard
Proceed through the VPN wizard with these steps:
- On the Type of Connections screen, select the Virtual Private Network (VPN) Connections Accept the default name and click Next.
- Select your VPN RADIUS client you configured in the section above. The IP of the RADIUS client should be your Always On VPN server. Click Next.
- Check the Extensible Authentication Protocol Change the Type to Microsoft: Protected EAP (PEAP). Uncheck any remaining boxes below. Click Configure.
Configuring authentication methods for Always On VPN within NPS
- After clicking Configure, the Edit Protected EAP Properties window should appear. Do not worry about the certificate section yet. Instead, remove any existing EAP types and add Smart Card or other certificate. The bottom of your window should match the screenshot below. If it does, click Next.
Enabling the Smart Card or other certificate EAP type
- On the Specify User groups window, add the VPN users group you created in part two of this guide.
- Click Next until you reach the end of the wizard. Do not make any changes to the remaining screens. At the end of the wizard, click Finish to save your changes.
In the NPS console, expand Policies and select the Connection Request Policies folder. Double-check the newly created Virtual Private Network (VPN) Connections policy is enabled and the source is set to Remote Access Server (VPN-Dial Up). If you have no other policies using that source, move your newly created policy up in the processing order.
The Always On VPN Connection Request Policy
After finishing the Connection Request Policy, select the Network Policy folder and double-check the newly created network policy. It should match the example picture below. If you have no other matching sources, move your new policy up to the top of the Processing Order list.
The Always On VPN network policy
The screenshot below details the conditions and settings windows you should see below your new network policy (once you select it). Make sure these match your settings.
Specifically, check the Extensible Authentication Protocol Method and Authentication Method lines. Mistakes here will cause all clients to fail when establishing the Always On VPN connection.
Mismatched NPS settings often lead to Always On VPN connection failures
NPS uses four ports for communication. In your internal network, ensure the ports 1645, 1646, 1812, and 1813 are open. This includes the connection from your Always On VPN server to NPS and from NPS to your domain controllers.
Configuring Remote Access Server for Always On VPN
Your Remote Access (VPN or Always On VPN) server sits between the internet and your internal network. It should have two separate NICs (physical or virtual ones). The NICs should have two separate IP addresses on them. If you have that set up now, you are good to continue. We will talk more about the remaining networking requirements in the next part of this guide.
If you haven't, install the DirectAccess and VPN (RAS) server role on your Remote Access server. After finishing this, click on the Notifications flag icon in the top-right section of Server Manager. Open the Remote Access wizard (Getting Started) and select the Deploy VPN Only option. While DirectAccess and Always On VPN can exist together, there is really no reason to deploy both technologies anymore.
In the Configure Remote Access wizard, continue until you can select Custom Configuration. Once on the Custom Configuration window, select VPN Access. Finish the wizard and start the Remote Access service.
The Routing and Remote Access console should open. If not, launch it now. Expand down to IPv4\General to list your interfaces. Make a note of which interface faces the external network and which interface faces the internal network. It may help to rename your two NICs in the Control Panel. The image below shows those renamed dedicated NICs.
Multiple NICs are required for Always On VPN
In the top-left section of the console, you should see the name of your Always On VPN server. This is just below the Server Status button. Right-click on your server name and select Properties.
If your internal IP range does not have access to a DHCP server, you will need to select the IPv4 tab and assign a static address pool. If you use DHCP, be sure to configure the IP Helper statements on your gateway. I prefer to use DHCP, and you can see that selection below.
DHCP provides addresses to this Always On VPN setup
Note that the Enable broadcast name resolution box is checked and that the adapter is set to the internal NIC. Whether you use a static pool or DHCP, set that option.
Select the Security tab now. Change the Authentication provider to RADIUS Authentication and select Configure. Add your NPS server IP to the list of addresses. Be sure to use the same shared secret used earlier in this guide. Repeat these steps for the Accounting provider box.
Connecting the VPN server to NPS for authentication and accounting
On the left side of the Routing and Remote Access console, you should see a Ports option. Right-click on Ports and select Properties. Left-click on WAN Miniport (SSTP) and select Configure. Uncheck Remote access connections (inbound only) in the Configure Device pop-up. Skip the WAN Miniport (IKEv2) option. Left-click on the remaining options (PPTP, L2TP, and PPPoE), and uncheck any inbound or outbound boxes in their Configure Device pop-ups. Your Port Properties window should now match the screenshot below. Note this uses only the IKEv2 type for RAS/Routing.
Allowing just IKEv2 for Always On VPN connections
After finishing this, restart the NPS and VPN servers. Your main server configuration for your Always On VPN setup is now complete! In the next part, we will configure a remaining certificate setting, configure networking, and explore security settings.
When are the next parts coming please!?
The next part in the series will probably published on Friday.
On the 'Uncheck Remote access connections (inbound only) in the Configure Device pop-up.' piece, assumption being we have RRAS and NPS configured on different systems (e.g. RRAS with dual NICs in DMZ, NPS internal LAN/WAN), this would enabled as any remote access connections *would* be incoming?
On the 'Uncheck Remote access connections (inbound only) in the Configure Device pop-up.' piece, I don't have that. Mine is JUST Status… Disconnect, Refresh, or Help, there is no properties?
Nevermind, I was able to do it via powershell/cmd prompt (My RRAS Server is a CORE server)
I want to setup two remote access servers to make this scale and redundancy combined with our external loadbalancer to direct the traffic towards these.
But I fail to find any good information on how or even if remote access clustering is needed if I want two servers. All guides I find for clustering Remote Access mentions direct access but not Always on VPN. Microsoft says that all config of a cluster be done in the Remote access mangement console. But in all guides of always on vpn all config is done using the Routing and Remote access snapin. Is this something you could clear up or point me to some resource?
You can let your external load balancer handle everything. Setup a second VPN (Routing and Remote Access) server. Copy your VPN cert from the first machine to the second – be sure to include the private key.
Hello,
Fantastic tutorial!
One question. I am doin NAT with the AOVPN clients, using the Internal interface (the IP addresses, are provided by the RRAS server itself like in your example), and it works.
I want to know if it is possible to use the external interface instead: I think this configuration could be more secure as the AOVPN clients are doing NAT on the side of the RRAS server located to the External firewall, not the internal network.
Thanks a lot in advance for your help.
Best regards
J
Thank you! I am not 100% (and I may not understand your question). On your firewall/router, you can use ACLs to allow clients to only talk with approved addresses.
Dear Joseph,
Thanks for your reply.
Let me try to clarify.
In your tutorial it is specified to use the Internal interface as the one to use to forward IP addresses to AOVPN clients.
I am doing the same and, at the same time, I am using NAT on the internal interface.
Do you know if it would be possible to do the same using the external interface instead?
I am asking because all documents I am reading use internal interface only but I cannot see a reason to use the external one instead. Maybe I am blind to something important and I don't want to play with my current infrastructure to discover that it is not working.
Thanks a lot in advance for your help on this matter.
Best regards