- 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
If you have followed this Always On VPN series so far, you are almost completely configured! In the previous two articles, you installed a Routing and Remote Access Server (RRAS) or virtual private network (VPN), a Network Policy Server (NPS) or Remote Authentication Dial-In User Service (RADIUS), and a Certificate Authority (CA). These segments are the most difficult portion of the whole guide, as one mistake can break functionality in the other roles. In this article, we will tackle network configuration and several security items.
The network configuration required for an Always On VPN environment is relatively simple. However, exact steps vary. Firewall, router, and switch configurations differ among vendors. As you will see in the next section, you can set up the networking components differently depending on your environment. We will begin with an overview of the final network layout first.
Networking configuration for Always On VPN
Your remote access server should have two network interfaces. One should be connected to the public network, and the other should be connected to the internal network. The public-facing interface should sit behind your network edge firewall. The internal interface should sit in front of your internal firewall. The NPS, CA, and domain controllers (DCs) sit inside the internal network. You can see this diagram in the center blue portion of the picture below.
If you do not have a separate internal firewall, you have a few options. First, many firewalls allow you to create a perimeter (DMZ) network within the external firewall. Connections would come into the external box and would be routed to that perimeter network. The external firewall would then allow certain traffic into the internal network.
The second option is to use an external firewall and route VPN traffic to a dedicated network on your router/core switches. You would then apply access control lists (ACLs) to this network to restrict your traffic. If these options do not work, you can also use the software firewalls in Windows Server. This mode is not recommended for production environments though.
On your VPN server, ensure you configured the public-facing interface with a dedicated IP, subnet mask, and default gateway. This default gateway will often be the external firewall. The internal network should also have a static IP and subnet mask. It will not have a default gateway though. Two default gateways can cause issues with routing the VPN connections and can often lead to missing VPN default gateway issues.
There are many ways to make the Always On VPN network configuration work for your environment. If you have specific questions about HP or Cisco equipment, leave a comment and I can try to help. Once you've correctly placed your servers in your network, continue below to finalize the security aspects.
Always On VPN Server security settings
A secure Always On VPN setup uses just a few ports for communication and a proper public/private certificate configuration. Part of this security is ensuring that clients always connect to your trusted RRAS/VPN server.
Start by creating a public DNS entry pointing to your RRAS/VPN server's public IP. This DNS name does not have to match the computer name. Of course, the domain name does have to match your publically routable domain name. For example, my DNS name would be AlwaysOn.DeployHappiness.com, and the server name might be VPN-01.DeployHappiness.com. Note this DNS name. You will need it in the next article (client configuration).
The certificate issued to the VPN-01 server would need to contain AlwaysOn.DeployHappiness.com in the Subject Alternative Name (SAN) field. Any clients connecting to your network should establish this as a trusted certificate. If you plan on using nondomain machines or might use these servers for separate purposes (such as wireless authentication on NPS), plan on purchasing a SAN certificate from a third-party certificate provider. Depending on the size of your environment, you may purchase a single certificate for NPS and RRAS.
Client VPN connections need two open ports. On your edge firewall, allow UDP 500 and 4500 to the public-facing interface of your VPN server. Ensure these two ports are also open on the software firewall for your public-facing network interface controller (NIC) inside Windows Server.
On any internal firewall sitting between your VPN server and your NPS box, allow ports 1645, 1646, 1812, and 1813. Ensure these four ports are also open on the firewalls inside Windows Server. It is always best to enforce additional configurations like these with Group Policy or Desired State Configuration.
Subscribe to 4sysops newsletter!
With these changes, your Always On VPN network and server configurations are finished! In the next post, we will set up a client to connect and cover client deployment options.
Read the latest IT news and community updates!
Join our IT community and read articles without ads!
Do you want to write for 4sysops? We are looking for new authors.
Hi, I have a situation where a working Always-On server needs to be moved to a different external network (both old/new behind a load-balancer) but the connections don't work when moved to the new network (VM VLAN and IP changed, and load-balancer re-pointed). Does any of the configuration on the server need to be re-run, i.e. is it somehow tied to the external IP even though it's a private IP?
Hi Joseph
I was wondering can the NIC behind the hardware firewall be on the same subnet as other NIC on the internal side? We have a fortigate FG- 501E firewall
Thanks for your time