Contoso, LTD. used VPN technologies included with Windows Server 2003 and Windows XP to leverage the connectivity of the Internet to connect remote users, branch offices, and business
There is no getting around it—with a technology as complex as a virtual private network (VPN) incorporating so many services and functions in one solution, you might need to do some troubleshooting to get it running. As described in Chapter 5, “Remote Access VPN Components and Design Points,” many separate components are involved in the creation of a remote access VPN connection, all of which must be correctly configured for connections to be successful. This chapter describes the set of troubleshooting tools provided with Microsoft Windows that you can use to gather information about connections, and then describes what to look for to correct the most common problems with remote access VPN connections. Because several
“Divide and conquer.”
Isolate the services that are working properly so that you can drill down from there to the problem areas. Make sure to
“This troubleshooting stuff really works!” Don’t get discouraged because of the complexity. If you take your time and work methodically, you will be very pleased with the results.
The Microsoft Windows Server 2003 family provides the following tools to troubleshoot VPN connections:
Transmission Control Protocol/Internet Protocol (TCP/IP) troubleshooting tools
Authentication and accounting logging
Event logging
Internet Authentication Services (IAS) event logging
Point-to-Point Protocol (PPP) logging
Tracing
Oakley logging
Network Monitor
Each tool handles a specific area of testing and logging. The list looks daunting at first, but if you maintain good notes and
The TCP/IP troubleshooting tools are used to test connectivity to remote servers,
A VPN server running Windows Server 2003 supports the logging of authentication and accounting information for remote access VPN connections in local logging files when Windows authentication or Windows accounting is enabled. This logging is separate from the events recorded in the system event log. You can use the information that is logged to track remote access usage and authentication attempts. Authentication and accounting logging is
Enable authentication and accounting logging from the Settings tab on the properties of the Local File object in the Remote Access Logging folder in either the Routing And Remote Access snap-in (if the Routing And Remote Access service is configured for Windows authentication and accounting) or the Internet Authentication Service snap-in (if the Routing And Remote Access service is configured for Remote Authentication Dial-In
The authentication and accounting information is stored in a configurable log file or files stored in the SystemRoot \System32\LogFiles folder. The log files are saved in IAS or database-compatible format. Saving a log file in a database-compatible format allows any database Open Database Connectivity (ODBC) program to read the log file directly for analysis.
If the VPN server is configured for RADIUS authentication and accounting and the RADIUS server is a computer running Windows Server 2003 and IAS, the authentication and accounting logs are stored in the SystemRoot \System32\LogFiles folder on the IAS server computer. Alternatively, IAS for Windows Server 2003 can also send authentication and accounting information to a structured query language (SQL) server database.
On the Logging tab in the properties of a VPN server in the Routing And Remote Access snap-in, there are four levels of logging. Select Log All Events, and then try the connection again. After the connection fails, check the system event log for events logged during the connection process for an
If your VPN servers are configured for RADIUS authentication and your RADIUS servers are computers running Windows Server 2003 and IAS, check the system event log for IAS events for rejected or accepted connection attempts. IAS system event log entries contain a lot of information about the connection attempt, including the name of the remote access policy that accepted or rejected the connection attempt. IAS event logging for rejected or accepted connection attempts is enabled by default and configured from the General tab from the properties of an IAS server in the Internet Authentication Service snap-in. This log is separate from the authentication and authorization logging mentioned previously—it pertains only to the operations of the IAS service itself, so make sure you are looking at the right logs for the right information!
All Microsoft VPN protocols are based on PPP negotiations, so there is a definite need to understand the PPP process and know how to troubleshoot it. We provide a complete sample of a PPP negotiation log on the companion CD so that you can compare your own logs to it. PPP logging records the series of programming functions and PPP control messages during a PPP connection, and it’s a
By default, the PPP log is stored as the Ppp.log file in the SystemRoot \Tracing folder.
The Windows Server 2003 Routing And Remote Access service has an
You can use the netsh command to enable and disable tracing for specific components or for all components. To enable and disable tracing for a specific component, use the following syntax:
netsh ras set tracing Component enableddisabled
Component
is a component in the list of Routing And Remote Access service components found in the Windows Server 2003 registry under HKEY_LOCAL_MACHINE
\\SOFTWARE\Microsoft\Tracing. For example, to enable tracing for the RASAUTH component, use the command
netsh ras set tracing rasauth enabled
.
To enable tracing for all components, use the command
netsh ras set tracing * enabled
. This should be your preferred method for troubleshooting rather than trying to enable individual component tracing. Using this method also allows you to disable
all
tracing once troubleshooting is complete by using the command’s
disabled
parameter. If you want to disable each trace log individually, you will need to keep track of each component you have enabled. Each trace being performed can dramatically reduce VPN resources and processing speed; remember to use the
netsh ras set tracing * disabled
command after every troubleshooting session to ensure that you have turned all tracing off, and then delete the trace files you do not need to keep. This is also a good security procedure to
Alternatively, you can configure the tracing function by changing settings in the Windows Server 2003 registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
\Tracing.
You can enable tracing for each Routing And Remote Access service component by setting the registry values described later. You can enable and disable tracing for components while the Routing And Remote Access service is running. Each component is capable of tracing and appears as a
To enable tracing for each component, you can configure the following registry value entries for each component key:
EnableFileTracing. You can enable logging tracing information to a file by setting EnableFileTracing to 1. The default value is 0.
FileDirectory. You can change the default location of the tracing files by setting FileDirectory to the path you want. The file name for the log file is the name of the component for which tracing is enabled. By default, log files are placed in the SystemRoot \Tracing folder.
FileTracingMask. FileTracingMask determines how much tracing information is logged to the file. The default value is 0xFFFF0000.
MaxFileSize.
You can change the
| Note |
Tracing consumes system resources and should be used sparingly to help identify network problems. After the trace is captured or the problem is identified, you should immediately disable tracing. Do not leave tracing enabled on multiprocessor computers.
Tracing information can be complex and very detailed. Most of the time this information is useful only to Microsoft support professionals or to network administrators who are very
|
You can use the Oakley log to view details about the IPSec security association (SA) establishment process. The Oakley log can be enabled in the registry or by selecting the Log Additional Routing And Remote Access Information option on the Logging tab in properties of a VPN server; Oakley Logging is not enabled by default. To use the registry to enable the Oakley log, set the HKEY_LOCAL_MACHINE\\SYSTEM\CurrentControlSet\Services\PolicyAgent\Oakley\EnableLogging registry setting to a of 1 (REG_DWORD). The EnableLogging key does not exist by default and must be created.
After it is enabled, the Oakley log, which is stored in the SystemRoot \Debug folder, records all IPSec SA negotiations. A new Oakley.log file is created each time the IPSec Policy Agent is started, and the previous version of the Oakley.log file is saved as Oakley.log.sav. You should be sure, then, to disable Oakley logging once you have completed your analysis; otherwise, you will be taking up valuable system resources. A sample Oakley log can be found on the companion CD-ROM, which you can use to compare to your own.
To activate the new EnableLogging registry setting after modifying its value, stop and start the IPSec Policy Agent and
Stop the Routing And Remote Access service using the net stop remoteaccess command.
Stop the IPSec services using the net stop policyagent command.
Start the IPSec services using the net start policyagent command.
Start the Routing And Remote Access service using the net start remoteaccess command.
Use Network Monitor, a packet capture and analysis tool supplied with Windows Server 2003, to capture and view the traffic sent between a VPN server and VPN client during the VPN connection process and during data transfer. You cannot interpret the encrypted portions of VPN traffic with Network Monitor, but for the purposes of troubleshooting VPN connection negotiation and operations, that portion of the packets is irrelevant. Network Monitor can be
The proper interpretation of the remote access and VPN traffic with Network Monitor requires an in-depth understanding of PPP, Point-to-Point Tunneling Protocol (PPTP), IPSec, and other protocols, so it is not for just