VPN Router 2700: Many tunnels were down because of misconfiguration of tunnels on VPNR and remote end devices.


Doc ID    SOLN200524
Version:    1.0
Status:    Published
Published date:    25 Apr 2012
Author:   
schalla
 

Details

Erratic behaviour with tunnel establishment between the 2700 and 1010 or 1100 models. There are 1000 tunnels configured correctly, but not all tunnels get established (currently only 400 are established) and sometimes tunnels that get established drop and dont establish again even after a tunnel reset. The other end (1010 and 1100 models) also have tunnels to other devices, which have no issues.
Actual configured tunnels were 1000 on secondary VPNR. But there are only 400 active tunnels appearing. When we gone through the configuration found some misconfigurations of tunnels on secondary VPNR.

Problem Clarification

It is actually Hub-spoke model topology at customer site. Secondary VPNR has 400 tunnels up instead of 1000 beacuase of configuration issue. Many tunnels were down because of misconfiguration of tunnels on VPNR and remote end devices.

Cause

Some tunnels are not configured propoerly. It was misconfigured.
Details are below.
-Local gateways were not present for some tunnels configuration

-Some of the tunnels state was in disable insteadd of enable

-Both side the preshared key mismatch

- Remote end gateway IP addresses wrongly mentioned

-No encryption types are enabled for the account in question

-The requested authentication method is not enabled

-Both sides supports static routing, however the local and remote network definitions of the two sides do not match

-The encryption types proposed by branch office xxx do not match the encryption types configured locally

-The Perfect Forward Secrecy (PFS) setting of the two sides do not match. The local settings require PFS but you did not enable it for branch office xxx

Solution

Major Findings are: Because of Misconfiguration of tunnels the below errors found in event logs.

Error: ISAKMP [13] No proposal chosen in message from xxx (a.b.c.d)
Action:-Check the encryption types on both sides to make sure they match. If necessary, reconfigure the encryption on one system
-Make sure the PFS settings on both sides match. Either enable PFS on the remote side, or disable PFS locally

ISAKMP [13] Error notification (Invalid ID information) received from xxx (a.b.c.d)
Action:Configure both sides to use the same routing type and Configure both sides to use the same local and remote network definitions.

ISAKMP [13] Error notification (Authentication failure) received from xxx (a.b.c.d)
Action: -Both sides should be same Pre-shared keys.
-Enable the desired encryption types
-Enable all required authentication types. Make sure the unneeded types are disabled.

Suggested to enter proper remote end IP address and local gateways IP addresses.
Suggested to enable the tunnels status instead of disable.

Requested them to cross check the Authentications on both sides.

By making all these above changes, we were managed to improve the number of tunnels.


Avaya -- Proprietary. Use pursuant to the terms of your signed agreement or Avaya policy