Windows Server 2003 offers several VPN choices through its Routing and Remote Access Services. These options include Point to Point Tunneling Protocol (PPTP), Layer 2 Tunneling Protocol (L2TP), and Point to Point Protocol over Ethernet (PPPoE). Like most Microsoft offerings, these VPN options are all tightly integrated with other Microsoft products. Microsoft has conveniently placed support for all of these VPN types into the client operating systems. This makes it very easy and economical for you to use Windows Server 2003 RRAS for VPN.

One of the drawbacks to using Windows Server 2003 RRAS for VPN is that although the Choose Your Role Wizard allows Windows Server 2003 to tailor itself for VPN use it is still an operating system that was built to fit many needs. Exposure to security vulnerabilities will be higher than with a device that is designed to do VPNs exclusively. It will be very important to administrators to ensure that a Windows Server 2003 RRAS system has been secured as much as possible. This chapter will cover such settings and recommendations.

Something of a hybrid solution is offered by companies such as Celestix. These hybrids are dedicated VPN systems that are based on a subset of Windows Server 2003. This gives them the advantages of the tight integration with Microsoft products without the exposure to security vulnerabilities that would be present in a full implementation of the operating system. Such devices leverage Active Directory for the storage of security account information and thus integrate well into Microsoft-oriented networks.

Most of the major firewalls on the market today offer VPN functionality. Many of these firewall manufacturers have gone out of their way to create proprietary VPN systems to differentiate themselves from Microsoft offerings. Although some of the smaller firewall manufacturers offer PPTP and L2TP w/IPSec, most of the larger companies such as Checkpoint or Cisco have created their own implementations.

These proprietary VPN systems often tout improved security in the areas of authentication and data encryption. Higher bandwidth saturation as well as larger numbers of concurrent connections is often offered by these solutions. Although there is a lot to be said for improved performance and security, it usually comes at a price. These firewall-based VPNs usually require that an additional VPN client be purchased and installed onto each system that will be accessing the network via the VPN. This results in additional costs not only in the purchase of licenses but in the added management of installation of this client onto workstations. For companies with high security requirements, this is usually not a big issue. As the philosophy goes, there are three components involved with security: the overall security of the system, the convenience of using the system, and the cost of the system. To increase security, either cost will increase or convenience of use will decrease. If you reduce cost in an implementation, either security or usability will suffer. Making an environment easier to use will either cost more money or security will suffer. There is no perfect balance of these components. It is up to you to determine the requirements and design accordingly.

Pay careful attention to performance numbers and don’t be swayed by impressive numbers. If VPN box #1 can saturate 10MB and VPN box #2 can saturate 100MB, box #2 seems a lot more impressive. If the company only has a T-1 to the Internet, both boxes are more than sufficient and there would be no reason to spend extra money for the added capacity of box #2 over box #1.

The last class of VPN device is the dedicated hardware VPN. Manufacturers like Cisco or Ravlin offer devices that are designed to do nothing other than act as a consolidation point for VPNs. As the saying goes, let routers route, let firewalls firewall, and let the VPN system handle the VPN. Although in many cases it is advantageous to consolidate multiple functions into a single device, security usually takes the exact opposite approach. By separating tasks, not only are devices able to focus on what they are best at but a network gains multiple layers of security. Layered security is harder and more importantly, more time-consuming to defeat. Time is the bane of the hacker. The longer their attack takes, the more likely you are to see the attack and take appropriate measures. Never forget that computers don’t know whether an access is legitimate. A VPN is a doorway into your network. Your job is to ensure that only appropriate users access it.

In the past, most dedicated VPN devices ran proprietary VPN protocols. Today most of these devices have moved toward standards-based VPNs with protocols like PPTP, IPSec, and IKE. This gives you greater flexibility in integrating multiple VPN devices. This is especially helpful when companies merge, acquire, or partner up.

Small networks that don’t have specific security requirements and that want to take advantage of VPN technologies are prime candidates for software-based VPNs. Windows Server 2003—with PPTP or L2TP w/IPSec on the back-end and the client running native VPN stacks from a Windows operating system—allows easy access to corporate resources.

Eventually companies outgrow this simple architecture. Because alternative operating systems need access to the resources, it is often helpful to abstract the VPN portion of the traffic. Site-to-site VPN technologies can be leveraged to allow normally unsupported operating systems to access a VPN as long as they are able to communicate via TCP/IP. An Apple computer or a Linux system can both ride a TCP/IP VPN tunnel into a network regardless of its ability to support PPTP if it is communicating through a PPTP capable site-to-site VPN device.

Site-to-site VPN devices are generally very secure, easy to install, and flexible in their protocol support. Rather than install client VPN software on all machines in a remote location and configure them all to connect to a single VPN device, local VPN gateways can be installed to allow traffic to route from site to site across the VPN. This enables a user to travel to any location with one of these VPN gateways and access the corporate network. In many companies, these types of VPNs have replaced traditional WAN connections. Because these VPNs leverage the Internet as their backbone, they are only as reliable as the Internet. The primary benefit of a site-to-site VPN over a traditional WAN connection is the cost. Local Internet connectivity is relatively inexpensive and this reduction in cost versus a long distance Frame Relay or ATM connection allows a site to purchase higher bandwidth than it would have normally been able to afford. The savings are often great enough to allow the site to also purchase a redundant Internet connection. This further improves the stability of the VPN and makes a compelling argument for replacing traditional WAN connections with site-to-site VPN connections.

It is a fairly common practice to install a VPN device in parallel with the firewall. This is to say that both the firewall and the VPN device have an interface that is connected directly to the Internet. Remote VPN users connect directly to the VPN device and their traffic does not pass through the firewall.

This configuration requires that the VPN device itself be well hardened and secured. Careful monitoring of the device will also help to ensure that it is not compromised. This configuration is often used in cases where the firewall is not able to correctly pass L2TP traffic to the VPN device.

One advantage of the VPN in parallel with the firewall is that it offloads traffic from the firewall, resulting in a smaller load on the firewall. Configuration of the VPN is also simpler as there is no configuration of the firewall necessary. This configuration can also reduce the number of licenses needed for the firewall because each VPN connection doesn’t use up an outgoing session license.

If an L2TP device is going to be run in parallel with the firewall it is preferable for the device to be a dedicated VPN device with a dedicated operating system. If the L2TP device runs a full operating system, such as Windows Server 2003 RRAS, it is recommended you perform the following tasks:

If the firewall supports it, there are numerous security advantages to placing the L2TP VPN device in series with a firewall. The concept of layering security is a popular one and the philosophy works well with VPNs. In addition to being able to secure the local VPN device as was described in the previous section, “L2TP in Parallel with Firewall,” having the firewall in series and ahead of the VPN device enables you to filter traffic at the firewall as well. In this way, before the VPN device could be attacked, the firewall would first have to be compromised. Anything that increases the time necessary to compromise a system increases the overall security of an environment.

Most Application Layer firewalls, Proxy Level firewalls, and Port Filtering firewalls will work very well with L2TP. L2TP can be passed through a firewall as well as be translated to an Internet host via Network Address Translation. This allows smaller companies with a single IP address to map L2TP services through a firewall back to an internal VPN device.

To make an L2TP/IPSec virtual private network (VPN) connection, you must first have an Internet connection. If a system tries to make a VPN connection before it has an Internet connection, it will likely experience a noticeable delay, perhaps 60 seconds, and then receive an error message stating that there was no response or that something is wrong with the modem or other communication device.

To use L2TP/IPSec connections, it is useful to understand how an L2TP/IPSec connection works. When a system starts the connection, an initial L2TP packet is sent to the server. This packet is requesting a connection. This packet causes the IPSec layer on the client computer to negotiate with the VPN device to set up an IPSec protected session. This protected session is also called a security association or simply an SA. Based on network speed and latency, the IPSec negotiations can take from a few seconds to several minutes. When an SA has been established, the L2TP session starts. When this session starts, the user will be prompted for a username and password. After the VPN device accepts the username and password, the session setup is completed.

Some common issues with the use of L2TP/IPSec connections include:

Many small networks use a router or firewall with NAT functionality to share a single routable address among all the computers on the network. The original version of IPSec drops a connection that goes through a NAT because it detects the NAT’s address-mapping as packet tampering. Home networks also frequently use an NAT. This blocks the use of L2TP/IPSec unless the client and VPN gateway both support the NAT Transparency standard for IPSec. NAT transparency is supported by Windows Server 2003.

For a common policy, you must choose the following:

For a custom policy, you must configure the following:

It is a fairly common practice to install a VPN device in parallel with the firewall. This is to say that both the firewall and the VPN device have an interface that is connected directly to the Internet. Remote VPN users connect directly to the VPN device and their traffic does not pass through the firewall. This is especially common for PPTP implementations due to the fact that PPTP traffic cannot normally be translated to an internal host via Network Address Translation. Without specific proxy type support for PPTP, the PPTP VPN device requires a routable IP address on the Internet in order to function correctly. Some modern firewalls allow a DMZ function where any undefined traffic will default to a particular device. This effectively places the device outside the firewalls and negates the normal protection provided by the firewall. If this method of passing traffic is employed it should be treated as though it was in parallel with the firewall as opposed to being connected in serial.

This parallel configuration requires that the VPN device itself be well hardened and secured. Careful monitoring of the device will also help to ensure that it is not compromised. Appropriate port filtering and security templates should be applied to the PPTP device where appropriate.

One advantage of the VPN in parallel with the firewall is that it offloads traffic from the firewall, resulting in a smaller load on the firewall. Configuration of the VPN is also simpler because there is no configuration of the firewall necessary. This configuration can also reduce the number of licenses needed for the firewall because each VPN connection doesn’t use up an outgoing session license.

If a PPTP device is going to be run in parallel with the firewall, it is preferable for the device to be a dedicated VPN device with a dedicated operating system. If the PPTP device runs a full operating system, such as Windows Server 2003 RRAS, it is recommended you configure the following items on the Advanced TCP/IP Settings as shown in Figure 18.2 for the network adapter:

Figure 18.2. Port filtering for PPTP.

If the firewall supports it, there are numerous security advantages to placing the PPTP VPN device in series with a firewall. The concept of layering security is a popular one and the philosophy works well with VPNs. In addition to being able to secure the local VPN device as was described in the previous section, “PPTP in Parallel with Firewall,” having the firewall in series and ahead of the VPN device enables you to filter traffic at the firewall as well. In this way, before the VPN device could be attacked, the firewall would first have to be compromised. Anything that increases the time necessary to compromise a system increases the overall security of an environment.

Most modern Application Layer firewalls, Proxy Level firewalls and Port Filtering firewalls will work very well with PPTP. When supported, PPTP can be passed through a firewall as well as be translated to an Internet host via Network Address Translation. This allows smaller companies with a single IP address to map PPTP services through a firewall back to an internal VPN device.

To make a PPTP virtual private network (VPN) connection, you must first have an Internet connection. If a system tries to make a VPN connection before it has an Internet connection, it will likely experience a noticeable delay, perhaps 60 seconds, and then receive an error message stating that there was no response or that something is wrong with the modem or other communication device.

Some common issues with the use of PPTP connections include the following:

For a common policy, you must choose the following:

For a custom policy, you must configure the following:

When using Terminal Services, data is not actually sent between client and server. Only the user interface of the server (for example, the IAS console image and the operating system desktop) is sent to the Terminal Services client. This is called Remote Desktop Connection in Windows XP. The client sends keyboard and mouse input, which is processed locally by the server that has Terminal Services installed. When Terminal Service users log on, they can view only their individual client sessions, which are managed by the server and are independent of each other. This means that other Terminal Sessions don’t have access to the traffic associated with other connection. Additionally, Remote Desktop Connection provides 128-bit encryption between the client and the server.

Like with any type of traffic, IPSec can be used to encrypt communication between the IAS server and the remote client computer that is being used to administer it. This ensures that none of the configuration information is being passed in clear text. To administer the server remotely, the Windows Server 2003 Administration Tools Pack must be installed on the client computer, and the IAS snap-in must be added to the Microsoft Management Console (MMC).

The IAS server provides authentication, authorization, and accounting for connection attempts to a corporate network. It is very important to protect the IAS server and RADIUS messages from unwanted internal and external intrusion. IAS is the key to accessing a corporate network and it is critical that only the appropriate people have access to those keys.

Always take standard precautions to secure an IAS server. Limit access to the system to only a limited number of members of the IT staff. Store the IAS server in a locked and controlled data center. Audit the security logs regularly and be sure to password-protect the system backups. This way the tapes can’t be easily used to create a server that can impersonate the corporate IAS server.

Use the RunAs command to administer local IAS servers rather than logging in with an administrative-level account. You can use the RunAs command to perform administrative tasks when you are logged on as a member of a group that does not have the required administrative credentials.

Because the IAS system is the gatekeeper to remote access it is critical that access via the system is well logged. There are two types of logging offered by IAS—event logging and authentication logging.

Event logging can be used to record IAS events in the system event log. This is primarily used for auditing and troubleshooting connection attempts. This information goes directly into the Windows Server 2003 Event Viewer.

IAS is able to log user authentication and accounting information to log files in text or database format. Optionally it can log to a stored procedure in a SQL Server 2000 database. This type of logging is primarily used for connection trend analysis as well as for billing purposes. This type of data can also be useful as a security investigation tool, giving you another method of tracking down the activity of an unauthorized user.

With either type of logging, ensure that there is sufficient capacity to maintain the logs. In the case of auditing information, one would usually need at least a month of data to accurately perform bill back tasks to various departments. On the security tracking side, it is useful to have many months of data so that it will be possible to track the activities of a suspected hacker. Be sure to back up the log files regularly as they cannot be re-created if they are damaged or deleted.

You can optimize IAS authentication and authorization response times as well as reduce network traffic by installing IAS on a domain controller. Similar gains can be achieved by making the IAS system a Global Catalog as well. This is because when universal principal names (UPNs) or Windows Server 2003 domains are used, IAS will use the global catalog to authenticate the users. Making the IAS a global catalog or at least having a global catalog on the same subnet as the IAS system will reduce the time needed to perform the authentication.

In a large RADIUS implementation where there is heavy authentication traffic, you can effectively load balance the RADIUS environment by doing the following:

This is especially useful in large 802.1x implementations where wireless connections are using certificates to authenticate via IAS/RADIUS to gain access to an internal network.

The Microsoft Connection Manager (CM) is a client dialer for connecting to network resources on a public network or to private networks over the Internet. CM sits on top of Dial-Up Networking (DUN) and simplifies the network access experience for end users. This dialer client can be preconfigured for the users by the Administrator by using the Connection Manager Administration Kit (CMAK).

The Connection Manager Administration Kit is a step-by-step wizard that creates custom service profiles and enables you to append applications. The Service Profile is a collection of connection information tailored to specific employees. This connection information is combined with applications and Connect Actions to create an Installation Package.

When installed, the Service Profile merges with the resident Connection Manager dialer to enable employees to easily connect to a public or private network. Through the use of the CMAK, you can standardize and simplify the configuration of remote connectivity and improve the end users’ connection experiences.

The CMAK can preconfigure any of a variety of items for each Service Profile within an Installation Package.

As companies scale the number of supported users they often replace banks of modems with dedicated hardware such as routers with multiple asynchronous interface cards. This enables you to bring in T-1 lines and create 23 dial-up connections rather than bringing in hundreds of analog lines. This concept scales well but eventually even it becomes unrealistic. For companies that must support huge numbers of dial-up connections there are Softmodems.

A Softmodem is a device that enables you to connect a large circuit connection, like a T-3 or an OC-3, and create a very large number of dial-up connections. Rather than have dedicated circuitry for each modem device, a Softmodem leverages a central processor to effectively create multiple virtual modems. This technology is scalable well into the ISP class of service.

As companies grow past a few modems and a few analog lines connected to a RAS device it makes sense to compare prices and costs against aggregating those connections into a larger circuit.

Racks of modems take up valuable space in a corporate data center. Racks of modems can be replaced by routers with asynchronous cards and Telco circuits to save space and improve performance. Consolidated devices are often more reliable than common off-the-shelf modems.

Let’s say, for example, that analog phone lines cost a company $40/month. Let’s say a T-1 line in the same location costs $600/month. A T-1 line provides the equivalent of 23 analog phone lines. After the company breaks 15 analog lines, the T-1 line is less expensive. Lines 16–23 effectively become savings that would apply against any additional costs of the consolidation device versus the costs of the old style modems. In some cases, the consolidation device will be less expensive than the RAS device and the modems would have been.

These consolidation devices usually support RADIUS for authentication and auditing as well as SNMP for management and monitoring. Between the savings in monthly costs and the reduction in space used in the data center, these solutions can be very viable for companies with even modest RAS needs.

RADIUS, or Remote Authentication Dial-in User Service, is the de facto standard for authenticating and tracking remote access users. RADIUS is used for dial-up, VPN, and even wireless connections. Microsoft’s IAS is its implementation of RADIUS.

A RADIUS remote access environment has three primary components: Users, Remote Access Servers, and the RADIUS server. Each user connection is a client of a Remote Access Server, which, in turn, is a client of the RADIUS server.

The user is the person who is trying to gain remote access to the corporate network from home or from the road. Usually, the user has a PPP or perhaps SLIP dialer that enables him to dial into a Remote Access Server at the corporate office and become a remote node on the network, with IP or IPX access to network resources.

The Remote Access Server (or RAS) is a device that does the following:

Because most RAS devices can handle multiple connections at once, a corporate network might include a single RAS or multiple RASes working in tandem to handle the traffic.

The RADIUS server is the device that accepts authentication requests from one or more Remote Access Servers, performs the authentication, and responds with the result. This result is either an accept or a reject. The RADIUS server also provides Accounting services that not only allow a network to handle “charge back” to departments that use the remote access system, but also provides for logging and auditing functions.

Typical installation of RADIUS will include a single RADIUS server to handle all the Remote Access Servers. An additional RADIUS could be added to increase redundancy. It is always preferable to not have a single point of failure in an enterprise RAS system. Some companies will have Remote Access Servers at multiple sites and could elect to have a separate RADIUS server at each site. If the various sites are sufficiently linked over a WAN of reasonable speed or over the Internet, a single RADIUS server can be used to handle multiple Remote Access Servers at multiple sites. This allows a single pair of RADIUS servers to be leveraged enterprisewide.

It is useful to understand the steps involved in a typical transaction in which a user is successfully authenticated via RADIUS:

In an authentication transaction, there is password information that is transmitted between the RADIUS server and the RAS device. The password information is encrypted via secret key that is entered at both the RAS device and the RADIUS server.

This password information originates from the user, usually as part of PPP negotiations. In a sense, the RAS device is just an intermediary device. It is easier to think of the authentication process as being a transaction between the user and the RADIUS server.

There are a few types of authentication transactions used between a remote access user and RAS that are supported by the Windows Server 2003 implementation of RADIUS:

Password Authentication Protocol is a fairly simple protocol. The user sends her password to the RADIUS server, and the RADIUS server validates it. This validation is performed either against RADIUS’ own database or against Active Directory. One of the drawbacks to PAP is that the password is initially sent unencrypted. RAS encrypts the password before forwarding it to the RADIUS server and the RADIUS server decrypts it using a shared secret key. Ultimately, the RADIUS server has the password in clear text form and is able to make use of it directly for authentication.

Challenge Handshake Authentication Protocol is much more secure in that it never sends passwords in clear text over any communication link. With CHAP, the RAS device generates a random number (the challenge) and sends it to the user. The user’s PPP client creates a digest, which is a one-way encryption, of the password concatenated with the challenge. This digest is sent to the RAS device. Because the digest is a one-way encryption, the RADIUS server cannot recover the password from the digest. It doesn’t need to recover the password. Instead it can perform the identical digest operation using its own copy of the user’s password stored in its database. If the two digests match, the user is authenticated successfully.

Extensible Authentication Protocol is an extension to the Point-to-Point Protocol (PPP). EAP supports arbitrary authentication methods using credential and information exchanges of arbitrary lengths. EAP was developed as a result of an increasing demand for authentication methods that leveraged third-party security devices and provide an industry-standard architecture to support additional authentication methods within PPP.

One of the most compelling benefits of Active Directory was the ability to manage users and their computers via Group Policy Objects. System settings, services, applications, and many other items could be controlled on a per-user or per-computer basis. One of the classic issues faced by administrators was how to manage remote users so that they were not impacted by their relatively slow connection speed. Publishing full applications to remote users would be a very slow and intrusive process. Taking users and computers in and out of OUs would be nearly impossible to manage to try to reflect their status of local or remote. The easy solution to this issue is to take advantage of the fact that RRAS can hand out its own block of IP addresses. You can pretty safely assume that if a client machine has an IP address that is handed out by the RRAS system, that client is either dialed in or connecting via VPN. By creating a site within Active Directory that contains the subnets owned by the RRAS server, specific GPOs can be applied to that site that take into account the reduced bandwidth.

Windows Server 2003 Routing and Remote Access Services supports not only client-to-server VPNs but also site-to-site VPNs. By creating VPN interfaces in addition to having physical interfaces, RRAS is able to route IP traffic not only throughout the network but across VPN connections as well.

To create a site-to-site VPN, do the following: