Troubleshooting Remote Access VPNs


From all the logs and reporting tools, it might seem like troubleshooting VPN connections is a completely daunting and impossible task. Just remember what we said at the beginning of this chapter: “Divide and Conquer”. Remote access VPN problems typically fall into the following categories:

  • Unable to connect

  • Unable to reach locations beyond the VPN server

Use the information in the following sections to isolate the configuration or infrastructure problem causing the problem. If you take it slow and remember to isolate and eliminate potential problem areas as you go through the process, it will all work out fine. Remember, VPN is one of the most complex solutions in the industry today. It is no simple thing to make a remote computer appear as part of the intranet with full encryption and authentication, so don’t get frustrated if two or three separate issues arise. In the end, it will be well worth the effort!

Unable to Connect

The “Unable to connect” problem is a broad one. With all the different pieces involved in negotiating a VPN session, the connection problems can come from many areas. The good news is that Windows has all the functionality built into the base operating system, so you do not need to worry about third-party interoperability issues.

When a VPN client is unable to connect, check the following:

  • Using the ping command when connected to the Internet, verify that the host name for the VPN server is being resolved to its correct IP address. The Ping itself might not be successful because of packet filtering that is preventing ICMP messages to get to and come from the VPN server, so make sure there are no firewalls or routers in the way that are blocking VPN traffic. If, after making sure there are no blocking agents, you still cannot Ping, either a routing or name resolution issue needs to be resolved.

  • If you are using password-based credentials, verify that the VPN client’s credentials—consisting of user name, password, and domain name—are correct and can be validated by the VPN server. The best way to do this is to see if logging directly onto the network can be validated without VPN in the way. If VPN is causing a problem, you will need to check to make sure that the VPN server is working properly with IAS or RADIUS, and that the user account is authorized to create remote access connections.

  • Verify that the user account of the VPN client is not locked out, expired, or disabled, or verify that the time the connection is being made corresponds to the configured logon hours. If the password on the account has expired, verify that the remote access VPN client is using Microsoft Challenge-Hand shake Authentication Protocol (MS-CHAP) or Microsoft Challenge-Handshake Authentication Protocol version 2 (MS-CHAP v2). These are the only authentication protocols provided with Windows Server 2003 that allow you to change an expired password during the connection process.

    For an administrator-level account whose password has expired, reset the password using another administrator-level account.

  • Verify that the user account has not been locked out because of remote access account lockout.

  • Verify that the Routing And Remote Access service is running on the VPN server.

  • Verify that the VPN server is enabled for remote access from the General tab on the properties of a VPN server in the Routing And Remote Access snap-in.

  • Verify that the WAN Miniport (PPTP) and WAN Miniport (L2TP) devices are enabled for inbound remote access from the properties of the Ports object in the Routing And Remote Access snap-in.

  • Verify that the VPN client, the VPN server, and the remote access policy corresponding to VPN connections are configured to use at least one common authentication method.

  • Verify that the VPN client and the remote access policy corresponding to VPN connections are configured to use at least one common encryption strength.

  • Verify that the parameters of the connection have permission through remote access policies.

    For the connection to be accepted, the parameters of the connection attempt must:

    • Match all the conditions of at least one remote access policy.

    • Be granted remote access permission through the user account (set to Allow Access). Or, if the user account has the Control Access Through Remote Access Policy option selected, the remote access permission of the matching remote access policy must have the Grant Remote Access Permission option selected.

    • Match all the settings of the profile.

    • Match all the settings of the dial-in properties of the user account.

    To obtain the name of the remote access policy that rejected the connection attempt, scan the accounting log for the entry corresponding to the connection attempt and look for the policy name. If IAS is being used as a RADIUS server, check the system event log for an entry for the connection attempt.

  • If you are logged on using an account with domain administrator permissions when you run the Routing And Remote Access Server Setup Wizard, it automatically adds the computer account of the RAS And IAS Servers domain-local security group. This group membership allows the VPN server computer to access user account information. If the VPN server is unable to access user account information, verify that:

    • The computer account of the VPN server computer is a member of the RAS And IAS Servers security group for all the domains that contain user accounts for which the VPN server is authenticating remote access. You can use the netsh ras show registeredserver command at the command prompt to view the current registration. You can use the netsh ras add registeredserver command to register the server in a domain in which the VPN server is a member or other domains. Alternatively, you or your domain administrator can add the computer account of the VPN server computer to the RAS And IAS Servers security group of all the domains that contain user accounts for which the VPN server is authenticating remote access.

    • If you add or remove the VPN server computer to the RAS And IAS Servers security group, the change does not take effect immediately (because of the way that Windows Server 2003 caches Active Directory directory service information). For the change to take effect immediately, you need to restart the VPN server computer.

  • For a VPN server that is a member server in a mixed-mode or native-mode Active Directory domain that is configured for Windows authentication, verify that:

    • The RAS And IAS Servers security group exists. If it does not, create the group and set the group type to Security and the group scope to Domain Local.

    • The RAS And IAS Servers security group has Read permission to the RAS And IAS Servers Access Check object.

  • Verify that IP is enabled for remote access on the VPN server.

  • Verify that all the PPTP or Layer Two Tunneling Protocol (L2TP) ports on the VPN server are not already being used. If necessary, the number of PPTP to L2TP ports by using the properties of the Ports object in the Routing And Remote Access snap-in to allow more concurrent connections.

  • Verify that the VPN server supports the tunneling protocol of the VPN client.

    By default, Windows 2000 remote access VPN clients have the Automatic Server Type option selected, which means that they try to establish an L2TP/ IPSec-based VPN connection first, and then they try a PPTP-based VPN connection. If either the PPTP or L2TP server type option is selected, verify that the VPN server supports the selected tunneling protocol.

    By default, Windows XP remote access VPN clients have the Automatic VPN Type option selected, which means that they try to establish a PPTP-based VPN connection first, and then they try an L2TP/IPSec-based VPN connection. If either the PPTP VPN or L2TP IPSec VPN Type option is selected, verify that the VPN server supports the selected tunneling protocol.

    Depending on your selections when running the Routing And Remote Access Server Setup Wizard, a Windows Server 2003–based computer running the Routing And Remote Access service is a PPTP and L2TP server with five or 128 L2TP ports and five or 128 PPTP ports. To create a PPTP-only server, set the number of L2TP ports to zero. To create an L2TP-only server, set the number of PPTP ports to 1 and disable remote access inbound connections and demand-dial connections for the WAN Miniport (PPTP) device from the properties of the Ports object in the Routing And Remote Access snap-in.

  • For L2TP/IPSec connections, verify that computer certificates, also known as machine certificates, are installed on the VPN client and the VPN server.

  • If the VPN server is configured with a static IP address pool, verify that there are enough addresses. If all the addresses in the static pool have been allocated to connected VPN clients, the VPN server is unable to allocate an IP address for TCP/IP-based connections and the connection attempt is rejected. If the VPN server is using DHCP to allocate addresses, another issue to check for is whether the VPN server is handing out valid addresses. For example, if the VPN server cannot contact the DHCP server to get IP addresses, it could start handing out automatic private addressing in the Automatic Private IP Addressing (APIPA) address range from 169.254.0.1 through 169.254.255.254. This is not a valid range for remote access connectivity. If this problem is occurring, check the DHCP/VPN server interactions to make sure DHCP requests are being resolved and then have anyone with an APIPA address re-establish the VPN connection to get a valid IP address.

  • Verify the configuration of the authentication provider. The VPN server can be configured to use either Windows or RADIUS to authenticate the credentials of the VPN client.

  • For RADIUS authentication, verify that the VPN server computer can communicate with the RADIUS server.

  • For a VPN server that is a member of a native-mode domain, verify that the VPN server has joined the domain.

  • For either a Windows NT 4.0 Service Pack 4 and later VPN server that is a member of a mixed-mode domain or a Windows Server 2003 VPN server that is a member of a Windows NT 4.0 domain that is accessing user account properties for a user account in a trusted Active Directory domain, verify that the Everyone group is part of the Pre-Windows 2000 Compatible Access group by using the net localgroup “Pre-Windows 2000 Compatible Access” command. If it is not, issue the net localgroup “Pre-Windows 2000 Compatible Access” everyone /add command on a domain controller computer and then restart the domain controller.

  • For a Windows NT 4.0 Service Pack 3 and earlier VPN server that is a member of a mixed-mode domain, verify that the Everyone group has been granted list contents, read all properties, and read permissions to the root node of your domain and all sub-objects of the root domain.

  • For PPTP connections using MS-CHAP and attempting to negotiate 40-bit Microsoft Point-to-Point Encryption (MPPE) encryption, verify that the user’s password is not longer than 14 characters.

  • Verify that packet filtering on a router or firewall interface between the VPN client and the VPN server is not preventing the forwarding of tunneling protocol traffic. See Appendix B for information on the types of traffic that must be allowed for PPTP and L2TP/IPSec traffic.

    On a Windows Server 2003–based VPN server, IP packet filtering can be separately configured from the advanced TCP/IP properties and from the properties of an interface under IP Routing in the Routing And Remote Access snap-in. Check both places for filters that might be excluding VPN connection traffic.

  • Verify that the Winsock Proxy client is not currently running on the VPN client.

    When the Winsock Proxy client is active, Winsock application programming interface (API) calls such as those used to create tunnels and send tunneled data are intercepted and forwarded to a configured proxy server.

    A proxy server–based computer allows an organization to access specific types of Internet resources (typically Web and file transfer protocol [FTP]) without directly connecting that organization to the Internet. The organization can instead use private IP network IDs (such as 10.0.0.0/8, 172.16.0.0/ 12, and 192.168.0.0/16).

    Proxy servers are typically used so that private users in an organization can have access to public Internet resources as if they were directly attached to the Internet. VPN connections are typically used so that authorized public Internet users can gain access to private organization resources as if they were directly attached to the private network. A single computer can act as a proxy server (for private users) and a VPN server (for authorized Internet users) to facilitate both exchanges of information.

L2TP/IPSec Authentication Issues

The most common problems that cause L2TP/IPSec connections to fail are discussed in the list below. A typical Oakley log for an L2TP/IPSec connection can be found on the companion CD-ROM, which you can compare to your own.

  • No certificate. By default, L2TP/IPSec connections require that the remote access server and remote access client exchange computer certificates for IPSec peer authentication. Check the Local Computer certificate stores of both the remote access client and remote access server using the Certificates snap-in to ensure that a suitable certificate exists.

  • Incorrect certificate. If certificates exist, they must be verifiable. Unlike manually configuring IPSec rules, the list of certification authorities (CAs) for L2TP/IPSec connections is not configurable. Instead, each computer in the L2TP connection sends a list of root CAs to its IPSec peer from which it accepts a certificate for authentication. The root CAs in this list correspond to the root CAs that issued computer certificates to the computer. For example, if Computer A was issued computer certificates by root CAs CertAuth1 and CertAuth2, it notifies its IPSec peer during main mode negotiation that it will accept certificates for authentication from only CertAuth1 and CertAuth2. If the IPSec peer, Computer B, does not have a valid computer certificate issued from either CertAuth1 or CertAuth2, IPSec security negotiation fails.

    The VPN client must have a valid computer certificate installed that was issued by a CA and follows a valid certificate chain from the issuing CA up to a root CA that the VPN server trusts. Additionally, the VPN server must have a valid computer certificate installed that was issued by a CA and follows a valid certificate chain from the issuing CA up to a root CA that the VPN client trusts.

  • A network address translator (NAT) between the remote access client and remote access server. If there is a NAT between a Windows 2000 or Windows XP–based L2TP/IPSec client and a Windows Server 2003 L2TP/ IPSec server, you cannot establish an L2TP/IPSec connection unless the L2TP/IPSec NAT-traversal (NAT-T) Update for Windows XP or Windows 2000 (available at http://windowsupdate.microsoft.com—Windows 2000 is available on the main site, and Windows XP is available on the Catalog site) is installed on the client. This update will be incorporated into Windows 2000 SP5 and Windows XP SP2 in the future.

  • A firewall between the remote access client and remote access server. If there is a firewall between a Windows L2TP/IPSec client and a Windows Server 2003 L2TP/IPSec server and you cannot establish an L2TP/

  • IPSec connection, verify that the firewall allows L2TP/IPSec traffic to be forwarded. For more information, see Appendix B.

One of the best tools for troubleshooting IPSec authentication issues is the Oakley log. For more information, see the Oakley Logging section in this chapter.

Extensible Authentication Protocol–Transport Layer Security (EAP-TLS) Authentication Issues

When EAP-TLS is used for authentication, the VPN client submits a user certificate, and the authenticating server (the VPN server or the RADIUS server) submits a computer certificate.

For the authenticating server to validate the certificate of the VPN client, the following must be true for each certificate in the certificate chain sent by the VPN client:

  • The current date must be within the validity dates of the certificate.

    When certificates are issued, they are issued with a range of valid dates, before which they cannot be used and after which they are considered expired. To view the range of validity dates for a certificate in the Certificates snap-in, open the certificate, click the Details tab, and then click the Valid From and Valid To fields.

  • The certificate has not been revoked.

    Issued certificates can be revoked at any time. Each issuing CA maintains a list of certificates that should no longer be considered valid by publishing an up-to-date certificate revocation list (CRL). By default, the authenticating server checks all the certificates in the VPN client’s certificate chain (the series of certificates from the VPN client certificate to the root CA) for revocation. If any of the certificates in the chain have been revoked, certificate validation fails. This behavior can be modified with registry settings described later in this section.

    To view the CRL distribution points for a certificate in the Certificates snap- in, open the certificate, click the Details tab, and then click the CRL Distribution Points field.

    The certificate revocation validation works only as well as the CRL publishing and distribution system. If the CRL in a certificate is not updated often, a certificate that has been revoked can still be used and considered valid because the published CRL that the authenticating server is checking is out of date.

  • The certificate has a valid digital signature.

    CAs digitally sign certificates they issue. The authenticating server verifies the digital signature of each certificate in the chain, with the exception of the root CA certificate, by obtaining the public key from the certificate’s issuing CA and mathematically validating the digital signature.

    The VPN client certificate must have the Client Authentication certificate (OID of 1.3.6.1.5.5.7.3.2)—also known as Enhanced Key Usage (EKU). The VPN client certificate must also conatin a user principal name (UPN) of a valid user account for the Subject Alternative Name property of the certificate.

    To view the EKU for a certificate in the Certificates snap-in, double-click the certificate in the contents pane, click the Details tab, and then click the Enhanced Key Usage field. To view the subject alternative name property for a certificate in the Certificates snap-in, double-click the certificate in the contents pane, click the Details tab, and then click the Subject Alternative Name field.

Finally, to trust the certificate chain offered by the VPN client, the authenticating server must have the root CA certificate of the issuing CA of the VPN client certificate installed in its Trusted Root Certification Authorities Local Computer store.

Additionally, the authenticating server verifies that the identity sent in the EAP- Response/Identity message is the same as the name in the Subject Alternative Name property of the certificate. The VPN client sends the EAP-Response/Identity message during the Extensible Authentication Protocol (EAP) authentication exchange. This prevents a malicious user from masquerading as a different user from that specified in the EAP-Response/Identity message.

If the authenticating server is a Windows Server 2003 VPN server or an IAS server, the following registry settings in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13 can modify the behavior of EAP-TLS when performing certificate revocation:

  • IgnoreNoRevocationCheck

    When this option is set to 1, the authenticating server allows EAP-TLS clients to connect even when it does not perform or cannot complete a revocation check of the VPN client’s certificate chain (excluding the root certificate). Typically, revocation checks fail because the certificate doesn’t include CRL information.

    IgnoreNoRevocationCheck is set to 0 (disabled) by default. An EAP-TLS client cannot connect unless the server completes a revocation check of the client’s certificate chain (including the root certificate) and verifies that none of the certificates have been revoked.

    You can use this entry to authenticate clients when the certificate does not include CRL distribution points, such as those from third parties.

  • IgnoreRevocationOffline

    When set to 1, the authenticating server allows EAP-TLS clients to connect even when a server that stores a CRL is not available on the network. IgnoreRevocationOffline is set to 0 by default. The authenticating server does not allow clients to connect unless it can complete a revocation check of their certificate chain and verify that none of the certificates has been revoked. When it cannot connect to a server that stores a revocation list, EAP-TLS considers the certificate to have failed the revocation check.

    Setting IgnoreRevocationOffline to 1 prevents certificate validation failure from occurring because poor network conditions prevented a certificate’s revocation check from completing successfully.

  • NoRevocationCheck

    When set to 1, the authenticating server prevents EAP-TLS from performing a revocation check of the VPN client’s certificate. The revocation check verifies that the VPN client’s certificate and the certificates in its certificate chain have not been revoked. NoRevocationCheck is set to 0 by default.

  • NoRootRevocationCheck

    When set to 1, the authenticating server prevents EAP-TLS from performing a revocation check of the VPN client’s root CA certificate. NoRootRevocationCheck is set to 0 by default. This entry eliminates only the revocation check of the client’s root CA certificate. A revocation check is still performed on the remainder of the VPN client’s certificate chain.

    You can use this entry to authenticate clients when the certificate does not include CRL distribution points, such as those from third parties. Also, this entry can prevent certification-related delays that occur when a certificate revocation list is offline or is expired.

All these registry settings must be added as a DWORD type and have the valid values of 0 or 1. The VPN client does not use these settings.

For the VPN client to validate the certificate of the authenticating server for either EAP-TLS authentication, the following must be true for each certificate in the certificate chain sent by the authenticating server:

  • The current date must be within the validity dates of the certificate.

  • The certificate has a valid digital signature.

    The VPN client verifies the digital signature of each certificate in the chain by obtaining the public key from the certificate’s issuing CA and mathematically validating the digital signature. The root CA certificate is self-signed.

Additionally, the authenticating server computer certificate must have the Server Authentication EKU (OID 1.3.6.1.5.5.7.3.1). To view the EKU for a certificate in the Certificates snap-in, double-click the certificate in the contents pane, click the Details tab, and then click the Enhanced Key Usage field.

Finally, to trust the certificate chain offered by the authenticating server, the VPN client must have the root CA certificate of the issuing CA of the authenticating server certificate installed in its Trusted Root Certification Authorities computer or user store.

Notice that the VPN client does not perform certificate revocation checking for the certificates in the certificate chain of the authenticating server’s computer certificate. The assumption is that the VPN client does not yet have a connection to the network, and therefore cannot access a Web page or other resource in order to check for certificate revocation.

Unable to Reach Locations Beyond the VPN Server

Now that we have established successful connectivity, we are done with most of the battle. Access to the network is achieved, but now we need to make sure that all the appropriate resources are reachable. If VPN clients are unable to send and receive traffic from locations on the intranet that are beyond the VPN server, check the following:

  • Verify that either the protocol is enabled for routing or that dial-in clients are allowed to access the entire network for LAN protocols being used by the VPN clients.

  • Verify the IP address pool of the VPN server.

    If the VPN server is configured to use a static IP address pool, verify that the routes to the range of addresses defined by the static IP address pool are reachable by the hosts and routers of the intranet. If they are not, you must add IP routes consisting of the VPN server static IP address ranges, as defined by the IP address and mask of the range, to the routers of the intranet, or you must enable the routing protocol of your routing infrastructure on the VPN server. If the routes to the remote access VPN client subnets are not present, remote access VPN clients cannot receive traffic from locations on the intranet. Routes for the subnets are implemented either through static routing entries or through a routing protocol, such as Open Shortest Path First (OSPF) or Routing Information Protocol (RIP).

    If the VPN server is configured to use DHCP for IP address allocation and no DHCP server is available, the VPN server assigns addresses from the APIPA address range from 169.254.0.1 through 169.254.255.254. Allocating APIPA addresses for remote access clients works only if the network to which the VPN server is attached is also using APIPA addresses.

    If the VPN server is using APIPA addresses when a DHCP server is available, verify that the proper adapter is selected from which to obtain DHCP-allocated IP addresses. The Routing And Remote Access Server Setup Wizard assigns the default adapter automatically. You can manually choose a LAN adapter from the Adapter list on the IP tab on the Properties sheet for a VPN server in the Routing And Remote Access snap-in.

    If the static IP address pool contains a range of IP addresses that are a subset of the range of IP addresses for the network to which the VPN server is attached, verify that the range of IP addresses in the static IP address pool are not assigned to other TCP/IP nodes, either through static configuration or through DHCP.

  • Verify that there are no packet filters on the profile properties of the remote access policy corresponding to VPN connections that are preventing the sending or receiving of traffic.




Deploying Virtual Private Networks With Microsoft Windows Server 2003
Deploying Virtual Private Networks with Microsoft Windows Server 2003 (Technical Reference)
ISBN: 0735615764
EAN: 2147483647
Year: 2006
Pages: 128

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net