Share via

Troubleshooting remote access VPNs

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Troubleshooting remote access VPNs

What problem are you having?

  • I received error 800, which says the VPN server is unreachable

  • I received error 721, which says the remote computer is not responding

  • I received error 741/742, which says there is an encryption mismatch error

  • I am unable to establish a remote access VPN connection

  • VPN clients are unable to access resources beyond the VPN server

I received error 800, which says the VPN server is unreachable.

  • Cause: PPTP/L2TP packets from the VPN client cannot reach the VPN server.

  • Solution:

    • Assuming ping is allowed (that is, not blocked) between the VPN client and the VPN server, ping the VPN server. Confirm that you have network connectivity and that packet filters configured on the VPN server are not preventing communication.

    • By default, when you configure the Routing and Remote Access service for the VPN server role, only PPTP and L2TP/IPsec packets are allowed on the Internet interface of the VPN server. Internet Control Message Protocol (ICMP) packets used by the ping command are filtered out. To enable ping on the VPN server, add an input filter and an output filter that allow ICMP traffic.

    • To allow PPTP traffic, configure the network firewall to open TCP port 1723 and to forward IP protocol 47 for Generic Routing Encapsulation (GRE) traffic to the VPN server. Some firewalls refer to IP protocol 47 as VPN or PPTP pass-through. Not all firewalls support IP protocol 47. You may need to upgrade the firmware.

    • To allow L2TP traffic, configure the network firewall to open UDP port 1701 and to allow IPsec ESP formatted packets (IP protocol 50).

    • Check that the VPN server is listening for PPTP traffic on TCP port 1723 and is listening for L2TP traffic on UDP port 1701. On the VPN server, from the command line, type:

      netstat -aon

      You should see the following:

      TCP

      0.0.0.0:1723

      0.0.0.0:0

      LISTENING

      UDP

      0.0.0.0:1701

      *:*

    • You can use the Portqry command-line tool to determine if PPTP and L2TP packets are being dropped between the VPN client and VPN server. For more information, see Description of the Portqry.exe command-line utility on the Microsoft Web site (https://go.microsoft.com/fwlink/?LinkId=71609).

      To query the PPTP port, use the following command: portqry.exe -n <server_IP_address> -e 1723

      To query the L2TP port, use the following command: portqry.exe -n <server_IP_address> -e 1701 -p UDP

      If the query output includes "NOT LISTENING/FILTERED", check the port configuration on the RRAS server.

I received error 721, which says the remote computer is not responding.

  • Cause: This issue can occur if the network firewall does not permit GRE traffic (IP protocol 47). PPTP uses GRE for tunneled data.

  • Solution: Configure the network firewall between the VPN client and the server to permit GRE. In addition, make sure that the network firewall permits TCP traffic on port 1723. Both of these conditions must be met to establish VPN connectivity by using PPTP. For more information, see article 888201, "You receive an "Error 721" error message when you try to establish a VPN connection through your Windows Server-based remote access server" in the Microsoft Knowledge Base.

Note

The firewall might be on or in front of the VPN client or in front of the VPN server.

I received error 741/742, which says there is an encryption mismatch error.

  • Cause: These errors occur if the VPN client requests an encryption level that is not valid or if the VPN server does not support an encryption type requested by the client.

  • Solution:

    • Check the properties (Security tab) of the VPN connection on the VPN client. If Require data encryption (disconnect if none) is selected, clear the selection and retry the connection.

    • If you are using Internet Authentication Service (IAS), check the encryption level in the remote access policy in the IAS console or policies on other RADIUS servers. Ensure that the encryption level requested by the VPN client is selected on the VPN server.

I am unable to establish a remote access VPN connection.

  • Cause:  The user account used by the remote access client is locked out, expired, disabled, or the time the connection is being made does not correspond to the configured logon hours.

  • Solution:  Modify the account properties of the user account.

See also:  Manage Users, Groups, and Computers

Cause:  The Routing and Remote Access service is not started on the VPN server.

Solution:  Verify the state of the Routing and Remote Access service on the VPN server.

See also:  Monitor the Routing and Remote Access service; Start and stop the Routing and Remote Access service

Cause:  Remote access is not enabled on the VPN server.

Solution:  Enable remote access on the VPN server.

See also:  Enable the remote access server

Cause:  PPTP or L2TP ports are not enabled for inbound remote access requests.

Solution:  Enable PPTP ports, L2TP ports, or both, for inbound remote access requests.

See also:  Configure ports for remote access

Cause:  The LAN protocols being used by the VPN clients are not enabled for remote access on the VPN server.

Solution:  Enable the LAN protocols being used by the VPN clients for remote access on the VPN server.

See also:  View properties of the remote access server

Cause:  All of the PPTP or L2TP ports on the VPN server are already being used by currently connected remote access clients or demand-dial routers.

Solution:  Verify that all of the PPTP or L2TP ports on the VPN server are not already being used by clicking Ports in Routing and Remote Access. If necessary, change the number of PPTP or L2TP ports to allow more concurrent connections.

See also:  Add PPTP or L2TP ports

Cause:  The tunneling protocol of the VPN client is not supported by the VPN server.

By default, remote access VPN clients running Windows XP or a Windows Server 2003 operating system use the Automatic server type option, which means that they try to establish a PPTP-based VPN connection first, and then they try an L2TP/IPSec-based VPN connection. If VPN clients use either the Point-to-Point Tunneling Protocol (PPTP) or Layer Two Tunneling Protocol (L2TP) server type option, verify that the selected tunneling protocol is supported by the VPN server.

By default, a computer running a Windows Server 2003 operating system and 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 0. To create an L2TP-only server, set the number of PPTP ports to 1 and disable remote access inbound connections and demand-dial connections.

Solution:  Verify that the appropriate number of PPTP or L2TP ports is configured.

See also:  Add PPTP or L2TP ports

Cause:  The VPN client and the VPN server in conjunction with a remote access policy are not configured to use at least one common authentication method.

Solution:  Configure the VPN client and the VPN server in conjunction with a remote access policy to use at least one common authentication method.

See also:  Configure authentication

Cause:  The VPN client and the VPN server in conjunction with a remote access policy are not configured to use at least one common encryption method.

Solution:  Configure the VPN client and the VPN server in conjunction with a remote access policy to use at least one common encryption method.

See also:  Configure encryption

Cause:  The VPN connection does not have the appropriate permissions through dial-in properties of the user account and remote access policies.

Solution:  Verify that the VPN connection has the appropriate permissions through dial-in properties of the user account and remote access policies.

In order for the connection to be established, the settings 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 through the user account (set to Control access through Remote Access Policy) and the remote access permission of the matching remote access policy (set to Grant remote access permission).

  • Match all the settings of the profile.

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

See also:  Introduction to remote access policies; Accepting a connection attempt

Cause:  The settings of the remote access policy profile are in conflict with properties of the VPN server.

The properties of the remote access policy profile and the properties of the VPN 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 is not enabled on the VPN server, the connection attempt is rejected.

Solution:  Verify that the settings of the remote access policy profile are not in conflict with properties of the VPN server.

See also:  Enable authentication protocols; Configure authentication

Cause:  The credentials of the VPN client (user name, password, and domain name) are incorrect and cannot be validated by the VPN server.

Solution:  Verify that the credentials of the VPN client (user name, password, and domain name) are correct and can be validated by the VPN server.

Cause:  There are not enough addresses in the static IP address pool.

Solution:  If the VPN server is configured with a static IP address pool, verify that there are enough addresses in the pool. If all of the addresses in the static pool have been allocated to connected VPN clients, the VPN server is unable to allocate an IP address, and the connection attempt is rejected. Modify the static IP address pool if needed.

See also:  Create a static IP address pool

Cause:  The VPN client is configured to request its own IPX node number, and the VPN server is not configured to allow IPX clients to request their own IPX node number.

Solution:  Configure the VPN server to allow IPX clients to request their own IPX node number.

Cause:  The VPN server is configured with a range of IPX network numbers that are being used elsewhere on your IPX internetwork.

Solution:  Configure the VPN server with a range of IPX network numbers that is unique to your IPX internetwork.

Cause:  The authentication provider of the VPN server is improperly configured.

Solution:  Verify the configuration of the authentication provider. You can configure the VPN server to use either Windows or RADIUS to authenticate the credentials of the VPN client.

See also:  Use RADIUS authentication

Cause:  The VPN server cannot access Active Directory.

Solution:  For a VPN server that is a member server in a Windows 2000 mixed domain or a Windows 2000 native domain that is configured for Windows 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 the VPN server computer to (or remove the VPN server computer from) the RAS and IAS Servers security group, the change does not take effect immediately (due to the way that Active Directory information is cached). For the change to take effect immediately, you need to restart the VPN server computer.

  • For a Windows 2000 native domain, the VPN server has joined the domain.

See also:  Create a new group; Verify permissions for the RAS and IAS security group; Netsh commands for remote access; Domain and forest functionality

Cause:  A Windows NT 4.0 VPN server cannot validate connection requests.

Solution:  If VPN clients are dialing in to a VPN server running Windows NT 4.0 that is a member of a Windows 2000 mixed 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, type net localgroup "Pre-Windows 2000 Compatible Access" everyone /add at a command prompt on a domain controller computer and then restart the domain controller computer.

See also:  Domain and forest functionality

Cause:  The VPN server is unable to communicate with the configured RADIUS server.

Solution:  If your RADIUS server is only reachable through your Internet interface, add an input filter and output filter to the Internet interface for UDP port 1812 (based on RFC 2138, "Remote Authentication Dial-In User Service (RADIUS)") or UDP port 1645 (for older RADIUS servers) for RADIUS authentication and UDP port 1813 (based on RFC 2139, "RADIUS Accounting") or UDP port 1646 (for older RADIUS servers) for RADIUS accounting.

See also:  Add a packet filter

Cause:  Cannot ping the VPN server from the Internet.

Solution:  Due to the PPTP and L2TP/IPSec packet filtering that is configured on the Internet interface of the VPN server, Internet Control Message Protocol (ICMP) packets used by the ping command are filtered out. To enable ping capability on the VPN server, you need to add an input filter and an output filter that allow traffic for IP protocol 1 (ICMP traffic).

See also:  Add a packet filter

VPN clients are unable to access resources beyond the VPN server.

Cause:  The LAN protocols used by remote access VPN clients are not enabled to allow access to the network to which the VPN server is attached.

Solution:  Configure the LAN protocols used by the remote access VPN clients to allow access to the network to which the VPN server is attached.

See also:  View properties of the remote access server

Cause:  A static IP address pool is configured but there are no routes back to the remote access VPN clients.

Solution:  If the VPN server is configured to use a static IP address pool, verify that the routes to the ranges of addresses defined by the static IP address pool are reachable by the hosts and routers of the intranet. If not, then IP routes consisting of the address ranges of the static IP address pool, as defined by the IP address and mask of each range, must be added to the routers of the intranet, or the routing protocol of your routed infrastructure on the VPN server must be enabled. 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. A route for the network is 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 allocates 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.

If the static IP address pool consists of ranges 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 ranges of IP addresses of the static IP address pool are not assigned to other TCP/IP nodes, either through static configuration or through DHCP.

See also:  Create a static IP address pool

Cause:  Packet filters on the remote access policy profile are preventing the flow of IP traffic.

Solution:  Verify that there are no configured TCP/IP packet filters on the profile properties of the remote access policies 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.

You can use remote access policies to configure TCP/IP input and output packet filters that control the exact nature of TCP/IP traffic allowed on the VPN connection. Verify that the profile TCP/IP packet filters are not preventing the flow of needed traffic.

See also:  Configure IP options

For more information about troubleshooting remote access connections, see Remote Access Troubleshooting.

Note

  • On Windows Server 2003, Web Edition, and Windows Server 2003, Standard Edition, you can create up to 1,000 Point-to-Point Tunneling Protocol (PPTP) ports, and you can create up to 1,000 Layer Two Tunneling Protocol (L2TP) ports. However, Windows Server 2003, Web Edition, can accept only one virtual private network (VPN) connection at a time. Windows Server 2003, Standard Edition, can accept up to 1,000 concurrent VPN connections. If 1,000 VPN clients are connected, further connection attempts are denied until the number of connections falls below 1,000.