Die Firewall beginnt, einen ZUVOR zulässigen UDP-Datenverkehr zu löschen, auch wenn keine Änderungen an der Firewallkonfiguration oder an einer beliebigen Stelle im Netzwerk vorgenommen wurden.

69367

Created On 01/12/21 16:26 PM - Last Modified 02/22/24 09:32 AM

Symptom

Es kann vorkommen, wie PAN Firewall beginnt, einen UDP-Datenverkehr zu blockieren (d. h. ESP, DHCP, DNS, NTP), der zuvor zugelassen wurde.
Dies ist möglich, auch wenn keine Änderungen an der Firewall-Konfiguration oder irgendwo in der Umgebung vorgenommen wurden.

Environment

Alle Hardware- und VM-Plattformen
Alle PanOS-Versionen

Cause

Pan-Firewall erstellt und verwendet Sitzungsdatensätze während der Verarbeitung des datenverkehrsdurchlaufenden Datenverkehrs. Der folgende Artikel kann überprüft werden, wie Firewall den Datenverkehr verarbeitet. https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClVHCA0

Die Sitzungen können in verschiedenen Zuständen stattfinden. Der folgende Artikel kann bezüglich der Beschreibung der Sitzungszustände überprüft werden.
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000Clk9CAC

Wenn sich eine Sitzung im Status "Verwerfen" befindet, wird jedes Paket, das von der Firewall empfangen wird und auf diese Sitzung trifft, immer gelöscht.

Eine Sitzung kann in bestimmten Szenarien im Status "Verwerfen" stecken bleiben. Die Szenarien können, aber nicht beschränkt auf die folgenden:

Beispielszenario 1: Ein IPSEC-Tunnel schlägt nach einer IPSec-Konfigurationsänderung oder einem Systemneustart fehl
– In diesem Szenario sendet der andere IPSec-Peer möglicherweise weiterhin SEP-Pakete während des Systemneustarts.
- Gemäß den Richtlinien/Konfigurationen wird der Datenverkehr von der Firewall gelöscht und eine ursprünglich erstellte Sitzung wechselt in den Status "Verwerfen".
- Alle folgenden Pakete treffen die gleiche Sitzung und die Sitzung bleibt und bleibt im Status "Verwerfen".
- Eine neue Phase2 wird nie etabliert, da alle Nachrichten die gleiche Sitzung treffen und gelöscht werden.

Beispielszenario 2: Ein weitergeleiteter DHCP-Datenverkehr schlägt plötzlich fehl
- In diesem Szenario spielt die Hardware-Entladung, die wir in den meisten unserer Hardwaremodelle haben, eine Rolle.
- Eine vorhandene Sitzung im Zusammenhang mit dem DHCP-Datenverkehr kann aufgrund unserer Entladelogik eine Zeitaufze auf DP haben. Bitte lesen Sie den folgenden Artikel, wie und wann der Netzwerkprozessor die Sitzungszeitgeber auf DP aktualisiert.
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000Cm8cCAC
- Wenn der DHCP-Datenverkehr von Zone A in Zone B zugelassen ist und die Sitzung vor der Antwort von Zone B in Zone A eine Zeitabfolge von Zeit für zeitnimmt, wird diese Antwortnachricht gelöscht, und es wird eine Sitzung im Status "Verwerfen" angezeigt.
- Die folgenden Pakete werden diese Sitzung treffen und werden gelöscht.

Resolution

Um die Drops auf der Firewall zu beheben, können einige Aktionen ausgeführt werden:

Die Sitzungen im Status "Verwerfen" können mit den folgenden Befehlen aufgelistet und entfernt werden. Es ist wichtig, nach den Sitzungen für jede Richtung zu suchen.

> alle Filterquellen [IP-Adresse 1] Ziel [IP-Adresse 2] status verwerfen
> Zeigen Sitzung alle Filterquelle [IP-Adresse 2] Ziel [IP-Adresse 1] Status verwerfen > zeigen Sitzung alle
Filterstatus verwerfen
> löschen Sitzungs-ID [Sitzungs-ID]

In Szenarien, in denen das Sitzungstimeout ebenfalls affektiv ist, kann der Sitzungstimeoutwert für die erforderlichen App-IDs erhöht werden. Dies kann durch Ändern des UDP-Timeoutwerts unter Device Tab > Applications > [Concerned App-id] > UDP Timeout (Second) auf der WebUI erfolgen.

Wenn das Ändern des Sitzungstimeouts nicht helfen würde, könnte eine andere Option darin bestehen, eine Zulässigsregel für die umgekehrte Richtung zu definieren. (Bezogen auf das Beispielszenario 2, eine Zulässigenregel von Zone B bis Zone A) Der Rücklaufverkehr löst also eine brandneue Sitzung aus und wird nicht gelöscht.

Additional Information