You can construct a VPN in a myriad of ways, but constructing your VPN is just your first step. After you construct the VPN, you have to troubleshoot it.
A minimal VPN implementation has a RAS PPTP server connected to the Internet, a client connected to the Internet, and a PPTP connection between the server and the client. As long as ISP service or Internet connectivity is available, clients can connect to your server or LAN from anywhere in the world. However, most VPNs aren't as simple as a connected server and client. More often, the VPN server is on a routed LAN segment, often behind a firewall, and the client connection uses an ISP network, which also employs routers and firewalls.
You can build a PPTP server as a standalone server or as a domain controller in a couple of steps: You install RAS and the PPTP protocol and configure PPTP ports the same way you configure dial-up connections. Windows NT client setup is equally straightforward: You load PPTP and configure the PPTP connection to locate the PPTP server over the Internet. With such a simple setup, you might assume that the VPN connection will function properly the first time. However, administrators spend a fair amount of time troubleshooting before they successfully deploy a new VPN.
Troubleshooting a VPN, like troubleshooting any WAN connectivity problem, is complex because the data travels through many links before it arrives at its destination. For example, data typically flows from the client to an ISP's router, through a firewall, across the ISP's network, maybe across additional ISPs' networks, to the company's router, to a firewall or proxy server, and finally to the destination PPTP server.
When a client connects to an ISP (this connection uses the Point-to-Point Protocol—PPP—portion of the VPN connection), the ISP assigns the client a TCP/IP address, a DNS server address, and a default gateway. When the client initiates a PPTP connection, that action creates a second TCP/IP session (this session is the tunnel portion of the VPN connection), which is embedded inside the first session and provides packet encryption and encapsulation. When the client connects successfully, the VPN server assigns the client a second IP address, a second DNS server address, frequently a WINS server, and another default gateway. At each link in the connection, something can go wrong. Knowing the common configuration and connectivity problems and having a troubleshooting procedure to follow will help you debug your VPN connections.
VPN Server Recommendations
If possible, start with an NT server that has a minimum number of services installed and limit the protocols to TCP/IP and PPTP. You'll save time if you update your server with service packs before you try to debug client connections. NT 4.0 Service Packs 5 (SP5) and SP6a correct numerous problems with PPTP connections, including performance problems related to fragmented packets, dropped connections, and refused connections. I have four more recommendations to help you keep the server configuration simple and straightforward for troubleshooting purposes.
Configuring a multihomed server. If your PPTP server has two network cards, one for the LAN and one for the WAN, leave the gateway field on the LAN adapter blank (don't enter zeros; leave it blank). In the gateway field of the WAN network interface, enter the TCP/IP address that your ISP provides; the gateway address usually points to a router at your ISP. You need the blank gateway so that the server can route network packets to the client. Leaving the LAN gateway blank is standard practice when you configure a server with multiple network adapters. For test purposes, I recommend you manually enter the TCP/IP address and WINS server address for the LAN NIC (instead of using DHCP to assign these values).
Configuring RAS. When you install RAS, configure only as many VPN ports as you truly need to support active client connections. Although each RAS server can support 256 concurrent connections (assuming you have the bandwidth for all this activity), you might need only 40 concurrent connections to support your mobile users. Next, configure the server to assign client addresses from a static address pool, rather than assigning addresses from a DHCP server. If you configure RAS to assign client addresses from a static address pool, clients inherit the DNS and WINS settings from the RAS server. If your RAS server can browse the network, clients should also be able to browse the network with the same settings.
If you prefer DHCP, verify that DHCP scope option 44 (WINS/NetBIOS name server) points to the WINS server and that scope option 6 shows the address of your DNS server. When you don't define these options, you almost guarantee problems with client browsing.
Enabling PPTP filtering. Configuring and testing a VPN server that resides outside your firewall is easier than testing a server inside your firewall because avoiding the firewall removes one link in the test-and-debug chain. If you aren't running your server in a highly secure environment, you can place the server outside the firewall and restrict incoming VPN traffic to PPTP packets only. To enable PPTP filtering, right-click Network Neighborhood, select Properties and Protocols, double-click TCP/IP Protocols, and select the WAN adapter and Advanced. Then, select the Enable PPTP Filtering check box. When you enable PPTP filtering, the server will refuse all non-PPTP requests. I've tested this feature, and it's an effective method for restricting incoming sessions to PPTP-only connections. PPTP filtering has one important side effect: When you enable filtering, LAN clients can't use the RAS server's WAN connection to browse the Internet because filtering disables incoming HTTP and FTP traffic.
If you want the VPN server to restrict incoming packets to PPTP and host an Internet-accessible Web site, you can make a Registry modification that lets other packets through the filtered interface to the local system only. Go to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RASPPTPF\ Parameters Registry key, and add the value entry AllowPacketsForLocalMachine of REG_DWORD data type 1. When you make this modification, you expose the RAS server to the Internet yet restrict incoming connections to the VPN server, so remote clients can't see any other resources on your network.
Using firewall ports. Before you place a VPN server behind a firewall, verify that your firewall software accepts PPTP packets. Sometimes firewall software packages (including some versions of Check Point Software Technologies' FireWall-1) don't accept PPTP connections when you configure the firewall with Network Address Translation (NAT—for information about NAT, see Zubair Ahmad, "Windows 2000's Network Address Translation," February 2000). In this situation, the client's attempt to connect to the RAS server produces the error message Event ID 721 PPP remote peer not responding. When you place a VPN server behind your firewall, be sure to enable IP protocol 47 (Generic Routing Encapsulation—GRE) and TCP port 1723. The connection uses port 1723 for general housekeeping, such as PPTP tunnel creation, maintenance, and termination. Port 47 passes tunneled data between the client and the server (including the GRE protocol), and you also need TCP port 1723 \[established\] if you're supporting RAS server-to-server VPN connections.
Before you try to connect a VPN client, verify the server's TCP/IP settings on both NICs and make sure your RAS server can perform all typical network operations (e.g., browse the LAN, connect to LAN resources, connect to the Internet, browse the Internet). Then, enable dial-up permission for your test account. You might also want to enable PPP logging for your initial test.
Client Troubleshooting
To operate successfully, a PPTP client must properly maintain two sets of TCP/IP stack settings: one for the ISP and Internet connection and one for the VPN server connection. The client's routing table must also have two entries: one that directs network packets to the ISP for Internet browsing and one that points to the VPN server interface for LAN browsing. When the stack settings are incorrect, clients experience problems. In general, NT clients maintain separate TCP/IP stack settings, but Windows 95 clients typically have trouble with stack settings when the clients have a network card and a modem. After establishing a PPTP connection, the Win9x default gateway might still point to the ISP, which prevents the client from successfully browsing the LAN. Let's take a look at the five most common client connectivity problems.
Client can't connect to the PPTP server. The first problem you might encounter is the client's inability to connect to the PPTP server. You need to check for three possible causes of this problem.
Client can connect but can't log on. The second connectivity problem you might encounter is when a connected client can't log on. You need to check three possible causes for this problem.
Microsoft introduced MSCHAP V2, a more secure version of MSCHAP, after SP3. You can make a Registry edit on the server and on Windows clients to force clients to authenticate only with MSCHAP V2. However, when you make this modification, clients that don't support MSCHAP V2 (which is a proprietary Windows protocol) can't log on successfully. Thus, this change can prevent UNIX and Macintosh systems from logging on to your VPN server.
To obtain troubleshooting information about logon failures, enable logon auditing in User Manager and try the connection again. You can get a good picture of the roadblock when you look at the records in NT Event Viewer's Security Log. You can see if the username is invalid, if the password has expired, if the computer lacks a valid account, or if no VPN ports are available.
When a user does log on successfully, the application event log records the date and time of the logon. You'll find another event in the event log that records the user's logoff time and the duration of the session.
Client can log on but can't browse the LAN. You can also encounter a situation in which the client has logged on but can't browse the LAN. To begin to troubleshoot this problem, make sure you set the workgroup to the target NT domain name on all Win9x clients. Next, you might not want your clients to browse if you have more than 15 or 20 nodes visible because browsing a large network over a slow dial-up connection can be extremely frustrating. Predefining or manually mapping Uniform Naming Convention (UNC) connections to needed shares and resources after establishing the PPTP session is far more user-friendly. Finally, you need to understand how the four TCP/IP settings affect your network connection. (For more information about these TCP/IP settings, see the sidebar "Important Client TCP/IP Settings.") When you support users who work at home with a permanent high-speed connection, browsing the LAN remotely is a viable option. After checking these components and reviewing the TCP/IP settings, you can use the following items to troubleshoot the browsing problem.
If the client still can't browse, try connecting from the client to a network share. For example, use the Net Use Z: \\myserver\myshare command. Manually connecting to shares is frequently a good workaround that lets users access files and printers while you're in troubleshooting mode.
If you still can't browse, you need to review the VPN server configuration. Many server problems affect client browsing, but the list of potential problems and solutions is too long to cover in this article. You'll find many excellent pointers if you search for PPTP client browsing and multihomed browsing in the Microsoft Knowledge Base at http://support.microsoft.com/search/default.asp. The search will produce a list of articles that document problems specific to multihomed servers and browsing (e.g., browsers on each NIC don't exchange browse lists), PPTP connections, WINS server location, and more.
| RELATED ARTICLES IN PREVIOUS ISSUES |
| You can obtain the following articles from Windows 2000 Magazine's Web Site at http://www.win2000mag.com/articles. KEN MILLER AND RICHARD BRACKETT "Configuring VPNs," December 1999, InstantDoc ID 7529 ERIC PEARCE "Managing VPNs with PPTP," January 1999, InstantDoc ID 4695 PAULA SHARICK "PPTP Provides Secure Connectivity to Your Corporate Network," March 1999, InstantDoc ID 4877 |
Connected client can't browse the Internet. I've seen this problem several times on Win95 clients that have both a network card and a modem. A client can't browse the Internet while its VPN session is active. This problem occurs in two common scenarios. First, the VPN server might not let remote clients access the Internet when they have a connection. In this case, when you close the VPN connection, the client can browse the Internet because the default gateway reverts to the gateway that the ISP specifies. Second, Win95 might overwrite the ISP gateway with the VPN server-defined gateway when the client connects, so the client has no path to the Internet. You can manually add a static route to the ISP's default gateway by trying the VPN gateway first and the ISP gateway second to solve this problem.
Connected client doesn't appear in Network Neighborhood. I worked with a network engineer who encountered the problem of the client not appearing in Network Neighborhood on the LAN side, even with a fully functional VPN client connection. You configure the client's PPTP connection with TCP/IP only and connect and authenticate to the VPN server. Then the client can browse all LAN resources. When the remote client expands Network Neighborhood, the client shows itself and all other clients in its browse list, but the remote system never appears in Network Neighborhood on the LAN. If you want remote clients to appear on the LAN browse list, you need to install NetBEUI on the RAS server and RAS clients. This peculiarity is a known problem with RAS, but no fix is available at press time.
Prepared at Last
I've covered most of the common VPN configuration and connection problems, and I expect that these tips will help you get your VPN connections up and running. This technology is engaging and popular and will become widely adopted when administrators can take advantage of the standard implementation of tunneling protocols and IP Security (IPSec) in Windows 2000 (Win2K). Remember, start simple and take one step at a time. Then, lean back, put your feet on the desk, and listen to your users rave about this new functionality—it's a great alternative to traffic jams and gridlock.