Recodificación excesiva de IPSec de sitio a sitio en un solo túnel en los registros del sistema

125265

Created On 09/25/18 19:50 PM - Last Modified 05/31/23 21:39 PM

Resolution

Síntoma

Hay una reintroducción excesiva de IPSec de sitio a sitio en un túnel en los registros del sistema, mientras que otros túneles no están duplicando este comportamiento.

Causa

Hay tres causas posibles para este problema:

La supervisión del túnel está activada mientras no hay ninguna dirección IP configurada en el túnel. Supervisión del túnel utilice la dirección IP del túnel como origen de los paquetes ICMP de supervisión de túnel.
La supervisión del túnel está activada mientras no existe un identificador de proxy correspondiente para la dirección IP del túnel y la dirección IP que se está monitoreando. Para la lista de control de acceso (ACL) VPN basada en IPsec, el par de proxy-ID para la dirección IP del túnel correspondiente y la dirección IP que se está monitoreando es necesario.
Nota: no hay necesidad de proxy-ID para túnel a túnel dirección IP supervisión túnel entre Palo Alto Networks Firewall.
Es posible que esto no es un problema y que Palo Alto Networks Firewall es sólo registro normal reintroducir para múltiples túneles. Esto es cierto si reintroducir intervalo es muy corto y hay varios pares de proxy-ID.

Para verificar en el Firewall de Palo Alto Networks use los siguientes comandos de CLI:

Comprobar IKE Debug LEVEL
> Debug IKE global show
Cambiar el nivel de depuración IKE para depurar
> Debug IKE global en Debug
Para observar los mensajes IKE
> cola seguir sí MP-log ikemgr. log
Devolver el nivel de depuración a normal después de la solución de problemas
> Debug IKE global on normal

Detalles

Para el número 1: configure una dirección IP asignada en el túnel IPSec o deshabilite la supervisión del túnel si no es necesario.

Para el número 2: configure el proxy-ID para la dirección IP del túnel correspondiente y la dirección IP que se está monitoreando, o deshabilite la supervisión del túnel si no es necesario.

Para el número 3: Compruebe el intervalo de reintroducir en IKE Phase1 y IKE Phase2.

Utilice el siguiente comando CLI para mostrar la puerta de enlace VPN:

> Mostrar Gateway VPN

GwID nombre de interlocutor/ID dirección local/protocolo de identificación propuestas

-------- ---- --------------- ---------------- -------- ---------

10 GW-1 1.1.1.1 (ipaddr: 1.1.1.1) 2.2.2.2 (ipaddr: 2.2.2.2) Main [PSK] [DH2] [AES256] [SHA1] 300-sec <== rekey too short rekey="" too=""></== rekey too short>

> Mostrar túnel VPN

TnID Name (Gateway) local proxy IP PTL: Puerto proxy remoto IP PTL: propuestas de Puerto

---- ------------- -------------- -------- --------------- -------- ---------

100 TUN-1: ProxyPair1 (GW-1) 192.168.1.0/24 0:0 192.168.31.0/24 0:0 ESP Tunl [DH2] [AES256] [SHA1] 300-sec <== rekey too short rekey="" too=""></== rekey too short>

100 TUN-1: ProxyPair2 (GW-1) 192.168.2.0/24 0:0 192.168.32.0/24 0:0 ESP Tunl [DH2] [AES256] [SHA1] 300-sec <== rekey too short rekey="" too=""></== rekey too short>

100 TUN-1: ProxyPair3 (GW-1) 192.168.3.0/24 0:0 192.168.33.0/24 0:0 ESP Tunl [DH2] [AES256] [SHA1] 300-sec <== rekey too short rekey="" too=""></== rekey too short>

100 TUN-1: ProxyPair24 (GW-1) 192.168.24.0/24 0:0 192.168.54.0/24 0:0 ESP Tunl [DH2] [AES256] [SHA1] 300-sec <== rekey too short rekey="" too=""></== rekey too short>

100 TUN-1: ProxyPair25 (GW-1) 192.168.25.0/24 0:0 192.168.55.0/24 0:0 ESP Tunl [DH2] [AES256] [SHA1] 300-sec <== rekey too short rekey="" too=""></== rekey too short>

Observando los siguientes registros se muestra que la clave SPI está siendo retecleada cada 3mins +. Dado que hay varios pares de proxy-ID en el túnel TUN-1, hay reclaves frecuentes debido a la configuración de Lifetime minutos. Los registros parecen ser reclaves consecutivas y en realidad son de diferentes túneles de recodificación dentro del intervalo minutos. Todos los múltiples proxy-ID se reintroducir minutos y desde la perspectiva logs parece ser demasiados.

Para verificar, escoja el SPI del túnel que exhibe reintroducir frecuente, utilice Match por peer-VPN-IP-address.

> Mostrar la dirección del sistema log igual al revés | Match 1.1.1.1

2014/02/24 13:43:04 info VPN Tun-1 IKE-NEG 0 IKE fase-2 la negociación se inicia como iniciador, modo rápido. Iniciado SA: 2.2.2.2 [500]-1.1.1.1 [500] ID de mensaje: 0x6F845F96.
2014/02/24 13:43:04 info VPN Tun-1 IKE-NEG 0 IKE fase-2 la negociación se ha tenido éxito como iniciador, modo rápido. Establecido SA: 2.2.2.2 [500]-1.1.1.1 [500] identificación del mensaje: 0x6F845F96, SPI: 0xDBE7425F/0xC3D97F6B.

2014/02/24 13:43:04 info VPN Tun-1 IPSec-k 0 IPSec Key installed. Instalado SA: 2.2.2.2 [500]-1.1.1.1 [500] SPI: 0xDBE7425F/0xC3D97F6B Lifetime 300 sec LifeSize 128000 KB.

Utilizando el siguiente comando, elija sólo los registros relacionados con el SPI:

> grep pattern 0xDBE7425F MP-log ikemgr. log

Establecido SA: 2.2.2.2 [500]-1.1.1.1 [500] identificación del mensaje: 0xB6DF139C, SPI: 0xDBE7425F/0xC3D97F6B

2014-02-24 13:43:04 [info]: ike_pfkey. c:339: sadb_log_add (): SADB_UPDATE ul_proto = 255 SRC = 1.1.1.1 [500] DST = 2.2.2.2 [500] satype = ESP Samode = Tunl SPI = 0xDBE7425F AuthType = SHA1 enctype = AES256 Lifetime tiempo suave = 300 bytes = 0 tiempo duro = 300 bytes = 0

Instalado SA: 2.2.2.2 [500]-1.1.1.1 [500] SPI: 0xDBE7425F/0xC3D97F6B Lifetime 300 sec LifeSize ilimitado

Eliminado SA: 2.2.2.2 [500]-1.1.1.1 [500] SPI: 0xDBE7425F/0xC3D97F6B

2014-02-24 13:46:40 [INFO]: SADB_DELETE ul_proto = 0 src = 2.2.2.2 [500] DST = 1.1.1.1 [500] satype = ESP SPI = 0xDBE7425F

2014-02-24 13:46:40 [info]: Received PFKEY_DELETE SEQ = 0 satype = ESP SPI = 0xDBE7425F

Comienzo: 13:43:04

Final: 13:46:40

Resolución

Aproximadamente, reintroducir cada 3 mins + para cada túnel creará lo que parece ser que la reintroducir excesiva es normal. Aumente el valor de reintroducir a los requisitos del equilibrio o del juego.