IPSec de site à site une régénération excessive sur un seul tunnel sur les journaux système

125267

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

Resolution

Symptôme

Il y a une réincrustation excessive de site à site IPSec sur un tunnel sur les journaux système, tandis que d'autres tunnels ne dupliquent pas ce comportement.

Cause

Il y a trois causes possibles à ce problème:

La surveillance du tunnel est activée alors qu'aucune adresse IP n'est configurée sur le tunnel. La surveillance du tunnel utilise l'adresse IP du tunnel comme source de paquets ICMP de surveillance de tunnel.
La surveillance du tunnel est activée alors qu'il n'y a pas d'ID proxy correspondant pour l'adresse IP du tunnel et l'adresse IP surveillée. Pour le VPN IPSec basé sur la liste de contrôle d'accès (ACL), la paire proxy-ID de l'adresse IP du tunnel correspondante et l'adresse IP surveillée sont nécessaires.
Note: il n'y a pas besoin de proxy-ID pour tunnel à tunnel adresse IP de surveillance tunnel entre Palo Alto Networks Firewall.
Il est possible que ce n'est pas un problème et que le pare-feu Palo Alto Networks est juste l'enregistrement recomposition normale pour les tunnels multiples. Cela est vrai si recomposition intervalle est très court et il existe plusieurs paires proxy-ID.

Pour vérifier sur le pare-feu de Palo Alto Networks, utilisez les commandes CLI suivantes:

Vérifier IKE Debug Level
> Debug IKE global Show
Modifier le niveau de débogage IKE pour déboguer
> Debug IKE global sur Debug
Pour observer les messages IKE
> queue suivre Oui MP-log ikemgr. log
Retourner le niveau de débogage à normal après dépannage
> Debug IKE global sur normal

Détails

Pour le numéro 1: configurez une adresse IP allouée sur le tunnel IPSec ou désactivez la surveillance du tunnel si elle n'est pas nécessaire.

Pour le numéro 2: configurez le proxy-ID pour l'adresse IP du tunnel correspondante et l'adresse IP surveillée, ou désactivez la surveillance du tunnel si elle n'est pas nécessaire.

Pour le numéro 3: Vérifiez l'intervalle recomposition sur IKE phase1 et IKE phase2.

Utilisez la commande CLI suivante pour afficher la passerelle VPN:

> Show VPN Gateway

Nom GwID adresse d'homologue/ID adresse locale/propositions de protocole d'id

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

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>

> Show VPN Tunnel

TnID Name (Gateway) local proxy IP PTL: port Remote proxy IP PTL: propositions port

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

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>

L'observation des journaux suivants montre que la clé SPI est retapée chaque 3mins +. Comme il existe plusieurs paires proxy-ID sur le tunnel TUN-1, il ya des retouches fréquentes en raison de la durée de vie des paramètres 5mins. Les journaux semblent être des retouches consécutives et proviennent en fait de différents tunnels de régénération dans l'intervalle 5mins. Tous les proxy-ID multiples seront recomposition 5mins et de la perspective logs semble être trop nombreux.

Pour vérifier, choisissez le SPI dans le tunnel qui présente des recomposition fréquentes, utilisez match by Peer-VPN-IP-address.

> Show log direction du système égal en arrière | allumette 1.1.1.1

2014/02/24 13:43:04 info VPN TUN-1 IKE-NEG 0 la négociation de phase-2 de IKE est commencée en tant qu'initiateur, mode rapide. Initié SA: 2.2.2.2 [500]-1.1.1.1 [500] ID de message: 0x6F845F96.
2014/02/24 13:43:04 info VPN TUN-1 IKE-NEG 0 IKE phase-2 la négociation est réussie en tant qu'initiateur, mode rapide. Établi SA: 2.2.2.2 [500]-1.1.1.1 [500] ID de message: 0x6F845F96, SPI: 0xDBE7425F/0xC3D97F6B.

2014/02/24 13:43:04 info VPN TUN-1 IPSec-k 0 clé IPSec installée. Installé SA: 2.2.2.2 [500]-1.1.1.1 [500] SPI: 0xDBE7425F/0xC3D97F6B Lifetime 300 sec LifeSize 128000 KB.

À l'Aide de la commande suivante, choisissez uniquement les journaux liés au SPI:

> grep pattern 0xDBE7425F MP-log ikemgr. log

Établi SA: 2.2.2.2 [500]-1.1.1.1 [500] ID de message: 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 durée de vie du soft = 300 octets = 0 temps dur = 300 octets = 0

Installé sa: 2.2.2.2 [500]-1.1.1.1 [500] SPI: 0xDBE7425F/0xC3D97F6B Lifetime 300 sec LifeSize Unlimited

Deleted 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]: reçu PFKEY_DELETE seq = 0 satype = ESP SPI = 0xDBE7425F

Début: 13:43:04

Fin: 13:46:40

Résolution

Approximativement, recomposition toutes les 3 mins + pour chaque tunnel créera ce qui semble être que la recomposition excessive est normale. Augmentez la valeur recomposition pour équilibrer ou répondre aux exigences.