Le pare-feu commence à laisser tomber un trafic UDP qui a été autorisé plus tôt, même il n’y a pas de modifications apportées dans le pare-feu config ou n’importe où dans le réseau

69379

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

Symptom

Il peut y avoir une situation comme pan pare-feu commence à bloquer un trafic UDP (c.-à-ESP, DHCP, DNS, NTP) qui avait été autorisé plus tôt.
Cela est possible même il n’y a eu aucune modification apportée dans le config pare-feu ou n’importe où dans l’environnement.

Environment

Toutes les plateformes matérielles et VM
Toutes les versions de PanOS

Cause

Le pare-feu PAN crée et utilise des enregistrements de session tout en traitant le trafic qui passe. L’article ci-dessous peut être vérifié concernant la façon dont le pare-feu gère le trafic. https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClVHCA0

Les sessions peuvent être dans divers états. L’article ci-dessous peut être vérifié concernant la description des états de session.
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000Clk9CAC

Si une session est en état de « rejet », tout paquet reçu par le pare-feu et frappé cette session est toujours supprimé.

Une session peut rester dans l’état « Rejet » dans certains scénarios. Les scénarios peuvent être mais ne se limitent pas aux éléments suivants :

Exemple Scénario 1 : Un tunnel IPSEC échoue après un changement de config IPSec ou un redémarrage du système - Dans ce
scénario, l’autre pair IPSec peut continuer à envoyer des paquets SEP pendant le redémarrage du système.
- Par les stratégies / config en place le trafic est supprimé par le pare-feu et une session qui a été initialement créé va dans l’état « Jeter ».
- Tous les paquets suivants ont atteint la même session et la session reste et rester coincé dans l’état « Discard ».
- Une nouvelle phase2 ne s’établit jamais parce que tous les messages frappent la même session et sont supprimés.

Exemple Scénario 2 : Un trafic DHCP relayé commence à échouer tout d’un coup
- Dans ce scénario de déchargement matériel que nous avons dans la plupart de nos modèles matériels joue un rôle.
- Une session existante liée au trafic DHCP peut s’éteindre sur DP en raison de notre logique de déchargement. S’il vous plaît vérifier l’article ci-dessous concernant la façon dont et quand le processeur réseau met à jour les timers session sur DP.
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000Cm8cCAC
- Si le trafic DHCP est autorisé de la zone A à la zone B et si la session s’entrée avant la réponse provenant de la zone B à la zone A, ce message de réponse sera supprimé et il y aura une session vue dans l’état de « rejet ».
- Les paquets suivants seront touchés cette session et seront supprimés.

Resolution

Afin de résoudre les gouttes sur le pare-feu quelques mesures peuvent être prises:

Les sessions en état « Rejet » peuvent être répertoriées et supprimées par les commandes suivantes. Il est important de rechercher les sessions pour chaque direction.

> session afficher toutes les sources de filtre [adresse IP 1] destination [adresse IP 2]
état de rejet > afficher la session toutes les sources de filtre [adresse IP 2] destination [adresse IP 1]
état de rejet > afficher la session tous les états de filtre jeter > un id
de session claire [Session Id]

Dans les scénarios où le délai d’attente de la session est également affectif, la valeur de délai d’attente de la session peut être augmentée pour les identifiants d’application nécessaires. Cela peut être fait en modifiant la valeur de délai d’attente UDP sous l’onglet périphérique > Applications > [Concerned App-id] > UDP Timeout (Second) sur le WebUI.

Si changer le délai d’attente de la session n’aiderait pas, alors une autre option pourrait être de définir une règle de permis pour la direction inverse. (Se référant au scénario d’exemple 2, une règle d’autoriser de la zone B à la zone A) Ainsi, le trafic de retour déclenchera une toute nouvelle session et ne sera pas supprimé.

Additional Information