Troubleshooting router-to-router VPNs

Artikel
10/08/2009

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

Troubleshooting router-to-router VPNs

What problem are you having?

Unable to establish a router-to-router VPN connection.
Unable to send and receive data.

Unable to establish a router-to-router VPN connection.

Cause: The user account used by the calling router 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.

Cause: The Routing and Remote Access service is not started on the VPN client (the calling router) and the VPN server (the answering router).

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

Cause: LAN and WAN routing is not enabled on the calling router and the answering router.

Solution: Enable Local and remote routing (LAN and WAN router) on the calling router and the answering router.

See also: Enable LAN and WAN routing

Cause: PPTP or L2TP ports are not enabled for inbound and outbound demand-dial routing connections.

Solution: Enable PPTP ports, L2TP ports, or both, for inbound and outbound demand-dial routing connections.

See also: Enable routing on ports

Cause: All of the PPTP or L2TP ports on the calling or answering router 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 calling router is not supported by the answering router.

By default, demand-dial interfaces on a computer running a Windows Server 2003 operating system use the Automatic server type option, which means that they try to establish an L2TP/IPSec-based VPN connection first, and then they try a PPTP-based VPN connection. If calling routers use either the Point-to-Point Tunneling Protocol (PPTP) or Layer-2 Tunneling Protocol (L2TP) server type option, verify that the selected tunneling protocol is supported by the answering router.

By default, a computer running a Windows Server 2003 operating system and the Routing and Remote Access service is a PPTP and L2TP-capable demand dial router with five L2TP ports and five PPTP ports. To create a PPTP-only router, set the number of L2TP ports to 0. To create an L2TP-only router, 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 on the calling router and answering router.

See also: Add PPTP or L2TP ports

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

Solution: Configure the calling router and the answering router in conjunction with a remote access policy to use at least one common authentication method.

See also: Configure authentication

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

Solution: Configure the calling router and the answering router 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.

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

The properties of the remote access policy profile and the properties of the answering router 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 answering router, 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 answering router, 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.

Cause: The credentials of the calling router (user name, password, and domain name) are incorrect and cannot be validated by the answering router.

Solution: Verify that the credentials of the calling router (user name, password, and domain name) are correct and can be validated by the answering router.

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

Solution: If the answering router 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 remote access clients or demand-dial routers, the answering router 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 authentication provider of the answering router is improperly configured.

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

See also: Use RADIUS authentication

Cause: The answering router cannot access Active Directory.

Solution: For an answering router that is a member server in a Windows 2000 mixed domain or a Windows 2000 native domain that is configured for the Windows authentication provider, 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 answering router 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 answering router computer to (or remove the answering router 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 answering router computer.
For a Windows 2000 native domain, the answering router has joined the domain.

Cause: An answering router running Windows NT 4.0 with the Routing and Remote Access Service (RRAS) cannot validate connection requests.

Solution: If calling routers are dialing in to a answering router running Windows NT 4.0 with RRAS 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 answering router 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 answering router from the Internet.

Solution: Due to the PPTP and L2TP/IPSec packet filtering that is configured on the Internet interface of the answering router, Internet Control Message Protocol (ICMP) packets used by the ping command are filtered out. To enable ping capability on the answering router, 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

Unable to send and receive data.

Cause: The appropriate demand-dial interface has not been added to the protocol being routed.

Solution: Add the appropriate demand-dial interface to the protocol being routed.

See also: Add a routing interface

Cause: There are no routes on both sides of the router-to-router VPN connection that support the two-way exchange of traffic.

Solution: 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.

Cause: A two-way initiated, router-to-router VPN connection is being interpreted by the answering router as a remote access connection.

Solution: If the user name in the credentials of the calling router appears under Dial-In Clients in Routing and Remote Access, the answering router interpreted the calling router as a remote access client. Verify that the user name in the credentials of the calling router matches the name of a demand-dial interface on the answering router.

If the incoming caller is a router, the port on which the call was received shows a status of Active and the corresponding demand-dial interface is in a Connected state.

Cause: Packet filters on the demand-dial interfaces of the calling router and answering router are preventing the flow of traffic.

Solution: 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.

You can configure each demand-dial interface with IP input and output filters to control the exact nature of TCP/IP traffic that is allowed into and out of the demand-dial interface.

See also: Manage Packet Filters

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 on troubleshooting demand-dial connections, see Troubleshooting demand-dial routing.

Freigeben über

Troubleshooting router-to-router VPNs