Secure connections for remote users are easy enough to provide with a Microsoft Windows 2003 VPN server. This article steps through the VPN deployment process, from the few key choices that must be made to the actual implementation.
Imagine being back in your high school cafeteria. You need to get a message to your friend on the other side of the room, but your school has very strict rules, and yelling at him will get you thrown in detention. One way to get the message across the cafeteria would be to tell your neighbor, then have everyone in the cafeteria pass it on until it reaches the other side of the room. Assuming that each person in the chain correctly repeated the message it would eventually reach your friend.
But what if the message was secret campaign information about the upcoming student election? You don't want everyone to know so you quickly find two cans and a long piece of string. After connecting the two cans to each end of the string you pass one of the cans over to your friend while each classmate in between holds the string.
That's the basic idea behind a virtual private network (VPN).
A VPN tunnels information through some "other" network. A VPN does not technically need to provide any authentication mechanisms or security for the information it is tunneling, though in reality this is the most common scenario. The analogy above illustrates the fundamental concepts behind most VPN implementations, which is passing private information securely via a public medium.
Site-to-Site vs. Remote Access VPNs
The two most common VPN scenarios are site-to-site and remote access. Let's take a closer look at each of these.
In a site-to-site scenario, a VPN connection joins two separate networks. For example, an organization may have its headquarters in Portland, Ore. and a new satellite office in Seattle, Wash. The boss wants employees in the new Seattle branch to have access to network file shares along with full Exchange connectivity, all of which are hosted in the Portland office. You could get an expensive leased line from the telephone company, but why pay big bucks when a site-to-site VPN will do the trick? With a site-to-site VPN connecting the two offices, computers on one local area network (LAN) will be able to communicate with computers on the remote LAN as if they were plugged into the same Ethernet switch. Of course, filters and other firewall rules can be put into place if you don't want any and all communication going across the VPN connection.
In a remote access VPN scenario users who are away from your organization's LAN are able to connect remotely and use the VPN to gain access to internal network resources. A good example of a remote access VPN in action would be the salesman in the field who needs access to a proprietary customer relationship management (CRM) application. If the CRM program does not have a Web interface, then using a remote access VPN is a great way to provide off-site access to the application. Of course, a remote access VPN connection can also provide access to network file shares and printing.
Another nice feature of the remote access VPN scenario is some additional privacy and security when using public networks, such as free wireless in a coffee shop. The remote access VPN client can be configured to send all traffic, including Internet traffic, through the VPN. This means other users on the wireless network will not be able to see what sites you are visiting, including any other unencrypted traffic.
Deploying Microsoft VPNs
When deploying a Microsoft VPN solution, two high-level design decisions must be made.
One of the most important choices to make is Point-to-Point Tunneling Protocol (PPTP) vs. Layer 2 Tunneling Protocol/IP Security (L2TP/IPSec). These are the two tunneling protocols that encrypt data and tunnel it safely across the Internet to its destination (i.e., the string between the two cans). PPTP is easier to set up because it doesn't require certificates (aka a public key infrastructure), but unfortunately it is not quite as secure as L2TP/IPSec. PPTP's core weakness is that it depends on the strength of the user's password, so be sure to have a good password policy in place if you use PPTP. PPTP is good enough for many environments, but if you need a 100-percent rock-solid solution, you will want to use L2TP/IPSec.
You can also support both PPTP and L2TP/IPSec. In this scenario you would distribute certificates to clients requiring the highest levels of security, and the rest of your users can stick with PPTP.
Another important design decision you must make is whether to configure remote access VPN clients for a split tunnel or a full/single tunnel. A split tunnel occurs when VPN clients send Internet-bound traffic through whatever Internet connection they are currently using but send traffic bound for the organization through the VPN tunnel. The advantage of this method is that it does not clog up the Internet gateway at the VPN server location. However, it does leave VPN clients with less privacy and security if they are connecting from an untrusted network. With a full/single tunnel, all traffic (whether it is bound for the Internet or your organization's network) will be sent through the VPN tunnel.
This article was originally published on Enterprise Networking Planet.
Now that we've introduced some fundamental concepts for building a Microsoft Windows Server 2003 VPN server, let's step through a basic remote access VPN deployment.
The very first thing you must decide when building a Windows VPN server is whether to use Microsoft's Internet Authentication Service (IAS) to authenticate users connecting to your VPN. IAS is Microsoft's implementation of RADIUS, and when building a VPN server you can have user's credentials passed off to IAS for verification or you can have users authenticated directly against Active Directory (AD).
Using IAS provides several advantages. First, it has better logging capabilities, including the ability to send data directly to an SQL database. Second, it provides a central destination at which you can point several VPN servers. This allows you to maintain one set of remote access policies that all of your VPN servers can use. In a nutshell, remote access policies can be characterized as a powerful way to define who is allowed access to the VPN. Assuming IAS is your choice for authentication, let's jump right into the configuration of an IAS server.
Follow the steps below to install your IAS server. If you are short on hardware, it can be installed on the same server you plan to use for VPN access. This is not recommended for a high security environment, however.
- Choose the desired option
- enter the appropriate information for your VPN server (you will be asked to enter a shared secret, enter one and save it for later)
- If your IAS server has a firewall enabled, then make an exception to allow UDP port 1812 from the VPN server
While the IAS admin interface is open, let's add a remote access policy to allow access to users who are in a specified AD group (the two default groups will not allow anyone to access your VPN server). Here are the steps:
- Choose a name » Next
- Choose VPN » Next
- Click Add...
- Click Locations... and select your domain
- Add MyVPNaccessGroup » Next
- Leave MS-CHAPv2 as the only option » Next
- Leave "Strongest encryption" as the only option » Next » Finish
Finally, be sure to update the new remote access policy to prevent rogue computers on the remote user's network from using the VPN connection to forward packets through the VPN server. Follow these steps:
Our ISA server is now ready to receive authentication requests from a VPN server. Before you can begin configuring a VPN server, take care of these pre-requisites on the VPN server:
- Setup two network interface cards (NICs) on your VPN server; connect one to the internal protected network and connect the other to your DMZ or publicly accessible network (we'll refer to this as the external NIC)
- Do not configure DNS or WINS on the external NIC
- Do not define default gateways for the internal NIC, only define one default gateway for the external NIC
And now, here are the steps required to configure your new VPN server:
- Stop the "Windows Firewall/Internet Connection Sharing" service and set the startup mode to Disabled
- Right-click the server name and click Configure and Enable Routing and Remote Access (the local firewall service must be disabled)
- Choose Remote Access » Next » check the box for VPN » Next
- Select the external NIC (notice the check box for "Enable security...") » Next
- Select the internal NIC » Next
- Choose "Automatically" or "From a specified range of addresses" (this procedure will follow the 2nd option) » Next
- Click New... » enter a range of IPs » OK » Next
- Choose "Yes, set up this server to work with a RADIUS server" » Next
- Enter your IAS server and shared secret » Next » Finish
- Add the IP address of a DHCP server to the DHCP Relay Agent configuration (note that the DHCP server is required to return information such as default domains, but shouldn't be handing out any IP addresses because set a static pool of addresses)
- If your internal network consists of only one network then you're finished! Otherwise, a route will need to be added for clients to get to other internal networks. enter a route that will get traffic to any subnet on your internal network. The easiest way to do this is to point all traffic for your internal network to the default gateway that the internal NIC is using.
Next you will need to setup a VPN connection from a client. Here are the steps on a Windows XP machine:
That's it! You should now be able to double click on the VPN connection you just created and logon with a user account that is a member of the group you granted VPN access to in the remote access policy created above.
You may notice that when you connect to the VPN you can't access the Internet. This is a tricky issue to get around, and the solution depends on your network topology. One obstacle is the default IP filters created on the external NIC where Routing and Remote Access is configured. You can configure these from buttons. Be careful when changing these filters as they are created as a security measure.
To configure the split tunnel vs. full tunnel discussed above got to . Un-checking this option will create a split tunnel when you initiate the VPN connection; leaving it checked creates a full tunnel.
To connect to PPTP or L2TP/IPSec (remember that L2TP/IPSec requires certificates) go to .
That's all folks. Two final pieces of information that may come in handy if you roll out a Windows VPN server: 1) Where applicable, user account settings on the dial-up tab of an AD user object override the remote access policy settings created on the IAS server and 2) Windows Server 2003 Standard edition supports up to 1,000 concurrent connections.
This article was originally published on Enterprise Networking Planet.
This article was originally published on Friday Dec 28th 2007