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.
- Configuring domain and server accounts. You can configure your RAS server as a domain controller or a standalone system. If you configure the server as a domain controller, make sure the user's domain account has dial-in permission. If the server isn't a domain controller, RAS by default authenticates client credentials against the local SAM. A user can authenticate to a standalone server in two ways: with a local account on the RAS server or with a Registry edit that forces the server to authenticate credentials against the domain SAM. In all cases, the account you supply must have permission to dial in.
- Configuring computer accounts. If the client is an NT workstation or server, the computer must have an account in the domain. If the client is a new system, create the new computer account in Server Manager before you test the connection. If the client system already has an account on the network but has been disconnected for a week or more, the computer account password might not be synchronized with the server. Every computer account has a hidden password that the PDC resets automatically; if a system is offline for a long time, the account password can be different on the PDC and the client. Ordinarily, you can delete and re-add the account to correct this problem.
- Negotiating client authentication. A RAS server can use three different authentication protocols to authenticate PPTP users. In increasing order of security, these protocols are Password Authentication Protocol (PAP), which is clear text; Challenge Handshake Authentication Protocol (CHAP), which is encrypted and hashed; and Microsoft Challenge Handshake Authentication Protocol (MSCHAP), which is encrypted and double-hashed with a checksum. The authentication protocols that the client and server negotiate for logon depend on the encryption settings you select when you configure the server's incoming VPN ports and the client PPTP connection network settings. The following options are available on the server and the client:
- Allow any authentication, including clear text. The server will authenticate clients with the protocol that the client requests (e.g., PAP, CHAP, MSCHAP).
- Require encrypted authentication. The server will authenticate with MSCHAP, Data Encryption Standard (DES), or Shiva PAP (SPAP).
- Require Microsoft encrypted authentication. The server will authenticate only with MSCHAP.
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.
- Check browsing. When you browse the network or even a specific server, you commonly receive the message System error 53 has occurred. The network path was not found. An inability to browse usually means the client can't resolve NetBIOS names. Make sure the client has a WINS server assigned, either statically (in the PPTP connection's Network Settings) or dynamically (use Ipconfig for all clients or Winipcfg for Win9x clients). If the client has no WINS server address, enter the address manually, reconnect, and try browsing again.
- Set up the default gateway. Look at the default gateway setting for the PPTP connection, or print out the route table (use the Route Print command). If the gateway still points to the ISP, every client request to browse the LAN goes to the ISP rather than to the VPN connection, and the ISP might block ports required for NetBIOS name broadcasts. Remember, routers and firewalls can prevent the transmission of NetBIOS names unless you enable unicast traffic on UDP ports 137 and 138 and TCP port 139. NetBIOS names are proprietary to Microsoft, and some ISPs might not let this data flow through their infrastructure.
You can manually delete the route in the route table and add a static route to the VPN server's virtual interface. The server's virtual interface is the address assigned to the VPN interface. This address is either the first address in the static address pool or the first available DHCP address in your RAS server configuration.
- Enable NetBEUI. If you aren't a TCP/IP purist, you can install NetBEUI on the RAS server and remote clients to solve client-browsing problems. Enable NetBEUI for incoming connections on the server's VPN ports, and select NetBEUI in the PPTP connection on the client. Doing so connects the client to the server with NetBEUI over TCP/IP. Try as you might, you can't escape the inherent limitations of the NetBIOS-based NT namespace. This NetBEUI option is probably the easiest way to obtain a fully browsable LAN.
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.
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.