| You've got your Windows Server 2003 server installed and configured, and it is supporting all your remote users as a remote access server and as a VPN server. The clients are installed, and you are ready for a long vacation. Don't book that flight just yet, though. What are you going to do when something breaks? To further complicate things, you are now dealing with a remote user or location, and potentially Internet connection issues, firewall conflicts, misconfigured workstations, and a number of other issues that you will need to identify and correct. To make matters worse, because your users are now scattered around the country or even around the world, troubleshooting their situations can be a real problemyou can't walk to their desks to see what's going on. And if the CFO is in Europe, you might find yourself troubleshooting issues at some pretty odd hours, due to the time difference. The CFO gets up in the morning and wants to check his email. It's breakfast time, and he's planning on eating and catching up on mail. Of course it's 2:00 a.m. at your house, but you might get a call when the CFO can't connect to the VPN server. To help you work your way through these types of issues, the rest of this chapter discusses troubleshooting remote access problems. Troubleshooting 101 One of the challenges that network and server administrators face is dealing with interruptions in service. This is a particularly large issue for administrators who are responsible for remote access or VPN-related problems. When a server is down, it is relatively easy to start troubleshooting it; it is almost always located in one of the company's offices. But how do you deal with a problem when it's the company CEO sitting in a hotel room in Hong Kong and she needs to get her email now? There are two generally accepted troubleshooting methods used by new administrators during their first encounter with a remote access outage: They either panic or they start trying things until the problem goes away. Neither of these is a recommended strategy for addressing problems in general, and they can be particularly problematic when dealing with remote access issues. Whenever you run into a problem, you need to use a structured approach to troubleshooting. There are several benefits to doing so. First, if you have a plan, you generally won't panic. You know what to do. Second, a consistent approach allows you to correct problems more efficiently than just trying things until the problem is corrected. Finally, if you use a consistent approach and document your results, you will be able correct a problem that recurs by using a known solution. In fact, if your documentation is good, someone else will be able to apply your solution if the problem crops up again. This is very useful if you are on vacation; the last thing you want to be working on during Mardi Gras in New Orleans is the server-down situation at the office, especially if it's the same problem you found and fixed three months ago. Now wouldn't it be nice if this book included the perfect troubleshooting process, so all you would need to do is follow a flowchart, and by the time you got to the end of the chart, the problem would be solved? If it were that easy, companies wouldn't need IT departmentswe would all be replaced by the sales team. This book provides a generic troubleshooting methodology. You are encouraged to use the process described here, change it to fit your needs/troubleshooting style, or even develop your own. The point is not to use one specific method, but to make sure you use a consistent process that works for you in your environment. Here is a generic process that you can use as a basis for a troubleshooting process: Identify the symptoms You can't fix a problem until you are sure what it is. Far too often you will hear things like "The Internet is down" or "Mail is down." What exactly does that mean? "The Internet is down" might mean that people can get to Web sites but not FTP. Or people might be able to get to some Web sites but not others. Or one person may not be able to get to her favorite quilting Web site. Until you have specific symptoms, you cannot correct a problem. Determine the problem scope How big is this problem? Is it 1 user, 100 users, or the entire company? Is it the secretary's cube, the entire floor, or the entire building? Knowing how big the problem is helps you get a handle on the urgency of the issue, and it gives you valuable clues about what the problem might be. If the sixth floor is down, you might look at the network infrastructure that supports that floor. In many cases, "the Internet is down" really means your boss can't get to her stock ticker. Although that may be an important issue, you can probably finish your lunch before you run to the boss's office. Look for changes A remarkably large number of problems in a complex computing environment are related to changes. If a single user is having a problem, did he install a cool new game that he received in an email message from his buddy? If you just lost access to the Internet, did anyone upgrade router code or install a new firewall rule? The toughest part about troubleshooting a change-related problem is identifying what changed. Unfortunately, identifying who made the change can be an even bigger challenge. Try the most likely solution When you have completed your information gathering, try the solution you think is the most likely. Determine whether the problem is fixed You've tried to fix the problem. Did it work? If not, repeat Step 4 with the next most-likely fix. Repeat until the problem is solved. See if you broke anything else This is a critical step because changes to the environment, even if it's change that occurs when you are trying to fix something, can have unpredictable side effects. You need to 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 Sales at lunch broke Accountingyou could be in for a long night. Always test your solutions after you implement them. Document it Documenting your solution is probably the most important part of the troubleshooting process. In six months, when you see the same problem, you don't want to rely on memory to come up with the solution again. Make sure you have something to which to refer.
Diagnosing and Resolving Problems Related to Remote Access VPNs Objective: Troubleshoot user access to remote access services. Remote access VPN problems typically fall into the following categories: Unable to Connect to the VPN Server When troubleshooting the inability of a remote user to connect to the VPN server, you should start at the network layer. Assuming that the remote user is connecting to the VPN server across the Internet (the most common architecture), you can try the following: Determine whether this is a problem with one user or many users. If it's a problem with a single user, the problem is most likely on that person's end. If it's a problem with a single user, proceed through this list. If it's a problem with many users, you should start looking at the server side. Is the server up? Is the Internet connection up? Verify that the remote user has Internet access. You can have the remote user test this by having her connect to an Internet Web site such as www.microsoft.com. If she cannot access a generic Web site, you need to look further into the user's local network connection. If the user can access an Internet Web site, see if she can access the Internet connection that the VPN server is on. The user should try to access a Web site on the same segment (if there is one) or by using IP troubleshooting tools such as ping and tracert. If the user cannot access devices on the VPN server's Internet connection, you should look further into problems on the VPN server Internet connection. If the connectivity is working but the tunnel still won't come up, has the user successfully connected before? If she has, see if anything has changed with the user's connection or her system. Has she upgraded a modem, installed a firewall, or made any changes that could prevent a VPN connection from being established? Is she connecting from her usual Internet connection, or is she traveling? If there have been no changes, check with the user's ISP to ensure that there haven't been any changes on the ISP's network that could affect the VPN connection. If the user has never connected successfully in the past, you should review her local network configuration; a firewall might be preventing the connection from working. When in doubt, you should have the user remove any extraneous network components (firewall, wireless routers, and so on) and connect as directly as possible. You should try to eliminate as many variables as possible. If the user is using NAT on the network connection, make sure that the VPN is using PPTP, or if PPTP is not available, make sure the NAT-compatible VPN client is being used. If Steps 1-5 don't identify the cause of the problem, you might need to have the user use a modem and dial in by using a direct ISP connection. If the VPN server still can't be reached, you might need to reinstall the VPN client or potentially re-image the client to ensure that the configuration is correct.
Unable to Authenticate to the VPN Server If the remote user can contact the VPN server but cannot authenticate, you can try the following: Determine whether this is a single-user problem or whether it affects a larger population of users. If it affects more that one user, check to make sure Windows Server 2003 RRAS is running and that the authentication infrastructure (Active Directory, IAS, or a third-party RADIUS server) is functioning correctly. For a single-user issue, continue with the following steps. If it's a problem with many users, you should start looking at the server side. Ensure that the user account, domain name, and password are correct. Sometimes a client connection problem can be as simple as a stuck Caps Lock key. Ensure that the user account of the VPN client is not locked out, expired, or disabled. Ensure that the user account has permission to connect by using remote access. Verify that there are enough PPTP or L2TP ports enabled. You can enable more ports if needed or check to ensure that the ports are not hung or otherwise unavailable. Ensure that the connection components (client, server, and remote access policy) use at least one common authentication method. Ensure that the client and remote access policy use at least one common encryption method. Ensure that the client and server are using a common tunneling protocol. If you are using an L2TP/IPSec VPN, ensure that the certificate configuration is correct. The client must have a valid machine certificate, and the CA must be available to authenticate the validity of the certificate. When you are using a remote access policy, you can try setting the policy to use no authentication. Just be sure to reenable it when you have completed your troubleshooting.
Exam Alert: Common Encryption Methods One of the most common problems in real-world authentication troubleshooting is not having the client and remote access policy share a common encryption method. Because this is something that administrators see fairly often, you might also see this on the exam.
If you get through this list and are still unable to identify the problem, it is probably time to have the user bring her computer by the office (or mail it in) so that you can take a closer look at the configuration and do some more intensive testing. Diagnosing and Resolving Problems Related to Establishing a Remote Access Connection Objective: Troubleshoot user access to remote access services. There is a lot of overlap in the problems with remote access connections and the problems with remote access VPN connections, due to the fact that they share many of the same components. Remote access connection problems typically fall into the following categories: Unable to Connect to the Remote Access Server When troubleshooting the inability of a remote user to connect to the remote access server, start with the phone lines. Then you can try these steps: Determine whether this is a problem with one user or many users. If it's a problem with a single user, the problem is most likely on that person's end. If it's a problem with a single user, proceed through this list. If it's a problem with many users, you should start looking at the server side. Is the server up? Is the Internet connection up? Verify that the remote user has the correct phone number. This is a quick check and saves you some embarrassment. You don't want to spend a lot of time troubleshooting the problem, only to find out the user had the wrong area code set. Ensure that there is a dial tone. Have the user verify that he gets a dial tone when he tries to connect. You might need to have him turn up the modem volume to verify this. If the user has a dial tone, have him try configuring the modem to dial a phone line, and see if the phone rings successfully. If it does, you know the user's line is working, and you probably need to look elsewhere for the cause of the problem. If the user can get a dial tone and successfully dial a phone number, have him listen to the modem dialing. Does it just ring and ring? Get a busy signal? Does the user get a modem tone, but the modems are unable to negotiate a connection? If the connectivity is working, but the connection still won't come up, has the user successfully connected before? If he has, see if anything has changed with his connection or his system. Has the user upgraded a modem, installed a firewall, or made any changes that could prevent a connection from being established? Is he connecting from his usual phone line, or is he traveling? If he has never connected successfully in the past, you should review the configuration of his remote access client. If Steps 1-5 don't identify the cause of the problem, you might need to reinstall the dial connection or potentially re-image the client to ensure that the configuration is correct.
Unable to Authenticate to the Remote Access Server If the remote user can connect to the modem but cannot authenticate to the remote access server, you can try the following: Determine whether this is a single-user problem or whether it affects a larger population of users. If it affects more that one user, check to make sure Windows Server 2003 RRAS is running and that the authentication infrastructure (Active Directory, IAS, or a third-party RADIUS server) is functioning correctly. For a single-user issue, continue with the following steps. If it's a problem with many users, you should start looking at the server side. Ensure that the user account, domain name, and password are correct. Sometimes a client connection problem can be as simple as a stuck Caps Lock key. Ensure that the user account is not locked out, expired, or disabled. Ensure that the user account has permission to connect by using remote access. Verify that there are enough modem ports. You can add additional modems if needed or check to ensure that the ports are not hung or otherwise unavailable. Ensure that the connection components (client, server, and remote access policy) use at least one common authentication method. Ensure that the client and remote access policy use at least one common encryption strength. Ensure that the policies are ordered as you expect, thus ensuring they are processing and allowing or denying connections as you expect.
If you get through this list and are still unable to identify the problem, it is probably time to have the user bring his computer by the office (or mail it in) so that you can take a closer look at the configuration and do some more intensive testing. Diagnosing and Resolving Problems with User Access to Resources Beyond the Remote Access Server Objective: Troubleshoot user access to remote access services. On some occasions, you might find that a user can connect to the Windows Server 2003 remote access server but is unable to access resources on the internal network. This is generally due to one of the following issues: The protocol the client is using is not enabled for routing. In this case, you should verify the protocol at both ends to ensure that it is configured appropriately. Clients are not allowed to access the entire network. If the server is using static IP routing, the network/resources that the user is trying to connect to are not in the routing table. If the routes are not present, remote access VPN clients cannot access locations on the intranet. The internal network may not have a route back to the remote access server client addresses. In this case, you should verify that the network the user is trying to access has a route back to the client addresses. There might be packet filters that are interfering with the access. You should verify that there are no packet filters on the profile properties of the remote access policy that correspond to the connection the client is using to connect.
You will find that these types of issues generally affect groups of users because the problem is typically on the intranet side of the connection. Looking for changes is especially important when you're troubleshooting these types of issues. |
