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
Internet Authentication Services (IAS) event logging
Point-to-Point Protocol (PPP) logging
Each tool handles a specific area of testing and logging. The list looks daunting at first, but if you maintain good notes and methods, and don’t lose your patience, everything will fall into place. Let’s take a look at each tool set to understand when and where to use each.
The TCP/IP troubleshooting tools are used to test connectivity to remote servers, clients, and resources. You will find the best use of these tools is at multiple points of the process: first make sure routing and connectivity exist to base services prior to VPN services being activated, and then test connectivity while VPN services are functioning. With this process, you can rule out connectivity being an issue while troubleshooting VPN. The Ping, Tracert, and Pathping tools use Internet Control Message Protocol (ICMP) Echo and Echo Reply messages to verify connectivity, display the path to a destination, and test path integrity. The route print command can be used to display the Internet Protocol (IP) routing table. Alternatively, on the VPN server, you can use the netsh routing ip show rtmroutes command or the Routing And Remote Access snap-in. The Nslookup tool can be used to troubleshoot DNS and name resolution issues.
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 especially useful for troubleshooting remote access policy issues. For each authentication attempt, the name of the remote access policy that either accepted or rejected the connection attempt is recorded.
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 User Service [RADIUS] authentication and accounting and the RADIUS server is an IAS server).
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 in-depth, step-by-step picture of the remote access events. Using the Log All Events option can add up to a lot of information per login attempt, successful or otherwise, so after you are done viewing remote access events, make sure to set the event logging back to the Log Errors And Warnings option on the Logging tab to conserve system resources. If the Log All Events option is left on, you will quickly encounter processor utilization and disk space issues.
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 valuable source of information when you are troubleshooting the failure of a PPP connection. To enable logging of all optional components—including PPP—select the Log Additional Routing And Remote Access Information option on the Logging tab in the properties of a VPN server.
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 extensive tracing capability you can use to troubleshoot complex network problems. You can enable the components in Windows Server 2003 to log tracing information to files by using the netsh command or through the registry.
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 enabled|disabled
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 adhere to—the trace files contain security information you do not want a malicious user to obtain in the case of an internal breach.
Alternatively, you can configure the tracing function by changing settings in the Windows Server 2003 registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
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 subkey under the preceding registry key.
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 size of the log file by setting different values for MaxFileSize. The default value is 0x1000000 (1MB).
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 experienced with the Routing And Remote Access service. Tracing information can be saved as files and sent to Microsoft support for analysis. Samples of these tracing logs can be found on the companion CD-ROM.
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 related IPSec services by running the following sequence of commands:
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 optionally installed as a networking component.
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 anyone to decipher and understand. If you are having difficulty interpreting the Network Monitor tracing, the Microsoft recommendation is to have Network Monitor captures saved as files and sent to your Microsoft support provider for analysis.