Troubleshooting Remote Access VPNs IV

Cause`: - Cannot connect to the VPN server over the Internet using the Ping.exe utility.

Solution: - Because of the PPTP and L2TP over 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 turn on the VPN server to respond to ICMP (ping) packets, add an input filter and an output filter that permit traffic for IP protocol 1 (ICMP traffic).

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

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. 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 turn on 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. See Windows Server 2003 online Help for more information about how to add an IP routing protocol, how to add a static route, and how to perform auto-static updates.

Cause: - A two-way initiated the answering router as a remote access connection is interpreting router-to-router VPN 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 may interpret 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 and IPX input and output filters to control the exact nature of TCP/IP and IPX traffic that is permitted into and out of the demand-dial interface.

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 permitted on the VPN connection. Verify that the profile TCP/IP packet filters are not preventing the flow of traffic.