El firewall comienza a descartar un tráfico UDP que se permitió anteriormente, incluso no se han realizado cambios en la configuración del firewall o en cualquier lugar de la red

69367

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

Symptom

Puede haber una situación como el Firewall PAN comienza a bloquear un tráfico UDP (es decir, ESP, DHCP, DNS, NTP) que se había permitido antes.
Esto es posible incluso no se han realizado cambios en la configuración del firewall ni en ninguna parte del entorno.

Environment

Todas las plataformas de hardware y VM
Todas las versiones de PanOS

Cause

El firewall PAN crea y utiliza registros de sesión mientras se procesa el tráfico que pasa a través. El siguiente artículo se puede comprobar con respecto a cómo el firewall maneja el tráfico. https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClVHCA0

Las sesiones pueden estar en varios estados. El siguiente artículo se puede comprobar con respecto a la descripción de los estados de la sesión.
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000Clk9CAC

Si una sesión está en el estado "Descartar", cualquier paquete recibido por el Firewall y golpea esa sesión se cae siempre.

Una sesión puede estar atascada en el estado "Descartar" en ciertos escenarios. Los escenarios pueden ser pero no limitados a los siguientes:

Escenario de ejemplo 1: Un túnel IPSEC está fallando después de un cambio de configuración IPSec o reinicio del sistema
- En este escenario el otro par IPSec puede continuar enviando paquetes SEP durante el reinicio del sistema.
- Por las directivas/los config en el local el tráfico es caído por el Firewall y una sesión que fue creada entra en el estado "Descartar".
- Todos los paquetes siguientes golpearon la misma sesión y la sesión permanece y permanecen atascados en el estado "Descartar".
- Un nuevo phase2 nunca consigue establecido porque todos los mensajes golpean la misma sesión y se caen.

Escenario de ejemplo 2: Un tráfico DHCP retransmitido comienza a fallar de
repente: en este escenario la descarga de hardware que tenemos en la mayoría de nuestros modelos de hardware juega un papel.
- Una sesión existente relacionada con el tráfico DHCP puede agotar el tiempo de espera en DP debido a nuestra lógica de descarga. Consulte el artículo siguiente sobre cómo y cuándo el procesador de red actualiza los temporizadores de sesión en DP.
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000Cm8cCAC
- Si el tráfico DHCP se permite de la zona A a la zona B y si la sesión agota el tiempo de espera antes de la respuesta que viene de la zona B a la zona A, este mensaje de respuesta será caído y habrá una sesión vista en el estado del "descartar".
- Los siguientes paquetes golpearán esta sesión y se caerán.

Resolution

Para resolver las caídas en el Firewall algunas acciones se pueden tomar:

Las sesiones en estado "Descartar" se pueden enumerar y quitar mediante los siguientes comandos. Es importante buscar las sesiones para cada dirección.

> mostrar sesión todo el origen del filtro [dirección IP 1] destino [dirección IP 2] descarte el estado
> mostrar sesión toda la fuente de filtro [dirección IP 2] destino [dirección IP 1] descarte
> mostrar sesión todo el estado del filtro descarte
> id de sesión claro [Id de sesión]

En escenarios donde el tiempo de espera de sesión también es afectivo, el valor de tiempo de espera de sesión se puede aumentar para los identificadores de aplicación necesarios. Esto se puede hacer cambiando el valor de tiempo de espera UDP en la pestaña Dispositivo > aplicaciones > [Identificador de aplicación preocupado] > Tiempo de espera UDP (segundo) en la WebUI.

Si cambiar el tiempo de espera de la sesión no ayudaría, otra opción podría ser definir una regla de permiso para la dirección inversa. (Refiriéndose al escenario de ejemplo 2, una regla de permiso de la zona B a la zona A) Así que el tráfico de retorno desencadenará una nueva sesión y no se descartará.

Additional Information