Given the complexities involved in Windows VPN configurations, there is no way to provide a comprehensive guide to VPN troubleshooting within the constraints of an article. Instead, I will discuss some common reasons why a remote user might have trouble establishing a VPN connection.
When a user has trouble connecting to a VPN (especially a new VPN), it's easy to assume that the VPN is configured incorrectly. However, before you start investigating configuration, it is best to begin by looking at the account that belongs to the user who is having problems connecting. There are a number of user-account-related issues that can cause a VPN connection to fail.
For example, the account might be locked or disabled. Likewise, if your user accounts are configured to permit logins during only certain times of day, it could be that a remote user was trying to establish their VPN connection outside of normal working hours.
Still another possibility related to the user's account is that the user may have never been granted the necessary permissions to log
Requires Free Membership to View
SearchEnterpriseWAN.com members gain immediate and unlimited access to breaking industry news, best practices for designing and managing Wide Area Networks, WAN Security, and more -- all at no cost. Join me on SearchEnterpriseWAN.com today!
Kate Gerwig, Editorial Director
in remotely. If you examine a user's properties sheet within the Active Directory Users and Computers console, you will notice that there is a dial-in tab which allows you to grant or deny the user remote access permissions. Although this tab is labeled "dial-in," these permissions also affect VPN connections.
If all of the user's permissions check out, another thing you can check is to make sure that the Routing and Remote Access service is still running on the VPN server. Sometimes services tend to shut down for no apparent reason, so checking the status of the Routing and Remote Access service is a good step.
Yet another issue that can cause users to have trouble connecting to the VPN server is that the PPTP or the L2TP ports are not configured to accept inbound remote access requests. To check to see how these ports are configured, open the Routing and Remote Access console and navigate through the console tree to Routing and Remote Access | your server | Ports. Now, right click on the Ports container and select the Properties command from the resulting shortcut menu. When you do, Windows will open the Ports properties sheet. Select a device from the list of ports and click the Configure button. You will now see the Configure Device dialog box. Verify that the Remote Access Connections (Inbound Only) and the Demand Dial Routing Connections (Inbound and Outbound) check boxes are selected.
While you are looking at the Configure Device dialog box, make note of the Maximum Ports setting. A common reason why VPN connections can fail is because all of the allocated ports are in use. You can find out how many ports are actually being used by selecting the Ports container in the Routing and Remote Access console and then looking at the contents of the Details pane.
 |
||||
|
|
|||
|
||||
One last issue I want to talk about is that the server that is running the Internet Authentication Service (IAS) might be trying to use an invalid certificate. When IAS uses the EAP-TLS authentication method, TLS uses a cached copy of the certificate properties rather than reading the certificate from the certificate store each time. Normally, this doesn't present a problem. However, if you were to replace the certificate with a new one, TLS will continue to attempt to make use of the now expired certificate until the cache entry expires. You can however force a cache refresh by rebooting the server.
As you can see, there are a number of very minor issues that can cause a perfectly configured Windows VPN to refuse user connections. Hopefully, this article has helped you learn how to get around them.
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer he has written for Microsoft, CNET, ZDNet, TechTarget, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at www.brienposey.com.
This was first published in April 2006