Common VPN Problems

  • Article

VPN problems typically fall into the following categories:

  • Connection attempt is rejected when it should be accepted.

  • Connection attempt is accepted when it should be rejected.

  • Unable to reach locations beyond the VPN server.

  • Unable to establish a tunnel.

Use the following troubleshooting tips to isolate the configuration or infrastructure problem causing the stated VPN problem.

Connection attempt is rejected when it should be accepted

  • Using the Ping command, verify that the host name or IP address of the VPN server is reachable. If a host name is being used, verify that the host name is resolved to its correct IP address. If the ping is not successful, packet filtering might be preventing the delivery of ICMP messages to or from the VPN server.

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

  • For remote access VPN connections, verify that the VPN server is enabled for remote access. For router-to-router VPN connections, verify that the VPN server is enabled for demand-dial routing.

  • For remote access VPN connections, verify that the PPTP and L2TP ports are enabled for inbound remote access. For router-to-router VPN connections, verify that the PPTP and L2TP ports are enabled for inbound and outbound demand-dial connections.

  • Verify that the VPN client and the VPN server in conjunction with a remote access policy are configured to use at least one common authentication method.

  • Verify that the VPN client and the VPN server in conjunction with a remote access policy are configured to use at least one common encryption method.

  • Verify that the parameters of the connection have permission through remote access policies.
    In order for the connection to be established, the parameters of the connection attempt must:

    • Match all of 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.

    For more information about remote access policies, see Windows 2000 Server Help and "Remote Access Server" in this book.

  • Verify that the settings of the remote access policy profile are not in conflict with properties of the remote access router.
    The properties of the remote access policy profile and the properties of the RAS server both contain settings for:

    • Multilink

    • Bandwidth allocation protocol

    • Authentication protocols

    If the settings of the profile of the matching remote access policy are in conflict with the settings of the VPN server, the connection attempt is rejected. For example, if the matching remote access policy profile specifies that the EAP-TLS authentication protocol must be used and EAP-TLS is not enabled on the VPN server, the VPN server rejects the connection attempt.

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

    • The RAS and IAS Servers security group exists. If not, then 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.

    • The computer account of the VPN server computer is a member of the RAS and IAS Servers security group. You can use the netsh ras show registeredserver command to view the current registration. You can use the netsh ras add registeredserver command to register the server in a specified domain.

    • If you add or remove the VPN server computer to the RAS and IAS Servers security group, the change does not take effect immediately (due to the way that Windows 2000 caches Active Directory information). For the change to take effect immediately, you need to restart the VPN server computer.

  • For remote access VPN connections, verify that the LAN protocols used by the VPN client are enabled for remote access on the VPN server.

  • Verify that all of the PPTP or L2TP ports on the VPN server are not already being used. If necessary, change the number of PPTP to L2TP ports to allow more concurrent connections.

  • Verify that the tunneling protocol of the VPN client is supported by the VPN server.
    By default, Windows 2000 remote access VPN clients have the Automatic server type option selected, which means that they try to establish a L2TP over IPSec-based VPN connection first, then they try a PPTP-based VPN connection. If either the Point-to-Point Tunneling Protocol (PPTP) or Layer-2 Tunneling Protocol (L2TP) server type option is selected, verify that the selected tunneling protocol is supported by the VPN server.
    By default, a Windows 2000 Server–based computer running the Routing and Remote Access service is a PPTP and L2TP server with five L2TP ports and five 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 zero.

  • For remote access L2TP over IPSec connections, verify that computer certificates, also known as machine certificates, are installed on the VPN client and the VPN server. For more information on troubleshooting IPSec connections, see "Internet Protocol Security" in the TCP/IP Core Networking Guide .

  • 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.

  • If the VPN server is configured with static IP address pools, verify that there are enough addresses.
    If all of the addresses in the static pools 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 client is configured to request its own IPX node number, verify that the VPN server is configured to allow IPX clients to request their own IPX node number.

  • If the VPN server is configured with a range of IPX network numbers, verify that the IPX network numbers in the range are not being used elsewhere on your IPX internetwork.

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

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

  • For a Windows NT version 4.0 Service Pack 4 and later VPN server that is a member of a Windows 2000 mixed mode domain or a Windows 2000 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 Windows 2000 domain, verify that the Everyone group is added to the Pre-Windows 2000 Compatible Access group with the net localgroup " Pre-Windows   2000 Compatible Access " command. If not, issue the net localgroup " Pre-Windows   2000 Compatible Access " everyone /add command on a domain controller computer and then restart the domain controller computer.

  • For a Windows NT version 4.0 Service Pack 3 and earlier VPN server that is a member of a Windows 2000 mixed mode domain, verify that 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 RADIUS authentication, verify that the VPN server computer can communicate with the RADIUS server.

  • For PPTP connections using MS-CHAP v1 and attempting to negotiate 40-bit MPPE encryption, verify that the user's password is not larger than 14 characters.

Connection attempt is accepted when it should be rejected

  • Verify that the parameters of the connection do not have permission through remote access policies.
    A connection can be rejected for the following reasons:
    The parameters of the connection attempt must be denied remote access permission through the remote access permission of the user account (with Deny access selected)
    The user account has the Control access through Remote Access Policy option selected, and the remote access permission of the first remote access policy that matches the parameters of the connection attempt has the Deny remote access permission selected.
    For more information about remote access policies, see Windows 2000 Server Help.

Unable to reach locations beyond the VPN server

  • For remote access VPNs, verify that either the protocol is enabled for routing or the Entire network option is selected for LAN protocols being used by the VPN clients.

  • For remote access VPNs, verify the IP address pools 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 pools are reachable by the hosts and routers of the intranet. If not, then IP route consisting of the VPN server static IP address pools, as defined by the IP address and mask of the range, must be added to the routers of the intranet or enable the routing protocol of your routed 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 Automatic Private IP Addressing (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. By default, the VPN server randomly chooses the adapter to use to obtain IP addresses through DHCP. If there is more than one LAN adapter, then the Routing and Remote Access service may choose a LAN adapter for which there is no DHCP server available. You can manually choose a LAN adapter from the IP tab on the properties of a remote access server in the Routing and Remote Access snap-in.
    If the static IP address pools are 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.

  • For router-to router VPN connections, verify that there are routes on both sides of the router-to-router VPN connection that support the two-way exchange of traffic.
    Unlike a remote access VPN connection, a router-to-router VPN connection does not automatically create a default route. You need to create routes on both sides of the router-to-router VPN connection so that traffic can be routed to and from the other side of the router-to-router VPN connection.
    You can manually add static routes to the routing table, or you can add static routes through routing protocols. For persistent VPN connections, you can enable Open Shortest Path First (OSPF) or Routing Information Protocol (RIP) across the VPN connection. For on-demand VPN connections, you can automatically update routes through an auto-static RIP update.

  • For two-way initiated router-to-router VPN connections, verify that the router-to-router VPN connection is not interpreted by the VPN server as a remote access connection.
    If the user name of the calling router's credentials appears under Remote Access Clients in the Routing and Remote Access snap-in, the VPN server has interpreted the calling router as a remote access client. Verify that the user name in the calling router's credentials matches the name of a demand-dial interface on the VPN server.

  • For one-way initiated router-to-router VPN connections, verify that the routes of the calling router's intranet are configured as static routes on the dial-in properties of the user account used by the calling router.

  • Verify that there are no TCP/IP packet filters on the profile properties of the remote access policy being used by the VPN connection configured on the VPN server (or the RADIUS server if Internet Authentication Service is used) that are preventing the sending or receiving of TCP/IP traffic.

  • For demand-dial VPN connections, verify that there are no packet filters on the demand-dial interfaces of the calling router and answering router that prevent the sending or receiving of traffic.

Unable to establish tunnel

  • Verify that packet filtering on a router interface between the VPN client and the VPN server is not preventing the forwarding of tunneling protocol traffic.
    On a Windows 2000–based VPN server, IP packet filtering can be configured from the advanced TCP/IP properties and from the Routing and Remote Access snap-in. Check both places for filters that might be excluding VPN connection traffic.
    For more information about VPN connection traffic and packet filtering, see "VPNs and Firewalls" earlier in this chapter.

  • Verify that the Winsock Proxy client is not currently running on the VPN client.
    When the Winsock Proxy client is active, Winsock 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 FTP) without directly connecting that organization to the Internet. The organization can instead use InterNIC-allocated private IP network IDs (such as 10.0.0.0/8).
    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.

For more information about troubleshooting remote access VPN connections, see "Remote Access Server" in this book. For more information about troubleshooting router-to-router VPN connections, see "Demand-Dial Routing" in this book.