Throughout the book, there are suggestions, recommendations, and warnings on different areas, topics, and technologies. These items are the “best practices” of deploying Microsoft virtual private network (VPN) technologies. Rather than making you hunt down all the best practices for deploying Microsoft VPN, this appendix collects them in one place for quick reference.
If there is one mantra that the Microsoft Windows Networking and Communications group lives by, it is “Stick to the IETF RFC standards.” If we need to make a new protocol or procedure to use in Microsoft Windows, we always present it for consideration to the Internet Engineering Task Force (IETF) so that everyone can benefit from the work and we can push for conformity across the industry on communication and security protocols. VPN is a big area that we work with standards on, and it is comprised of many technologies (routing, tunneling, authentication, name-resolution, provisioning, quarantine, and so forth) meshed into a single solution. The only way to successfully augment or interoperate with the Windows operating system is to make sure that all communications are based on standards. The following sections present some standards to which you should conform to ensure your VPN solution works with every vendor throughout the industry.
We have outlined two tunneling protocols in this book: Point-to-Point Tunneling Protocol (PPTP) and Layer Two Tunneling Protocol with Internet Protocol Security (L2TP/IPSec). Both of these tunneling protocols are ratified by the IETF, but more to the point, L2TP/IPSec is the only IPSec based tunneling protocol that is approved for use by the IETF. The following are our recommendations for use.
Our recommendation is to use L2TP/IPSec whenever possible for your tunneling protocol because it takes advantage of IPSec for encryption and data integrity. This protocol also uses certificates for authentication and encryption processing. The L2TP portion of the protocol allows for full Point-to-Point Protocol (PPP)–based session management and control, and therefore, it gives you a flexible and powerful set of traffic management tools to work with.
PPTP is a good alternative and is also PPP-based, but its encryption capabilities are primarily password encryption based on Microsoft Point-to-Point Encryption (MPPE), not IPSec, thus allowing for weak passwords which can compromise the security process. L2TP/IPSec relies on certificates, which takes the element of poor password choice out of the equation, thus making for a much more secure implementation. This is not to say that PPTP is a bad choice, but if you decide to use PPTP you absolutely must use a strong-password policy with your users and make sure you have ways to make users adhere to this policy. Otherwise, the system can become vulnerable and weak. (Much of the concern in the industry about PPTP focuses on PPTP’s reliance on passwords for its security.)
Almost every vendor uses IPSec tunnel mode (TM) for their remote access VPN solutions. This is mostly because of the previous lack of ability for IPSec to traverse Transmission Control Protocol/Internet Protocol (TCP/IP) network address translator (NAT). This technical issue has been resolved by Microsoft with the implementation of IPSec NAT traversal (NAT-T) in Windows Server 2003 and all the Windows client operating systems. The fact is that IPSec TM has been rejected by the IETF as a viable solution because it makes organizations that use it susceptible to man-in- the-middle attacks. Microsoft does not implement technologies that have not been approved by the IETF for networking protocols, so IPSec TM will not be supported by Windows servers or clients in the base operating system.
Another issue with IPSec TM is that because of the lack of a standard for vendors to follow, each organization that has implemented IPSec TM has a proprietary solution for it that does not interoperate with other implementations. In other words, if Vendor A has an IPSec TM solution and Vendor B has one as well, Vendor A’s IPSec TM cannot interoperate with Vendor B’s IPSec TM. This situation leaves the customer with a vendor-specific proprietary solution. Microsoft advocates L2TP/IPSec because it is standards based and every major vendor with VPN services supports and interoperates with it. Vendors need to support it or they cannot claim to be IETF compliant.
Organizations using Microsoft Windows can choose from several authentication protocol options.
If you are using certificates, you should choose Extensible Authentication Protocol- Transport Layer Security (EAP-TLS) to take advantage of the security and functionality of the certificate services available to you. If you are not using certificates, be sure to use Microsoft Challenge-Handshake Authentication Protocol version 2 (MS- CHAPv2) to take advantage of the mutual authentication and encryption processes during the authentication negotiation. Compared with using Password Authentication Protocol (PAP) or Challenge-Handshake Authentication Protocol (CHAP), the IT Administrator will have little to no overhead when using MS-CHAPv2, and the improvements in security are immense. Do not use MS-CHAP because it has no benefits that are found in MS-CHAP v2.
Throughout the book, you have the option of using PPTP or L2TP/IPSec. The major difference between them is that PPTP does not require a certificate infrastructure to be deployed. You’ll notice that even when using PPTP in this book, we recommend that you use EAP-TLS as the authentication protocol and use certificates for the identification of the user and computers. Certificates are absolutely the best way to secure the network, and Microsoft’s recommendation is to use certificates for all authentication purposes from now on. The perfect time to implement and start taking advantage of the security and flexibility that certificates provides is when you are rolling out a VPN solution for mobile networking.
When servicing more that 750 people on a VPN, you should start load-balancing your users on more than one VPN server by using the Network Load Balancing (NLB) feature that is available in Window Server 2003, Enterprise Edition, and Windows Server 2003, Datacenter Edition. As more and more users are added to the VPN, spreading out and balancing the load across multiple gateways increases scalability and provides redundancy.
Windows Server 2003, Standard Edition is capable of handling up to 1000 simultaneous connections and up to 5000 simultaneous connections on Windows Server 2003, Enterprise Edition. In reality, though, most standard network adapters these days can support a throughput of only 100 Megabits/second (Mbps). Depending on the amount and type of traffic being processed over the VPN connections, this capability can become overloaded quickly. NLB gives you more scalability and redundancy in the case of a hardware or link failure.
We recommend that you use Internet Authentication Service (IAS) for your Remote Authentication Dial-In User Service (RADIUS) server needs and functionality. This recommendation is not a marketing ploy like “use our brand of cheese when eating our brand of crackers.” There are important benefits to using IAS for the RADIUS needs of your organization rather than using a third-party RADIUS server. For starters, IAS uses industry-standard RADIUS protocols to handle all the work, so it is fully compliant with third-party RADIUS solutions. Also, Microsoft IAS gives you more capabilities because it has extensions beyond the base industry-standard functionality through its integration into the Active Directory directory service. It also has the ability to work with groups and group policy, which is a major component in applying VPN resources to your user base.
Another factor is the structured query language-Extended Markup Language (SQL- XML)–based logging capabilities of IAS. These capabilities allow for centralized and database-capable authorization, authentication, and accounting (AAA) logging across the enterprise for all access solutions, including remote access over VPN.
Finally, using IAS will enable single sign-on solutions across the enterprise, incorporating the VPN solutions into all other access-controlled systems. This capability means that you have to create user accounts and directory services only once in a central control location for your organization’s needs.
Use redundant IAS servers, and make sure that they stay synced. The procedures for how to set them up are shown in Chapter 6, “Deploying Remote Access VPNs” and in Chapter 9, “Deploying Site-to-Site VPNs.” Command-line operations can be used to make sure these redundant IAS servers are synced when they are installed. (Please refer to the documentation in the referenced chapters, and follow the complete procedures outlined there.) Because the focus of this book is VPN and not IAS in particular, make sure to search for IAS in Help And Support Center, and read the articles at http://www.microsoft.com/ias for information and best practices on IAS operations.
Allow privileges for remote access only to the appropriate users, and make sure that a proper remote access policy is in place.
Allowing all users to have access to the VPN systems of the company is the easiest thing to do, but often it is not the most practical thing to do. Limit privileges for remote access systems to users who have a definite need for them. Allow access only to full-time employees and contractors that require access. By doing so, you reduce the attack surface a hacker has to attack your system, the need for redundancy, the load on the gateways, and the amount of extraneous access to the Active Directory environment. If you are using certificates, restricting access also cuts down on the amount of certificate revocation you will need to do as contractors and partners complete their projects.
Use the automated packet filter systems incorporated into the Routing And Remote Access service for remote access connections.
You can turn off this default functionality if you want. Many consultants will tell you there is an increase in performance by doing so, but if the load is that high you should implement load-balancing to take care of the overhead, not reduce security. Also, do not add too many packet filters to the automatically plumbed list. Every packet filter does affect throughput and performance of the system, so be frugal in your use of packet filters.
Unless there is no avoiding it, do not use split-tunneling.
To comply with industry standards, Microsoft allows for split-tunneling on VPN systems through the use of Connection Manager. You can also implement split tunneling by using DHCPInform messages and the Classless Static Routes DHCP. Although Microsoft provides this support, the recommendation is that you do not deploy split-tunneling. Split-tunneling has an inherent security hole on the client side of the link that could result in someone gaining unauthorized access to the corporate intranet. By disabling routing on the VPN client and disabling split-tunneling, you immediately prevent a major security risk. In their own implementation of VPN, one of the options that Microsoft checks for on each VPN client is the disablement of split-tunneling on the VPN client prior to allowing access to the Microsoft intranet. We recommend that you do the same for your company.
Remember that quarantine relies on running a client script—and the longer the script, the longer the quarantine check and the slower the access is to the corporate LAN. Make the script reasonable, less than 30 seconds of processing time.
Quarantine can be a very powerful tool, and it is highly recommended that you use the quarantine features of Windows Server 2003 for client conformity checks prior to allowing access to the corporate LAN. Keep in mind the following issues when deploying quarantine:
Keep the client-side scripting short and simple. If the script takes too long to run, the user will incorrectly assume the connection is stalled and will naturally cancel the connection and start over. This reaction causes the whole process to start again. A good way to mitigate this is to put a graphical progress bar on the client screen so that the user knows something is happening and that progress is being made. Microsoft Operations Technology Group has done this for its VPN users, and it has been very successful. Quarantine operates as a custom connect action on Connection Manager, so see Chapter 7 for more information.
Use a quarantine network rather than allowing access to individual resources in the corporate LAN. You’ll be tempted to just punch through access to resources that are already in place, but remember that every quarantined user will be getting IP filters created to them for quarantine access. To cut down on filter lists and processor usage, create a small quarantine network that has all the resources and then allow access for quarantined users to that network segment. This means that only one IP filter needs to be plumbed (the filter that allows access to that IP segment), and LAN access is still protected.
If at all feasible, you should use a form of two-factor authentication to authenticate the users.
In today’s computing environment, usernames and passwords are generally not adequate to ensure the security of an organization’s resources. There are just too many ways to lose control over such a simple mechanism for identity control. With the use of two-factor authentication—something you have plus something you know—you have a much greater assurance of the security of the system. Smart cards fulfill the “something you have” part of the equation, while tokens or biometrics fulfill the “something you know” part. Microsoft Corporation, by requiring its users around the world to log on to its networks with smart cards, has one of the most extensive deployments of smart cards in the industry.
The two primary items you need to implement certificate-based authentication solutions into your environment—even if you are not going to do it immediately—are certificates and EAP-TLS. You must set up your current VPN systems to use these two items. EAP methods are the technology that enables two-factor authentication, and EAP-TLS is the mandatory factor if you are planning to do two-factor authentication either now or in the future.
To get more information on the rollout and implementation of the Microsoft Corporate deployment, contact your local Microsoft representative. You can also check out http://www.microsoft.com/vpn and http://www.microsoft.com/ias for white papers and deployment guides on EAP-TLS authentication solutions.
Use Connection Manager and Phone Book Services to enable your client computers for VPN connectivity.
The functional phrase here is “ease of use” for your users. When going through Chapter 6, you got a good feel for the complexity of setting up VPN connectivity on either the client or the server. It’s not a simple process and requires users to make certain choices they are probably not ready or willing to make. By using Connection Manager (CM), you take away all of that pain for your users and save yourself, as the administrator, a lot of support time and aggravation. By building CM profiles for your users, all they have to do is install the profile and click Connect and they are on the VPN system. If they are road warriors traveling frequently from city to city, you can automate their connectivity by providing Phone Book Services. See Chapter 7 for more information on setting up Connection Manager and incorporating advanced features such as quarantine for your user base. Also read Appendix E, “Setting Up Connection Manager in a Test Lab” for full details and procedures on how to set up and deploy CM with Phone Book Services.
There are special considerations when using site-to-site VPN rather than remote access, and we need to cover some best practices that go with site-to-site VPN setups.
Use two-way initiation of a site-to-site link only if there is vital information the organization needs to access at the remote site.
There are two reasons for limiting two-way initiation in this way:
It will keep costs down on communications bills. Remember, the site that contains the answering router must always have an “always-on” link to the Internet. To keep the costs of the remote site communications down, you should consider using one-way initiation so that only pertinent traffic originating from the remote site can activate the link.
It will reduce the load on the VPN answering gateway at the primary site. Remember that the primary site is most likely handling multiple connections and operations at once. When using demand-dial connections, the originating gateway will have to analyze all traffic with the demand-dial filters, even if the traffic is not destined for the VPN link, to assess it for VPN activation. Make the remote gateway take care of this responsibility, and take the burden of traffic analysis off of the main site’s gateway.
There will be situations in which it makes more sense to do two-way initiation, such as in the case of domain controller, e-mail, or database synchronization. To reduce the burden on the traffic analysis, schedule these activities appropriately on the servers and have them coincide with one another’s schedules. By doing this, the link can be brought up and down in a uniform fashion and not cause “flapping” on the network by constantly going up and down.
If you are contemplating using two-way initiation, you should also consider using a persistent connection.
The choices are relatively simple:
“Do I have a permanent connection to the Internet on both sides of the link?” For example, the remote site uses a broadband connection to the Internet instead of a dial-up connection. If the answer is “yes,” ask the following question.
“If I do have the permanent connections on both sides, is there any reason I would want to tear down the link?” For example, no one is in the office and I’m worried about security breaches; or I have two sites I’m servicing, and one is in New York and the other in India. If the answer is “no,” you should consider using a persistent link between the sites. Using a persistent link reduces overhead in administration, reduces the need for extensive deployment and management of complex demand-dial filters, and reduces the logging and auditing needed to maintain the link. Finally, if you are using dynamic routing, it reduces flapping of the link and has less effect on the dynamic routing protocols.
On site-to-site links, unless there is a really serious reason not to, use static routes on the gateways instead of dynamic routes.
Although at first glance it might seem attractive to use dynamic routing, consider the following issues:
The network address allocations between the primary and remote sites of a corporation rarely change, and if they do change it is usually only to add a single subnet to the routing. By definition, this is an ideal place to use static routes because route summarization can be used to cut down on the confusion and management of the TCP/IP network.
If you are not using a persistent connection, the link will be going up and down on a semi-regular basis. This will look like a flapping link to the dynamic routing protocol, and it will cause a network convergence to occur in the area of the VPN gateway connection. For anyone who has set up a dynamic routing architecture, this is undesireable behavior. By using static routes, flapping will not occur and the dynamic routing architecture will not be affected by on-demand, site-to-site VPN connections.
Always use certificates whenever possible on site-to-site links.
By using certificates for all VPN communications, you eliminate the possibility of a rogue server capturing a set of username/password credentials and impersonating the remote site. If the default method is to use certificates, this impersonation attack is not possible and the VPN architecture is much more secure. Even if you decide not to use certificates for remote access VPN (and we highly recommend that you do), we still recommend that you use certificates for site-to-site. Site-to-site VPN links are designed to occur without any human intervention, thus making them more attractive to hackers.
When it comes to troubleshooting the VPN architecture, use the procedures outlined in the book in the order that they appear.
The troubleshooting procedures in this book are designed to rule out issues step by step. They are designed to drill down to the root causes of setup failures and problems. VPN is not a technology that responds well to a shotgun method of troubleshooting—many services and systems need to work with each other to make a VPN setup operate successfully. Take the time, use our procedures, and make sure to check out the sample logs and troubleshooting samples included on the companion CD for this book. Our test team in the Windows Division at Microsoft Corporate uses the same logs and tools to troubleshoot, so you should be successful in troubleshooting VPN every time.