Intermittent ping timeout, VPN, 200r - 100

[bmullan]

Hi, I've setup VPNs between a 200r and a two 100s. The manual recommends administering each remote 100 using the VPN connection, but this barely works. When I ping the remote 100's internal IP address more than half the pings are timing out. Pinging workstations on the remote subnet shows about 1 in 6 pings timing out. However pinging each 100's external IP address is 100% successful.
I've set the Keep Alive indicator on the 200r to google and logging on all devices is set to System only.
I've got another 3 100s to install at other sites so I'm more than a bit concerned about this behaviour.
Anyone got any ideas? TIA

 

[apeasecpc]

Try turning on some of the other logging and see if there are any error messages explaining the problem.

What kind and speed of internet connection do you have at both ends?

Do you have fixed IP addresses or are you using Dynamic DNS?

What kind of network is on the remote subnet?

 

[bmullan]

Apeasecp, thanks for the reply. I've changed the log type to include everything except Attack. Below is what the log now shows - as you can see I now have installed 3 100s all of which exhibit the same intermittent ping problem:

08/02/2004 15:29:00.89 System started
08/02/2004 15:29:10.89 VPNLarn - Initiating IKE Main Mode
08/02/2004 15:29:10.89 VPNLarn - STATE_MAIN_I1: initiate
08/02/2004 15:29:10.89 VPNDown - Initiating IKE Main Mode
08/02/2004 15:29:10.89 VPNDown - STATE_MAIN_I1: initiate
08/02/2004 15:29:10.89 VPNLima - Initiating IKE Main Mode
08/02/2004 15:29:10.89 VPNLima - STATE_MAIN_I1: initiate
08/02/2004 15:29:11.99 VPNLarn - STATE_MAIN_I2: from STATE_MAIN_I1; sent MI2, expecting MR2
08/02/2004 15:29:13.04 VPNDown - STATE_MAIN_I2: from STATE_MAIN_I1; sent MI2, expecting MR2
08/02/2004 15:29:14.09 VPNLima - STATE_MAIN_I2: from STATE_MAIN_I1; sent MI2, expecting MR2
08/02/2004 15:29:16.29 VPNLarn - STATE_MAIN_I3: from STATE_MAIN_I2; sent MI3, expecting MR3
08/02/2004 15:29:16.29 - ERR:Main Mode message is part of an unknown exchange
08/02/2004 15:29:17.84 VPNDown - STATE_MAIN_I3: from STATE_MAIN_I2; sent MI3, expecting MR3
08/02/2004 15:29:17.84 - ERR:Main Mode message is part of an unknown exchange
08/02/2004 15:29:17.84 VPNLarn - STATE_MAIN_I4 ISAKMP SA established
08/02/2004 15:29:17.84 VPNLarn - Doing Quick Mode with 84.92.11.130 "VPNLarn"
08/02/2004 15:29:17.84 VPNLarn - initiating Quick Mode
08/02/2004 15:29:18.89 VPNLarn - STATE_QUICK_I1: initiate
08/02/2004 15:29:20.49 VPNLima - STATE_MAIN_I3: from STATE_MAIN_I2; sent MI3, expecting MR3
08/02/2004 15:29:20.49 VPNDown - STATE_MAIN_I4 ISAKMP SA established
08/02/2004 15:29:20.49 VPNDown - Doing Quick Mode with 84.92.15.130 "VPNDown"
08/02/2004 15:29:20.49 VPNDown - initiating Quick Mode
08/02/2004 15:29:21.54 VPNDown - STATE_QUICK_I1: initiate
08/02/2004 15:29:21.54 VPNLima - STATE_MAIN_I4 ISAKMP SA established
08/02/2004 15:29:21.54 VPNLima - Doing Quick Mode with 84.92.11.126 "VPNLima"
08/02/2004 15:29:21.54 VPNLima - initiating Quick Mode
08/02/2004 15:29:22.64 VPNLima - STATE_QUICK_I1: initiate
08/02/2004 15:29:24.19 VPNLarn - STATE_QUICK_I2 sent QI2, IPsec SA established
08/02/2004 15:29:25.94 VPNDown - STATE_QUICK_I2 sent QI2, IPsec SA established
08/02/2004 15:29:27.54 VPNLima - STATE_QUICK_I2 sent QI2, IPsec SA established

Here is a summary from one of my ping tests:
ping stats - sent 19, received 7, lost 12, average round trip 77ms

Connection at 200R is 2Mb ADSL
Connection at each 100 is 1Mb ADSL

All IP addresses are fixed

Remote networks are 5 - 10 computers addressed 192.168.40/50/60.0 mask 255.255.255.0

TIA for your help.

 

[apeasecpc]

What are the timeout settings for your VPN?

In you settings are you referencing the remote end by IP address or by name?

What happens when you attempt the access the manager remotely?

Home many hops does a traceroute take to your destination?

 

[bmullan]

The remote gateway addresses are referenced by IP address as are the remote subnets.

Remote access to the manager is nearly unusable. Remotely pinging the exterior address of the 100 gives 100% replies. Remotely pinging the interior address (& hence the manager) gives on average 55% replies. Browsing to the remote manager takes 3-4 attempts to load a screen.

1 hop.

 

[apeasecpc]

So you have just one hop from the 200R's local subnet to any of the 100's remote subnets?

Are you using both wan ports on the 200R, or just one?

Do you have global tunnel enabled?

Do you have any kind of router behind the 200R, or is it doing all of the routing?

Are you using any access filters or virtual servers?

Do the remote subnets show in the 200R's routing table?

What firmware versions are on your appliances?

 

[bmullan]

Oops - 2 hops

Both WAN ports of the 200R are connected, to different ISPs, but all VPN traffic is via WAN2 because the remote 100s all connect to the same ISP as WAN2. (but see below)

No global tunnels.

An ISDN router, which is about to be made redundant by the VPNs, is still in place. Even when it's turned off the ping problem continues.

No access filters or virtual servers.

Remote subnets don't show in the 200R's routing table.

200R - Firmware Version V1 Rel 62
100 - Firmware Version V1 Rel 62

Thinking about this yesterday I configured one of the remote 100's to connect to WAN1 on the 200R i.e. using the other ISP ADSL line. Immediately I could see a significant improvement in the ping responses. Now sending 100 pings I'm getting 100% replies from a server on the subnet! The same exercise to a server on another 100 subnet results in a 24% loss - this connection uses WAN2 on the 200R. WAN1 uses a different ISP from WAN2 and also connects with a different brand of ADSL modem. I've talked to the WAN2 ISP and they could offer no help. As all the 100s and WAN2 of the 200R are using the same brand of ADSL modem I've borrowed 2 different ADSL modems to try on WAN2 of the 200R and one of the 100s. It'll may be a few days before I can test these but I'll let you know.
In the meantime thanks for your suggestions and help

 

[apeasecpc]

The problem does sound like a routing delay by the ISP that is timing out before the packets reach their destonation.

On the other hand, Symantec lists a number of VPN issues when using both WAN ports. Symantec claims to have fixed these in the firmware version you have, but their claims aren't always true, for example the latest firmware still has dropped connection problems that were allegedly fixed several releases ago.

Try swapping your WAN1 and WAN2 connections and see if the problems with the currently used ISP still happen when it is on WAN1.