Deploying Virtual Private Networks with Microsoft Windows Server 2003 (Technical Reference)

In all our discussions of remote access solutions for VPN, we will be working with connections over the Internet. This means we are reliant on the Internet, which is the intermediate network, to provide certain services and transports to the users. You need to check several items to make sure the Internet communications system will be able to connect your users to your VPN server. To create a VPN connection to a VPN server across the Internet, you need to verify the following items first before any connections can be created:

• The VPN server name must be resolvable. Ensure that the Domain Name System (DNS) names of your VPN servers are resolvable from the Internet by placing an appropriate DNS record either on your Internet DNS server or on the DNS server of your ISP. Test the resolvability by using the Ping tool to ping the name of each of your VPN servers when directly connected to the Internet. Because of packet filtering, the result of the Ping command might be “Request timed out,” but check to ensure that the name specified was resolved by the Ping tool to the proper Internet Protocol (IP) address.

• The VPN server must be reachable. Ensure that the IP addresses of your VPN servers are reachable from the Internet by using the Ping tool to ping the name or address of your VPN server with a 5-second timeout (using the -w command line option) when directly connected to the Internet. If you see a “Destination unreachable” error message, the VPN server is not reachable.

• VPN traffic must be allowed to and from the VPN server. Configure packet filtering for PPTP traffic, L2TP/IPSec traffic, or both types of traffic on the appropriate firewall and VPN server interfaces connecting to the Internet and the perimeter network. For more information, see Appendix B, “Configuring Firewalls for VPN.”

VPN Server Name Resolvability

In most cases, you want to reference the VPN server by name rather than by an IP address, as names are much easier to remember. You can use a name (for example, VPN1.example.microsoft.com) as long as the name can be resolved to an IP address. Therefore, you must ensure that whatever name you are using for your VPN servers when configuring a VPN connection can be resolved to an IP address using the Internet DNS infrastructure.

When you use names rather than addresses, you can also take advantage of DNS round-robin load balancing if you have multiple VPN servers with the same name. Within DNS, you can create multiple records that resolve a specific name to different IP addresses. In this situation, DNS servers send back all the addresses in response to a DNS name query and cycle the order of the addresses for successive queries. Because most DNS clients use the first address in the DNS query response, the result is that VPN client connections are on average spread across the VPN servers.

VPN Server Reachability

To be reachable, the VPN server must be assigned a public IP address to which packets are forwarded by the routing infrastructure of the Internet. If you have been assigned a static public IP address from an ISP or an Internet registry, reachability is typically not an issue. In some configurations, the VPN server is actually configured with a private IP address and has a published static IP address by which it is known on the Internet. A device between the Internet and the VPN server translates the published and actual IP addresses of the VPN server in packets to and from the VPN server. This device is known as a network address translator (NAT), and typically these devices are either routers or firewalls that are NAT–capable.

Previously when using L2TP/IPSec, there was an issue with going across NAT boundaries because IPSec, which maintains the encrypted tunnel for the communications, could not negotiate security associations (SAs) across NAT devices. This issue has been resolved by Microsoft with the implementation of NAT traversal (NAT-T). NAT-T allows Internet Key Exchange (IKE), the negotiation protocol of IPSec, to negotiate security associations (SAs) across NATs. NAT-T is a feature of Windows Server 2003, and you can add NAT-T to all client operating systems in one of the following ways:

• When using Windows 98, Windows 98 SE, Windows Me, and Windows NT 4.0, you can apply the Microsoft L2TP/IPSec VPN Client, which has NAT-T included in the package.

• When using Windows XP or Windows 2000, a new hotfix is available as of May 2003 for Windows 2000, and July 2003 for Windows XP, via Windows Update that will add NAT-T to the operating system. These hotfixes will be added to Windows XP SP2 and Windows 2000 SP5 when those service packs are released.

Although the routing infrastructure might be in place, the VPN server might be unreachable because of the placement of firewalls, packet filtering routers, NATs, security gateways, or other types of devices that prevent packets from either being sent to or received from the VPN server computer.

VPN Servers and Firewall Configuration

There are two approaches to using a firewall with a VPN server:

1. The VPN server is attached directly to the Internet, and the firewall is between the VPN server and the intranet. In this configuration, the VPN server must be configured with packet filters that allow only VPN traffic in and out of its Internet interface. The firewall can be configured to allow specific types of remote access traffic.

2. The firewall is attached to the Internet and the VPN server is between the firewall and the intranet. In this configuration, both the firewall and the VPN server are attached to a network segment known as the perimeter network (also known as a demilitarized zone [DMZ] or a screened subnet). Both the firewall and the VPN server must be configured with packet filters that allow only VPN traffic to and from the Internet.

For the details of configuring packet filters for the VPN server and the firewall for both of these configurations, see Appendix B, “Configuring Firewalls for VPN.”