Managing remote access servers can be among the most high-maintenance activities that any administrator has to juggle. Simply put, tons of things can go wrong that prevent a user from connecting, stop a user from accessing network resources, or slow down the user’s connection.

However, many of these problems are beyond the administrator’s immediate control, such as client configuration difficulties, hardware problems at the remote user’s end, issues with the user’s ISP (if connecting over a VPN), and Internet bandwidth problems.

In my experience, once a RAS server is up and running, subsequent reported problems tend to be user-related issues rather than server problems. Nevertheless, you can bet users will contact you and complain about problems with the RAS server(s). And when they do, you usually have to confirm that everything is working as expected on the server side before they will doubt their end of the connection.

I’ve had many frantic calls from remote users complaining that the RAS server is down and must be fixed immediately because it is imperative for them to do their work, and only after I’ve proved that the problem is not with the RAS server have they looked a little closer to home and found the problem.

So what can you do to streamline the troubleshooting process? I’ve put together some tips that can help with this time-consuming exercise.

Gather timely information
When a user complains that the RAS server is down, the most obvious thing to check is that the server is running and that the RAS service is started. Most admins check this by pinging the server and then connecting to the server to verify that the RAS service is up.

Of course, you can do this from your workstation rather than physically on the server itself. But a quicker and more elegant solution is to run the RAS Server Monitor (Rassrvmon.exe) from the Windows 2000 Resource Kit, which, unfortunately, only works with Windows 2000 RAS servers and not with NT4 RAS servers.

You can have the utility running permanently on your workstation so that you can quickly check the server’s status with the utility’s GUI, or you can run it on another computer and leave it to collect the monitored information to file. You can then check the information ad hoc. If you have multiple RAS servers, you should have multiple instances of the RAS Server Monitor—one for each server.

This utility produces three files, which all have the base name of the server (name or address) that you provide when you load the utility, with the extensions .webstatus, .userlist, and .userdetails. The .webstatus file is designed to be posted on a Web server, so you can publish the current status of your RAS server on your company intranet. This includes information such as the number of currently connected users, total calls, total bytes transferred, and the total and peak number of connections. The .userlist and .userdetails files provide more details on each connection made and include information such as user name and workstation name, the IP address allocated and type of port used, the number of bytes transferred, the first and last connection, the connection duration, and the line speed.

As a background task, you can also configure the RAS Server Monitor to alert you if it detects problems, so that you will know about them before a user contacts you. The first alerting service monitors whether the RAS service is up by sending the MprAdminPortEnum API to the server you specify. A failure to respond means the service or server is down. You configure the alert (for example, send an e-mail message or log an error) by running a program of your choice when the number of failed responses continues over a period of time. By default, this time period is 10 minutes.

The second alerting service monitors for inactive RAS connections over a specified time period. Obviously, there may be legitimate reasons for this inactivity (for example, overnight hours and quiet periods during popular vacation times), but on RAS servers that are usually busy during the day, it could indicate that there’s a problem with the line(s), which would not be detected by the service API monitor.

Does the user have dial-in permission?
If you’re running RAS servers in a native-mode Active Directory domain, you can use the new permission Control Access Through Remote Access Policy on all user accounts so that dial-in permissions are always kept centrally on your RAS servers as part of your Remote Access Policies. However, if you are still using NT4 RAS servers, or your Active Directory is not in native mode, you will need to grant the dial-in permission on each user account.

It can be quite tedious and time-consuming to individually check this on multiple accounts. One way to ease the burden a bit is to make it a regular administrative task to use the Resource Kit tool RASUsers to output a list of all users on a server or domain that have been granted this right. You can then import this information into a database or spreadsheet, making it very quick to search and confirm whether a user account has been granted that right.

Are Remote Access Policies preventing users from connecting?
Windows 2000 Remote Access Policies are great for granular control of user permissions and connections. However, they can also be a pain to support, and they can get so complex that it’s difficult to figure out which policy is being used, and thus, which condition is responsible for a failed connection.

My first tip here would be to make sure that you know how the administration modes work for Remote Access Policies, use the simplest policies you can, bear in mind the order of processing, and document your choices (perhaps with a flowchart to show their decision criteria for allowing connections).

My second tip—particularly when using multiple RAS servers—is to centralize authentication with Windows 2000’s Internet Authentication Service (IAS), even if you have to load it on the same machine as Win2K RRAS. This is because IAS will record which Remote Access Policy is being used with each connection in the Event Log, which makes it much easier to troubleshoot policy problems.

Is your firewall preventing VPN users from connecting?
If you have VPN connections using PPTP, you will need to allow TCP port 1723 and IP protocol port 47 to pass through your firewall. If you are using L2TP/IPSec, you will need UDP port 500 and IP protocol port 50 to pass through the firewall. If you are using AH as well as ESP in your IPSec policies, you will also need IP protocol port 51 to pass.

You can use the Windows 2000 Resource Kit utility PPTP Ping to confirm that this protocol is working between client and server. Simply install pptpsrv.exe on the RAS server and install pptpclnt.exe on the client. Issue the command pptpclnt <ip address of VPN server> on the client. If the protocol reaches the server, the server will display a successful message. If port 1723 is blocked or if port 1723 is open but protocol 47 is blocked (the most common configuration mistake with firewalls), this will be reported as an error since there will be no connectivity taking place.

In the early stages, when you are testing your VPN server, the simplest way to check the viability of the VPN server itself is to eliminate the firewall by setting up a client VPN connection over Ethernet rather than over the Internet. If this doesn’t work when there is no firewall between the server and the client, you can’t blame the firewall for the connection problem.

Are certificates preventing L2TP/IPSec users from connecting?
When it comes to troubleshooting L2TP/IPSec connections, I would put problems with certificates at the top of the list of potential problems. Verify that both client and server have a Certificate Authority (CA) in common and that both have been issued with a valid computer certificate from this CA. If the certificates have been issued outside Active Directory, it’s particularly important to ensure that the certification path has been installed and the system date/time is correct on both computers.

Are there performance problems?
There are a hundred and one reasons for connections not going as quickly as users would like, but one of my tips is to give remote clients LMHOSTS and/or HOSTS files that contain the domain name and the main servers, such as domain controllers, WINS servers, and any servers the user needs for network resources. This should reduce any problems that might be caused by name resolution issues.

If you think poor performance could be due to overstressing your RAS server, use the Performance Monitor counters to keep an eye on memory and processor metrics. PPTP will incur more processing than PPP (because of the encryption), and L2TP/IPSec will be higher still (because of the IPSec processing).

If you suspect the additional stress of running L2TP/IPSec is responsible for poor performance, look to see whether you are using 3DES encryption on most connections (the default for 128-bit versions). If so, consider disabling the default L2TP/IPSec policy and configuring your own policy that uses DES rather than 3DES. You could also invest in a network card that offloads some of the IPSec processing.

The RAS Server Monitor also provides statistical information you might find useful here, such as peak connection time, total connect time, and total bytes transferred. You can use its sister utility, Reportgen, to provide reports from the information produced by Rassrvmon, which can help provide trend analysis to help you determine whether reports of poor performance are linked to high usage.

Prevent user misconfiguration problems
If possible, discourage or prevent most users from changing their RAS settings if their configuration is working. (Windows 2000 Local Group Policies are fantastic for enforcing this.) However, when a user has to configure a connection from scratch, this is another matter. You may find that deploying preconfigured connections with a dialer program is a worthwhile investment of time.

Windows 2000 Server now ships with Connection Manager Administration Kit (CMAK), which allows you to preconfigure remote access connections for your users and customize the configuration with your own company logos, etc. You can include a static address book for your RAS server details or, if you think your RAS server details may change, you can supply the phone book as an automatic download that will update clients with any changes. You’ll find details for using CMAK here.

Many network admins prefer VPN connections over dial-up modems these days because they have many cost advantages and it’s easier to run multiple simultaneous connections, which eliminate the need for modem banks.

However, consider keeping some PPP ports in case users have problems connecting over the VPN—for example, if their ISP is having problems. Because these dial-up connections use Point-to-Point rather than the Internet, they also offer a more secure medium, which means that you may consider configuring them with lower security options, such as CHAP authentication for non-Windows clients and no encryption for better throughput. If you are using Windows 2000 Remote Access Policies, you can easily configure the security settings for these different connections based on the port type being used.

Summing up
Running a trouble-free RAS service isn’t easy, but I hope these tips and tools will help you streamline troubleshooting this important service. The tips have included gathering timely information on your RAS servers’ status, verifying dial-in permission and Remote Access Policies, firewall configuration, certificate verification, performance improvements, preconfiguring connection details for users, and having some contingency plans to call upon.

Do you have tips for working with RAS and VPN servers?

We look forward to getting your input and hearing about your experiences regarding this topic. Join the discussion below or send the editor an e-mail.