Troubleshooting Remote Access Problems

You've got your Windows 2000 RRAS server installed, configured, and supporting all your remote users as a RAS server and as a VPN server. The clients are installed, the phone books are configured, and all is right with the world-until something breaks. And unlike the LAN, when something breaks in a remote access environment, the number of possible problems multiplies exponentially. Is it a client configuration issue, a server problem, a problem with an ISP, or one of a dozen other common remote access problems? To make matters worse, because your users are now scattered around the country or even the world, troubleshooting their situation can be a real problem. You can't simply walk to a user's desk to see what's going on. You have to work with users remotely to determine the issue and resolution. For that reason, we spend the rest of the chapter looking at some of the common issues you could encounter while working with a Windows 2000 RRAS implementation. But before we get to the specifics, let's discuss troubleshooting as a general concept.

When many people start working in the IT industry, they generally use one of two troubleshooting methods when faced with their first major issue. They either panic, or they simply start trying solutions until the problem goes away. Neither of these courses of action is a recommended strategy for addressing issues. Whenever you run into an issue, you need to use a structured approach to troubleshooting. There are several benefits to this approach. First, if you have a plan, you generally won't panic. You'll know what to do. Second, a consistent approach allows you to correct issues more efficiently than merely trying things until the issue is corrected, which could waste a lot of time on blind alleys. Finally, if you use a consistent approach and document your results, you will be able correct an issue that recurs with a known solution. In fact, if your documentation is good, someone else will be able to apply your solution if a problem crops up again. This is very useful if you are on vacation; it's no fun getting paged on the beach in Maui because someone on your team doesn't know how you fixed the problem the last time.

To that end, one generic troubleshooting methodology is the following:

1. Identify the symptoms  You can't fix a problem until you are sure what the problem is. Far too often, you will hear your coworkers make comments such as "The Internet is down" or "Mail is down." What exactly does that mean? "Internet down" might mean that people can get to Web sites but not FTP, or people can get to some Web sites but not others. Until you have specific symptoms, you cannot correct any issue.

2. Determine the problem scope  How big is this problem? Is it one user, 100 users, or the entire company? Is it the secretary's cube, the entire floor, or the entire building? Not only will this information help you get a handle on the urgency of the issue, it also gives you valuable clues as to what the problem might be. If the north side of the floor is down, for example, you might look at the network infrastructure that supports that side of the building. In many cases, "The Internet is down" really means that your boss can't get to www.espn.com to see how his team did in the big game last night. That's still important, but you can probably finish your coffee before you run to his office.

3. Look for changes  A remarkably high number of issues in a complex computing environment are related to changes. If it's a single user, did he or she install a "cool new game" that they received in an e-mail from a buddy? If you just lost access to the Internet, did anyone upgrade router code or install a new rule base on a firewall? Volumes have been written about how to control change in a network environment, but at a minimum you should have a shared calendar on your mail server where groups can post changes. The toughest part about troubleshooting a change-related issue is identifying what changed.

4. Try the most likely solution  Fix it already! Once you have completed your information gathering, try the solution you think is the most likely to work.

5. Is it fixed?  You've tried to fix it; did it work? If not, repeat Step 4 with the next most likely fix. Repeat this process until the problem is solved.

6. Did you break anything else?  This is a critical step; changes to the environment, even if you are trying to fix something, can have unpredictable side effects. Look for them. The last thing you want to find out as you are headed home for the day is that the fix you put in for the sales department at lunch broke accounting's network. You could be in for a long night.

7. Write it down  This is probably the most important part of the equation: Document your solution. In six months when you see the same problem, you don't want to rely on memory to come up with the solution. Make sure you have something in writing to refer to.

This is a very generic troubleshooting methodology that is only intended as a guideline. The real point is to make sure you have a formal, repeatable process that you can follow to resolve any problem you encounter. Use this list or come up with your own from scratch, as long as you have a process.

Now let's look at some common remote access problems you might run into.

Problems with a VPN Due to the Internet Service Provider

ISPs such as America Online (AOL), Microsoft Network (MSN), Earthlink, and the hundreds of other international, national, and local ISPs can present some special challenges to anyone supporting VPN users. Fortunately, identifying issues is a fairly simple process: You just need to start from the client and work your way out.

In the old days, everyone connected to their ISPs through a dial-up modem, so many of the issues were related to modem connections. Although modem connections still make up a significant number of Internet connections, we now also have high-speed broadband such as xDSL and cable modem to contend with. Here we do not cover troubleshooting the ISP connections themselves but rather specific VPN-related ISP issues.

If you are unable to establish a VPN connection across your ISP connection, ask yourself the following questions:

1. Do you have a connection to the Internet?  You can check this by attempting to access a Web site. If you can access a generic Internet Web site such as www.microsoft.com, try accessing a Web site from your corporate Internet connection, if it's available. This will allow you to not only test Internet connectivity but also connectivity from the remote network to the corporate network. If you are unable to access the Internet, you need to check with your ISP's technical support people. If you can access the Internet but not your corporate network, check with your own technical support staff and verify that there are no connectivity issues at the other end of the connection.

2. If you have Internet access, have you successfully connected before?  If you have connected, think about what could have changed on your connection. Have you upgraded your modem, installed a firewall, or made any changes that could prevent a VPN connection from being established? If there have been no changes on your end or if this is the first time you have tried to connect, check with your ISP to ensure that its network supports the VPN protocol you are attempting to use. We discuss NAT issues later in this section, but that is a potential problem.

3. Anything else?  Other ISP-related issues can be firewall configurations, the use of transparent proxy servers, or, in some isolated networks, the lack of router support for either PPTP or L2TP/IPSec. This last issue is very rare these days, but it was common when these protocols were introduced.

These are the main areas you need to be concerned with when you're dealing with ISP-related issues. When in doubt, try to simplify the local network as much as possible, to immediately eliminate that as a source of trouble. If you have an extensive home network, with wireless and a firewall, try connecting your computer directly to the ISP network connection, and verify that you don't have local configuration issues before you involve technical support in resolving your issues.

Client Computer Operating System Issues

Once you have ruled out the ISP as a source of trouble, you need to check the configuration of the client computer. Again, following our methodology, once you have established that this is an issue with just your system, look to see what changed. Some common places to check for potential changes that could impact your connection are these:

• Verify that your user account and password are correct. Sometimes a client connection issue can be a stuck Caps Lock key.

• Installation of new applications such as a personal firewall or a security update can potentially impact the stability of your client environment. If you have made such a change, try removing the new software or update, and see if it corrects your issue.

• When in doubt, delete your VPN connection and reinstall it.

If none of these steps corrects your issue, you should engage your technical support team to verify that your client configuration matches the configuration of the VPN server at the other end.

Network Address Translation Devices

Before we discuss the issues associated with NAT, we need to talk about what exactly NAT is. As you are undoubtedly aware, the Internet relies on the TCP/IP protocol for communications. In order for two systems to communicate using TCP/IP, each system must have a unique IP address; without a unique address, the network cannot deliver the packet to your system. This concept is fairly straightforward until we discuss the size of the Internet.

In the early days of the Internet, when IP addressing was being developed, the 32-bit addressing scheme (known as IPv4) was considered more than adequate for any potential network growth. Theoretically, 4,294,967,296 unique addresses were available using 32-bit addresses; even discounting the reserved ranges, there were still over 3 billion possible addresses. At the time, that was enough addresses to provide an address for every person on the planet, including children.

Unfortunately, the designers of the addressing scheme dramatically underestimated the explosive growth of the Internet as well as the popularity of TCP/IP in business and home networks. There are no longer enough addresses to go around. As a result, a new addressing scheme is under development. IPv6 is an addressing scheme that allows for a dramatically larger pool of addresses but is enjoying very limited deployment on the Internet today. This is in large part due to the use of NAT. (For more information on NAT, see RFC 3022, Traditional IP Network Address Translator (Traditional NAT), January 2001.)

NAT is an Internet standard that allows you to use one set of IP addresses on your internal LAN and a second set of IP addresses for the Internet connection. A device (usually a router or firewall) between the two connections provides NAT services, managing the translation of internal addresses to external addresses. This allows companies to use large numbers of unregistered internal addresses while only needing a fraction of that number of addresses on the Internet, thus conserving the addresses.

There are two main types of NAT:

• Static NAT  This version of NAT maps an unregistered IP address on the private network to a registered IP address on the public network on a one-to-one basis. This type is typically used when the translated device needs to be accessible from the public network. For example, a Web server on your private network might have an unregistered address of 10.10.10.10 but a NAT address of 12.2.2.123. A user trying to connect to that Web site can enter 12.2.2.123, and the router or firewall at the other end will translate that address to 10.10.10.10 when the packet reaches it.

• Dynamic NAT  This version of NAT maps an unregistered IP address to a registered IP address from a group of registered IP addresses. This version is more commonly used when large pools of systems on the internal network need to access the Internet and don't have a requirement for a static address. The workstation's address is translated to the next available registered address as soon as it initiates a connection to the public network.

This high-level overview of NAT is useful, but the critical thing to remember about NAT is that due to limitations in the first version of the IPSec standard, IPSec cannot traverse a translated network. IPSec requires that both the VPN client and the VPN server have static, untranslated addresses on the public network in order to connect. What this means from a practical perspective is that if you are trying to connect and NAT is anywhere in the network architecture, you cannot use an L2TP/IPSec VPN. (Note: This situation is expected to change with the release of .NET Server 2003, but the released version of the Microsoft L2TP/IPSec client/server VPN will not work.) The PPTP protocol does not suffer from this limitation. So, if you are using NAT, plan to use PPTP for the near future, until the IPSec standard matures.

Damage & Defense…
NAT and the End User's Home Network

It is very easy to say "IPSec doesn't support NAT; use PPTP instead," but how does this impact you in the real world? In most environments, NAT-related issues arise from end users' home network connections. As a general rule, companies that provide ISP access for their employees still provide dial-up Internet access. Not only is it cost-effective compared with high-speed access, it can be used not only from home offices but also while traveling. This makes it a great solution for mobile users, and because almost all major ISPs provide Internet-routable (not translated) addresses for their dial-up users, NAT-related issues are almost nonexistent.

Not so with high-speed home networks. Most broadband providers rely on NAT to ensure that they have enough IP addresses to support all their users. To make matters worse, even if you do find a provider that is using Internet-routable addresses, now you run into the users who want to hook up their kid's PC while connecting their own home PC and company laptop to the Internet over the same connection. They run out to buy a low-cost router and start doing their own NAT.

The net result of these complications is that unless you are able to mandate the use of a dial ISP with Internet-routable addresses, you need to rely on PPTP for all your VPN connections. L2TP/IPSec will not work for the majority of your high-speed users.

Routing and Remote Access Server Issues

We've looked at ISP issues, NAT issues, and client issues. Let's take a look at some of the possible problems with the server. When you have a server issue, it will generally affect a specific population of users. These issues break down into three main types:

• Single-user issues  Some common server-related issues that can cause a server to not allow a single user to connect include:

  • Not having enough PPTP or L2TP ports enabled. You can enable more ports if needed or check to verify that the ports are not locked up or otherwise not available.

  • Not having the correct combination of user permissions and remote access policies enabled to permit the user to connect. You need to correctly configure the user's permissions to correct this issue.

  • The user's account is completely disabled. To fix this issue, you should enable the user's account.

  • User's client and server are not configured to utilize the same authentication or VPN protocol. To correct this issue, you generally need to reconfigure the client's authentication. You should never reconfigure the server to address a single-user issue, unless you are sure the change won't have any side effects that might impact other users.

  • If the user credentials (user ID, password, and domain) are correct, you might have a DHCP issue. Check to make sure that you haven't run out of addresses. If you have, you need to allocate additional addresses.

• Group-related issues  Although these issues are similar to the issues seen with a single user, having a group of users (not all users, which we discuss in the next section) can make troubleshooting the issue a little easier. Some common things you can do to help narrow down the source of the problem include:

  • Check for common factors. If the users are all in the same Active Directory container or group, a permissions or remote access policy conflict could be preventing the users from connecting.

  • If the users are all configured to use PPTP and they don't work, but the L2TP/IPSec does (or vice-versa), check the appropriate group of ports and any associated authentication or encryption setting used by those ports. In the event of the issue being with L2TP/IPSec only, you might have an issue with the machine certificate used by that system.

• Serverwide issues  On a particularly bad day you will run into an issue in which the entire system is unavailable for remote users. If this is the issue, check the following:

  • Is the Routing and Remote Access service started on the VPN server? If it's not, try to start it.

  • Are your PPTP and/or L2TP/IPSec ports enabled for inbound requests? If they're not, enable them.

  • Are the correct authentication protocols still enabled?

  • Is the user domain available? You might have an issue with your Active Directory or Windows NT domain. If you have configured RADIUS authentication, your issue could also lie with the RADIUS server connection.

  • You could have a routing issue. The routing table on the server could be corrupted or you could not have the correct routes on your network for the DHCP addresses configured on your server. If this is the case, users will connect but will be unable to access any resources. You can correct this situation by updating the routes on your network or by changing the DHCP addresses to addresses that are already routable on the network. Avoid having your remote access server participate in any dynamic routing; the security issues associated with that kind of dynamic network access are numerous.

  • Another issue that could prevent users either from connecting or from reaching a remote network are the IP filters. If your IP filters are configured improperly, they can be dropping tunnel traffic. An easy test for this issue is to document your filters and then delete them, to see if the issue is resolved.

These are just a sample of the issues you can run into while working in a remote access/VPN environment. Due to the dispersed nature of the user population, diverse (in most environments) system operating systems and configurations, and the intricacies of the Internet's addressing and routing architecture, troubleshooting issues with this infrastructure represent a major test of your troubleshooting skills.

Firewall Issues

Finally, you will also encounter firewall issues when you work with VPNs. These issues break down into two main categories: VPN server-side issues and VPN client-side issues.

Server-side issues are typically the more difficult to work on, since you cannot disable the firewall to see if the issue goes away. So, on the server side you have to deal with any firewall issues between your production network and the VPN client, without the luxury of trying to connect without the firewall to rule out other issues. Some companies put their VPN servers directly on the Internet, but doing so can be a security problem, and you are almost always better off placing them behind a firewall. This situation raises two issues. First, is the firewall also doing any NAT? If it is, you will only be able to use PPTP for VPN connections, or you will have to rearchitect the connection to the Internet. Next, are the correct ports open to allow the clients to connect to the firewall? PPTP uses the GRE protocol or protocol 47 to make the connection, whereas L2TP/IPSec needs protocol 50 (for ESP), 51 (for AH), plus UDP port 500 for the Internet Key Exchange (IKE).

On the client side, you have essentially the same potential issues, but you should always remove the firewall from the equation when you're troubleshooting. Connecting the client directly to the Internet and trying to connect quickly confirms or rules out a client-side firewall issue.

Once you have confirmed it is a firewall issue (by being able to connect from the direct connection), you need to reexamine your network for the use of NAT on the firewall and verify that the appropriate ports are opened.