Windows 2000 Server has been on the market for more than two years, and its successor, Windows .NET, is just around the corner. But many enterprises have consolidated around Windows NT Server 4 as a back-end infrastructure. That includes using NT as a first-generation, PPTP-based VPN server, even though VPN was a very new technology back when NT was released in the mid-1990s.
Of course, supporting an NT VPN server requires the administrator to be diligent in monitoring and optimizing the VPN and to be able to troubleshoot issues that appear in the day-to-day administration of an NT VPN server.
In supporting VPN clients, I have found most issues to be related to the client-side configuration, but some important server-side issues must be considered as well. In terms of VPN troubleshooting, we're going to take a look at rights issues, connection types, networking setup, and client configurations.
The rights needed to access an NT VPN server are assigned by the Grant Dialin Permission To User option in each user account. This option simply states whether this NT account can access the Remote Access Service (RAS). This option is assigned in each user account from within the User Manager For Domains administrative tool, as shown in Figure A.
|Enable Dialin Permission for users who will make VPN connections.|
If a user does not have this option enabled on the account, the connection will not be established and the user will be told that dial-in permission does not exist for the selected account. This will also generate an Event 20082 of source Remote Access in the Event Log of the Remote Access/VPN server.
Microsoft provides a nice list of all RAS-related error codes and a description for each in Knowledge Base article Q117304.
Windows NT, unfortunately, does not allow the dial-in right to be assigned to a local or global group. You can bypass this limitation somewhat by using the Remote Access Admin administrative tool. The Remote Access Admin will allow you to assign the dial-in right to all users, as shown in Figure B.
|Use the Grant All button to enable RAS/VPN permissions for all users.|
If you take this approach, you'll need to watch the situation carefully. This option does not allow you to select a number of users and assign the right—it assigns all listed users the right to dial in. It also lets you revoke all users. Using the Remote Access Admin console to give all users dial-in rights is most useful if you are using your Windows NT VPN server exclusively for remote dial-in (including VPN), where the only accounts on that computer are the dial-in accounts (not the domain accounts).
Supporting VPN clients entails an assortment of responsibilities, and depending on your situation, you may have a mix of how users connect to your VPN server. If you are supporting telecommuters, users needing occasional remote access, and/or site-to-site VPNs, you will be dealing with different connection types.
While it is likely that the VPN server will not be changing ISPs frequently, I have learned to have the clients connect to the VPN's fully qualified domain name instead of an IP address. That way, if you do change ISPs, you don't have to reconfigure all of your client configurations. For example, have the client connect to "vpn.company.com" and make sure that your DNS records are modified accordingly during your ISP change, which will make an ISP change easier for everyone involved.
Users tend to change ISP connections frequently. Various dial-up, broadband, satellite, wireless, and other connections may cause you headaches in trying to support VPN users. Make an effort to be aware of how your VPN clients are connecting to the Internet (and then to your VPN server). Also, try to provide or recommend the best solutions based on your experience.
The networking of a VPN can be a frequent trouble spot. Topics like RAS setup, ISP networking issues, name resolution means, and gateways can affect the reliability of your VPN solution.
On the server, be sure that you have enough VPN connections enabled for the number of potential VPN users that will be connecting. This setting is configured in the properties of the Point-To-Point Tunneling Protocol within the Network applet of the control panel on the VPN server, as shown in Figure C.
|Set the allowed number of incoming VPN connections.|
Another concern related to connection types and networking setup comes up when users try to use a nonstandard ISP to connect their VPN. A nonstandard ISP is one that adds items into the Network applet of the control panel. I have had many issues with ISPs that add protocols or adapters into the client networking setup. When supporting users, you should provide or recommend a good ISP for dial-up access in order to save yourself a lot of headaches down the road. If you have a user who is having trouble accessing the VPN, ask whether any software was installed that may have affected the network stacks, such as special client software from the ISP.
For the VPN client, an important consideration is whether the VPN connection will authenticate the client to be part of the Windows domain or authenticate it on the VPN server and simply give it a connection to the internal network. This setting is configured on the VPN client, and it varies slightly with different versions of Windows. Generally, you can configure this setting by selecting (or not selecting) the Include Windows Logon Domain in the Properties dialog box for the VPN connection in the Network/Dial-up Connections applet. Figure D shows an example of what this looks like using Windows XP as the client operating system. (Windows 2000 looks almost identical to this.)
|Select whether you want the connecting client to be part of the Windows domain.|
Another important aspect of the VPN client setup is the default gateway. If the client VPN connection is set up to use the default gateway on the remote network, all Internet traffic will be routed through the VPN connection. For example, if someone makes a VPN connection from a home machine, any time that person tries to access an Internet site, the request will be sent over the VPN tunnel to the company network and out the Internet. The downloaded page will then be sent back down the VPN tunnel to the client. Obviously, most of the time you're not going to want this to happen.
But if you do want to enable this setting—for example, for tracking all Internet traffic from a company laptop—on a Win2K client, go to the Properties of the VPN connection and select the Networking tab. Then, select TCP/IP, click Properties, click Advanced, and select the Use Default Gateway On Remote Network check box, as shown in Figure E.
|Setting up the client to use the gateway of the remote network|
Name resolution is also an important part of supporting a VPN client. The easy option is to have RAS use DHCP assignments for VPN connections. This option will usually give the clients the same network resolution services that DHCP connections on the internal network are entitled to use and will greatly simplify the work of an admin.
Client VPN problems can be tough to diagnose. I have found client troubleshooting issues generally not to be related to VPN/PPTP but to changes on the end user's PC. This can include problems with:
- Virtual hardware devices (modems in particular) not operating correctly.
- Bogus DHCP leases/assignments requiring a manual release/renew.
- Installed software that has modified the networking stack of Windows.
- Accidentally changing a setting on the VPN connection itself.
While diagnosing these problems is challenging, getting the VPN to work again is usually fairly easy. One trick I've relied on is creating two identical PPTP connections on the client computer. I put one on the desktop as a shortcut and keep one untouched. Since the end user does not utilize it, I can use it as a support tool. This setup allows you to tell if the settings of a PPTP connection are inhibiting the user from authenticating and/or connecting correctly.
Monitoring the VPN connections is important to ensure that they are working correctly and are not being abused. Here are some ways you can monitor your VPN server:
- Use Remote Access Admin—This configuration applet shows you current connections, lets you see how long the active connections have been online, and provides statistics on the number of bytes transferred.
- Use WINS/DHCP Admin—This tool lets you determine whether you have a DHCP lease reserved for a VPN client.
- Reevaluate VPN strategy—If the VPN solution is a trusted VPN (all TCP ports open) to all clients, consider adding TCP/IP security (Advanced Properties of TCP/IP from the Network applet of the control panel) for the explicit ports needed to the VPN server’s internal interface.
Microsoft provides detailed information about client and server PPTP connections on Windows NT Server 4. You can download these documents from the Microsoft Web site.
The Windows NT 4 VPN server is still in use in many organizations, and keeping the connections working correctly will ease your administration worries. The tips provided here should be a valuable companion for troubleshooting and monitoring your NT 4 VPN servers and their connecting clients.
Rick Vanover is a software strategy specialist for Veeam Software, based in Columbus, Ohio. Rick has years of IT experience and focuses on virtualization, Windows-based server administration, and system hardware.