Website-to-Site IPSec überMäßiges Rekeying auf nur einem Tunnel auf System Protokollen

125295

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

Resolution

Symptom

Es gibt Website-to-Site IPSec übermäßiges Rekeying auf einem Tunnel auf Systemprotokollen, während andere Tunnel nicht duplizieren dieses Verhalten.

Ursache

Es gibt drei mögliche Ursachen für dieses Thema:

Die Tunnel Überwachung ist aktiviert, während keine IP-Adresse auf dem Tunnel konfiguriert ist. Tunnelüberwachung nutzen Sie die Tunnel-IP-Adresse als Quelle für Tunnelüberwachung ICMP-Pakete.
Die TunnelÜberwachung ist aktiviert, solange keine entsprechende Proxy-ID für die Überwachung der Tunnel-IP-Adresse und der IP-Adresse vorhanden ist. Für die ZugriffsKontrollliste (ACL), die IPSec VPN basiert, ist ein Proxy-ID-Paar für die entsprechende Tunnel-IP-Adresse und die überwachte IP-Adresse erforderlich.
Hinweis: Es besteht keine Notwendigkeit für eine Proxy-ID für den Tunnel, der die IP-Adresse des Tunnels zwischen der Palo Alto Networks-Firewall überwacht.
Es ist möglich, dass dies kein Problem ist und dass Palo Alto Networks Firewall nur den normalen Rekey für mehrere Tunnel protokolliert. Dies gilt, wenn das Rekey-Intervall sehr kurz ist und es mehrere Proxy-ID-Paare gibt.

Um auf den Palo Alto Networks Firewall zu überprüfen, verwenden Sie die folgenden CLI-Befehle:

ÜberPrüfen Sie IKE Debug Level
> Debug IKE Global Show
Ändern Sie IKE Debug Level, um zu Debuggen
> Debug IKE Global auf Debug
Um IKE-Nachrichten zu beobachten
> Schwanz folgen ja MP-Log ikemgr. log
Rückgabe des Debug-Levels auf normal nach der Fehlerbehebung
> Debug IKE Global auf Normal

Details

Für Ausgabe 1: Konfigurieren Sie eine zugewiesene IP-Adresse im IPSec-Tunnel oder deaktivieren Sie die Tunnelüberwachung, falls nicht erforderlich.

Für Ausgabe 2: die Proxy-ID für die entsprechende Tunnel-IP-Adresse und die überwachte IP-Adresse konfigurieren oder die Tunnelüberwachung deaktivieren, wenn Sie nicht benötigt wird.

Für Ausgabe 3: ÜberPrüfen Sie Rekey-Intervall auf IKE Phase1 und IKE Phase2.

Verwenden Sie den folgenden CLI-Befehl, um VPN-Gateway anzuzeigen:

> VPN Gateway anzeigen

GwID Name Peer-Adresse/ID-lokale Adresse/ID-Protokoll-Vorschläge

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

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>

> VPN-Tunnel anzeigen

TnID Name (Gateway) lokaler Proxy IP PTL: Port Remote Proxy IP PTL: Port-Vorschläge

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

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>

Wenn man die folgenden Protokolle beobachtet, zeigt sich, dass die SPI-Taste alle 3 Minuten + rekeyed wird. Da es mehrere Proxy-ID-Paare auf dem TuS-1-Tunnel gibt, gibt es häufige rekeys wegen der Einstellungen Lebensdauer 5min. Die Protokolle scheinen aufeinander folgende rekeys zu sein und stammen eigentlich aus verschiedenen Tunneln, die innerhalb des 5-Minuten-Intervalls Rekeying sind. Alle Multiple Proxy-ID wird 5 Minuten Rekey und aus der Logs-Perspektive scheint zu viel zu sein.

Um zu überprüfen, wählen Sie die SPI aus dem Tunnel, die häufige Rekey, verwenden Sie Match per PEER-VPN-IP-Adresse.

> Log-System Richtung gleich hinten anzeigen | Match 1.1.1.1

2014/02/24 13:43:04 Info VPN TUN-1 IKE-Neg 0 IKE Phase-2 Verhandlung wird als Initiator, Quick Mode gestartet. Initiiert SA: 2.2.2.2 [500]-1.1.1.1 [500] Message ID: 0x6F845F96.
2014/02/24 13:43:04 Info VPN tun-1 IKE-Neg 0 IKE Phase-2 Verhandlung ist als Initiator, Quick Mode, gelungen. Etablierte SA: 2.2.2.2 [500]-1.1.1.1 [500] Message ID: 0x6F845F96, SPI: 0xDBE7425F/0xC3D97F6B.

2014/02/24 13:43:04 Info VPN TUN-1 IPSec-k 0 IPSec Key installiert. Installiert SA: 2.2.2.2 [500]-1.1.1.1 [500] SPI: 0xDBE7425F/0xC3D97F6B Lifetime 300 sec Lebensgröße 128000 KB.

Mit folgendem Befehl wählen Sie nur Protokolle, die mit dem SPI in Zusammenhang stehen:

> grep Pattern 0xDBE7425F MP-Log ikemgr. log

Etablierte SA: 2.2.2.2 [500]-1.1.1.1 [500] Message ID: 0Xb6df139 c, 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 Lebenszeit Soft Time = 300 Bytes = 0

Installiert SA: 2.2.2.2 [500]-1.1.1.1 [500] SPI: 0xdbe7425f/0Xc3d97f6b Lifetime 300 sec Lebensgröße unbegrenzt

Gelöscht 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]: empfangene PFKEY_DELETE SEQ = 0 Satype = ESP SPI = 0xDBE7425F

Start: 13:43:04

Ende: 13:46:40

Lösung

Ungefähr, Rekey alle 3 Minuten + für jeden Tunnel wird das schaffen, was zu sein scheint, dass übermäßiger Rekey normal ist. Erhöhen Sie den Rekey-Wert, um die Anforderungen auszugleichen oder anzupassen.