When ISA Server 2006 is configured to be a VPN Server there is always a doubt of what to do when something happens and data needs to be gathered since there are two major components in use: ISA Server and Windows RRAS. Depending on the error message you might be able to figure out which one is potentially causing the issue. In this particular scenario the description of the 691 error is very tricky because it sounds like an authentication issue as you can see in Figure 1:
Figure 1 - Error 691 leads you to believe that there is an authentication issue.
By only reading this message the first reaction is to review the authentication repository that ISA Server 2006 is using to authenticate users.
In this particular case this troubleshooter didn’t help to fix the issue, however it did help to isolate and figure out which components were working properly. The next step in this type of case is to gather more data and analyzing it.
2. Gathering Data
The data gathering in this type of scenario is much more on the Windows RRAS side rather than on ISA Server 2006 side. On ISA Server you just need to make sure that the VPN client access configuration is correctly done. To confirm that the configuration is correctly done you can use the article Configuring the ISA Server 2004 Firewall as a VPN Server to review the main steps. Assuming that it is correctly, next step on ISA Server side is to monitoring the user attempt to connect using Monitoring/Logging. In this particular case, ISA Server Logging was showing that the connection was allowed and no major issues were detected:
Figure 2 – ISA Logging showing that the PPTP connections were all allowed.
By isolating ISA Server from the scenario, next step is to get more data on the RRAS side. The best way to do that is by enabling RRAS Tracing Log. To do that open command prompt on ISA Server computer and type:
netsh ras set tracing * enable
By running this command on ISA Server a new set of logging will be created at %systemroot%\tracing folder by Windows RRAS component.
Besides this logging, you also can use the following tools to assist you on gathering even more details to better understand what is happening under the hood:
· Network Monitor: by binding netmon to the internal NIC of ISA you can see the network communication from ISA to any internal server that can be related to this VPN access attempt.
· Process Explorer: RRAS runs under svchost process (svchost.exe –k netsvcs) and with Process Explorer you can verify deeply what this process is doing.
After setup all these tools, repro the
When start analyzing the whole set of data is better to start looking to log files created in %systemroot%\tracing folder. In this particular case the only log file that was showing something that could be related to the issue was the file IASACCT.LOG with the following errors:
You might be thinking that ISA Server is logging on a SQL database and this database is somehow not accessible. However you need to remember that those logs are not related to ISA component, they are all related to Windows RRAS Component.
To confirm that this error was consistently happening, we asked to try to connect again and at this time we used Process Explorer to view more information about the SVCHOST Process as shown in Figure 3:
Figure 3 - Using Process Explorer you also can see that the SVCHOST process is accessing the IASACCT tracing key.
To see more details about this process you need right click on it and choose properties. For this particular case one thing that I want to see was the TCP/IP tab since the error message in the log file says that the server does not exist and my question at that point was: which server? Let’s see in Figure 4 what process explorer says:
Figure 4 – Svchost was trying to establish a connection with 192.168.5.80.
Great, now we know that the SVCHOST process was trying to connect (TCP SYN was sent) to 192.168.5.80. By talking with the system administrator he was able to determine that 192.168.5.80 was an old SQL Server that they used to have, even he didn’t know why and who was using this server.
At this point we already know that ISA Server was not involved as the culprit for this issue and that all evidences points to an issue on Windows RRAS component. In this type of scenario where you need to review RRAS configuration, nothing better than do a quick review on RRAS Management Console to see if everything looks fine. At this point in time in a real troubleshooting scenario within Microsoft CSS, we already have Networking team engaged and working with us to identify what is happening. After reviewing the logs our Networking team was able to conclude that the SQL Server which the logging is complaining about could be hosting the RRAS Logging….bingo!!! Figure 5 shows exactly that:
Figure 5 – RRAS was using a SQL Server that didn’t exist anymore.
This makes perfect sense since in compliance with RADIUS RFC if the logging cannot be reached, all requests should be rejected.
This was a typical example of an issue that started with ISA Server as culprit and required hours of troubleshooting to finally understand what the real issue was. This also helps you to understand that ISA Server VPN component uses Windows RRAS component and that when the ISA is isolated from the main problem, the troubleshooting line needs to follow RRAS tools and techniques.
Security Support Engineer
Microsoft CSS Forefront Edge Team
Sr. Support Escalation Engineer
Microsoft Networking Team
Vic Singh Shahid
Microsoft CSS Forefront Edge Team
Special thanks to Daniel Pires (MS Vendor in Brazil) that worked in an issue like that and inspired me to reproduce this behavior in lab.