Upgraded to 6.5R3.1 , now users complain of drops

[Jickfoo_]

Just to keep this case updated in hopes of helping someone else in the future:

- I've tried allowing access to the local subnet. The theory behind this is with split-tunneling enabled we rule out the Route Monior. This step did not work.

- I've put all the problem users into a group which uses oNCP only. I'm waiting to see if this has any positive benefits.

I've also added the below robot in hopes he can help my situation.

Thanks,

Justin

[cgalla_]

I had users getting same error messages (plus a few more) back in January in their event logs on their corporate XP SP3 laptops. They were also experiencing dropping with Network Connect and also randomly not being able to connect to Outlook and other resources. The problem for us was when they connected in through VPN to the network, Kerberos was using default UDP through the VPN tunnel. Packets were fragmenting and UDP could not reassemble packets. Packets were dropped, so hit or miss at connectivity to some of the resources. We pushed out a registry change to the laptops to force Kerberos to use TCP and our problems vanished. Here is more info http://support.microsoft.com/kb/244474 - Don't know if this applies to you, but thought I would put it out there.

We are running 6.5R1 on an SA4000

[Jickfoo_]

Thanks for your reply.

I am finding that switching users from ESP to oNCP is resolving the problem.

That doesnt help me though as I dont want to switch everyone to NCP.

Did you ever try this ?

Thanks,

Justin

[cgalla_]

No we have not.

[Jickfoo_]

The timeouts are coming almost exactly after 2 hours of connectivity.

Under Configuration, NCP, the Idle Timeout Connection is for 2 hours. Also in the logs there are a bunch of keep-alive messages before the tunnel crashes. I've changed this to 480 and am keeping my fingers crossed.

[Jickfoo_ · Accepted solution]

This worked. I told my tech and he was able to locate a desciption of a similar problem somewhere. The problem is our IPSEC keys are good for 8-hours. We do this for a variety of reasons but will probably lower it now. Control-data now flows over NCP (SSL). This must have changed somewhere between versions 6.0R7 and and 6.5R3.1. Well, this control data is limited to the timeout you set under Configuration, NCP. (I dont know why. I personally dont think control-data should ever time-out until the session is closed.) In short The NCP Timeout value has to be greater then the key exchange time. I see this as a bug.

Whatever, it's fixed.

[JQ_]

This only applies to ESP transport right?

Also, is this value for the key exchange timeout under Network COnnection Connection Profile, connection Settings?

If I'm running NCP, this shouldn't matter right?

[zanyterp_]

the control channel has always been over the NCP tunnel.

yes, the key lifetime is only for ESP connections; if you are using the NCP/SSL connection, there is no separate key