VPNs via Windows Server 2003: Insight

To print: Select File and then Print from your browser's menu

--------------------------------------------------------------
This story was printed from ZDNet Australia.
--------------------------------------------------------------

VPNs via Windows Server 2003

By Scott Lowe, 0
September 26, 2003
URL: http://www.zdnet.com.au/insight/soa/VPNs-via-Windows-Server-2003/0,139023731,120278987,00.htm

Virtual private networks have fast replaced dial-up connections as the preferred method for achieving remote access to corporate information resources. Although Windows NT and 2000 both boast remote access services, including VPN, Windows Server 2003 offers the next level of these services, providing a secure communications mechanism for your users and infrastructure.

Windows Server 2003 provides a number of enhancements to VPN/remote access services that are superior to the features found in older versions of the operating system. The core support is still available for Point-to-Point Tunneling Protocol (PPTP), Layer 2 Tunneling Protocol (L2TP), IP Security (IPSec), Extensible Authentication Protocol (EAP), Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP 2), and Remote Access Services (RAS), but there are also some desirable new features.

In Windows Server 2003, Microsoft has improved the reach, security, and availability of the VPN services by providing NAT-aware L2TP/IPSec services and enabling VPN services to be used in conjunction with Network Load Balancing Services. Previously, to provide VPN services to clients behind NAT devices, the solution was to use the less secure PPTP.

To use L2TP/IPSec services from behind a NAT device, the remote end of the connection must be running a VPN client that supports drafts from the IPSec Protocol Working Group: Negotiation of NAT-Traversal in the IKE and UDP Encapsulation of IPSec Packets. Microsoft’s L2TP client has the appropriate support. The Network Load Balancing Services work in conjunction with both PPTP and L2TP/IPSec-based connections.

Windows Server 2003 also includes the ability to support client NetBIOS name resolution without the need for DNS and WINS servers through the use of a NetBIOS over TCP/IP (NetBT) name resolution proxy service running at the VPN server. This resolves some name resolution problems at the client side.

Up to 1,000 PPTP and 1,000 L2TP connections can be supported in Windows Server 2003 Standard and Enterprise editions, while a single connection of each type is supported in the Web edition. A single connection in the Web edition can help to support a secure remote administration mechanism.

Preparing the Windows Server 2003 system for VPN services
Like all other services in Windows Server 2003, the Routing And Remote Access Services (of which VPN is but one component) are disabled by default. Before they are enabled, a couple of things need to be verified. First, are two communications devices enabled at the server? At least one of them should be a network adapter. After all, the point of a remote access VPN is to provide access to internal network resources from outside the organisation.

Second, check to make sure you’re running the proper protocols on your server and workstations. As far as protocols go, today’s typical VPN uses TCP/IP in one form or another with either PPTP or L2TP for security. To provide users with access to resources on the internal network via a VPN connection, you must distribute IP addresses to them. You can accomplish this via the network’s existing DHCP server or by defining an address pool in the Routing And Remote Access Services configuration. This will also provide the remote client with appropriate addressing information for DNS and WINS to enable efficient name lookups.

Allowing and restricting access
Any type of remote access to a network opens the potential for abuse and unauthorised access, although you can take steps to mitigate these risks. For example, with Windows Server 2003 RRAS/VPN, you must explicitly allow each user to make use of the services by granting dial-in privileges in each user's profile. In addition, you can create strict policies—such as time of day restrictions, maximum session times, and MAC address restrictions—at the server to reduce the inherent security risk.

Enabling VPN services
To enable VPN services, you must enable Routing And Remote Access Services, which include VPNs. First, open Start | All Programs | Administrative Tools | Routing And Remote Access on the server where you want to support VPN. Next, right-click on the server name and choose Configure And Enable Routing And Remote Access. This will start a wizard that will help you configure these services.

RRAS includes a number of other capabilities besides VPN services, including NAT and dial-up (PPP). On the Configuration screen, shown in Figure A, you can specify which services you want to enable. For this example, I'll enable only dial-up/VPN.

Figure A

Enable VPN and/or dial-up services on the local server.

Choosing dial-up/VPN brings up the Remote Access screen, shown in Figure B. Here, you must select which of these services (or both) that you want to offer from this server. For this example, I'll choose only the VPN components.

Figure B

This server will allow only VPN connections.

Since VPN servers are generally installed with one interface facing outside the organisation to support remote connections, the wizard will now display the VPN Connection screen, shown in Figure C. You'll need to identify which interface will act in this capacity.

Figure C

The 192.168.1.120 interface is used for remote connections.

On the VPN server in my lab for this exercise, I have two interfaces. The first interface’s address is 192.168.1.120/24 and the second’s is 192.168.2.2/24. Since this server is in my lab, it does not have a true public address. However, for the purposes of this example, I'll use the 192.168.1.120 interface. Below the interface list, you'll notice a check box indicating that static packet filters can be applied to this interface to allow VPN traffic only. I recommend that you enable this feature, especially if this interface is outside the corporate firewall.

To access resources on the internal network, the remote client needs an IP address that is allowed to do so. The IP Address Assignment screen, shown in Figure D, gives you two choices for automatically providing the client with an IP address. First, you can use an existing DHCP server on your network after making sure that it is configured properly. Second, you can provide the VPN server with a range of addresses that it can dole out to the clients.

Figure D

Choose an IP addressing mechanism.

I prefer the second method, because it makes me feel a little more in control. I have to provide a range of addresses, and it allows me to quickly determine just by looking at a list of IP connections to a server if they are internal or VPN clients. If you choose this method and are using addresses from the same space as your internal network, make sure you exclude the range you choose from any DHCP scopes you've defined on other DHCP servers to prevent addressing conflicts. For this article, I'll choose this option.

Because I'm assigning addresses from a specified pool, the pool or pools must be set up, which I’ll do on the Address Range Assignment screen. Unless you have specific needs, you can specify a range of addresses from the LAN side of the VPN server. In this example, that network is 192.168.2.0/24.

To add a range, click the New button. You need to supply the starting address of the range and either the ending address or the number of addresses you would like in the pool. For this example, I'll create a range of 25 addresses from 192.168.2.100 to 192.168.2.124.

A key aspect in providing remote access services is authentication. Without it, anyone can access your internal network as long as they can get to your VPN server. If your network includes a RADIUS server, the Windows Server 2003 VPN services are more than capable of using it for authentication. If you don’t have one, you can just let the RRAS services handle the authentication. You’ll specify authentication on the Managing Multiple Remote Access Servers screen.

After this step, the wizard will configure RRAS based on the parameters you specified. When the process is completed, you'll be notified that you need to allow DHCP relays to clients if you chose to use an existing DHCP server. You should then see a green arrow next to your local server on the RRAS screen indicating that the service is active, as shown in Figure E.

Figure E

More options are available now that RRAS is enabled.

Connecting clients
With the VPN server minimally installed to support PPTP and L2TP connections, you can now initiate these connections as long as the user has permissions to use the VPN services. One good thing about RRAS is that Windows does not automatically enable every user to use RRAS. Rather, an administrator needs to enable this privilege for each user who needs it.

To enable someone to use the VPN services, start Active Directory Users And Computers. Next, right-click on a user object and choose Properties. On the Properties page for the user, go to the Dial-in tab and choose the Allow Access option under Remote Access Permission (Dial-in Or VPN). Click Apply or OK to continue. The user will now be able to use the VPN services. In Figure F, the Administrator user VPN dial-in permissions are enabled, but this is for demonstration purposes only. I would not recommend enabling the Administrator user outside of a lab setting, since this account is a favourite target for exploitation.

Figure F

You enabling someone to use the VPN server through the Properties page.

Testing the connection
With this out of the way, a client computer can now be connected to the VPN server using this user’s credentials. For this step, I'll use a Windows XP Professional SP1 client. This system resides on the outside of the network and needs to use the VPN services to gain access to the inside.

To begin, choose Start | My Network Places and choose View Network Connections from the Network Tasks shortcut menu. Next, click Create A New Connection. This will start a wizard to help you set up the connection.

The wizard first asks what kind of connection you want to create. Since this example is designed to test the new VPN server, choose the Connect To The Network At My Workplace option.

The next step asks whether this will be a dial-up or a VPN connection. Because your users are going to connect to a VPN, naturally you'll choose a VPN connection. The wizard will also ask for a name for this connection.

If you need to dial up to an ISP before establishing the VPN connection, you can allow the VPN connection to do so when you open it. If you're using DSL, a cable modem, or another always-on connection, you don't need to dial anything beforehand. The IP address or DNS name for the VPN server is required in the next step of the wizard. Finally, you need to provide the username and password credentials for a user who is allowed dial-in access to the network.

Click Connect to establish the connection. If everything is set up properly, you will be connected to the VPN server and be provided an IP address from the static pool that was created during the installation of the VPN server. As you can see in the VPN connection details for this test, shown in Figure G, the server IP address is the VPN server, and this connection has been assigned an IP address from the pool.

Figure G

These are the details for our VPN connection.

On the VPN server, you can also view details about the connection by choosing RRAS Console | VPN Server Name | Remote Access Clients and then right-clicking on the connection. Just choose Status from the shortcut menu, and you'll see the screen shown in Figure H.

Figure H

You can also view server details for our VPN connection.

It's as easy as that
To provide a better level of security, you can enable remote access policies that, for instance, allow only L2TP/IPSec connections or specific authentication types. VPN services in this new operating system are flexible and can give your users secure remote access to the network to increase their productivity.

TechRepublic is the online community and information resource for all IT professionals, from support staff to executives. We offer in-depth technical articles written for IT professionals by IT professionals. In addition to articles on everything from Windows to e-mail to firewalls, we offer IT industry analysis, downloads, management tips, discussion forums, and e-newsletters.

©2003 TechRepublic, Inc.