Inicio / Notas técnicas / Guía de solución de problemas de firewall

Fallas de sesión, NAT y política del firewall: guía de solución de problemas de campo

Cuando un firewall Huawei USG “no deja pasar el tráfico”, la falla casi siempre está en uno de estos tres lugares — la política de seguridad nunca coincidió, la tabla de sesiones muestra algo anómalo, o el NAT tradujo lo incorrecto. Este es el orden que lo encuentra más rápido: los comandos display que ejecutar en cada etapa, cómo leer lo que devuelven, y los comandos de debugging a los que recurrir cuando los comandos display por sí solos no bastan.

Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026

Por qué el orden importa más que cualquier comando individual

Tres formas de falla distintas terminan en el mismo ticket — “el firewall no deja pasar el tráfico” — y cada una tiene su propio orden de diagnóstico.

Un reporte de tráfico de firewall rara vez viene con un síntoma claro. “No funciona” puede significar que la política de seguridad nunca coincidió con el tráfico, que la tabla de sesiones muestra algo raro una vez que existe una sesión, o que el NAT tradujo algo que no debía — o no tradujo lo que debía. Cambiar reglas en la capa de política y en la capa de NAT al mismo tiempo, esperando que algo funcione, es la forma más lenta de resolverlo. Trabajar las tres categorías en un orden fijo — política de seguridad, luego tabla de sesiones, luego NAT — encuentra la falla real más rápido, porque cada etapa descarta un conjunto distinto de causas antes de pasar a la siguiente.

A continuación, ese orden: los comandos display exactos para cada etapa y cómo leer lo que devuelven, los comandos de debugging y captura de paquetes a los que recurrir cuando los comandos display por sí solos no bastan, cinco trampas extraídas de casos reales de campo, y cinco respuestas a preguntas frecuentes construidas de la misma manera.

Lea el árbol de fallas antes de tocar cualquier configuración

Una falla de tráfico de firewall se divide claramente en exactamente tres formas — ubicar el síntoma en este árbol primero le indica qué sección de abajo realmente se aplica.

Cada rama de abajo descarta una capa específica. Trabajar de arriba hacia abajo — política, luego tabla de sesiones, luego NAT — significa que nunca está solucionando problemas de NAT porque asumió que la capa de política estaba bien.

Firewall Traffic Fault 1 · Security Policy Not Matching 2 · Session Table Abnormal 3 · NAT Problem HITS stays at 0matched a higher-priority rule, or the implicit default No policy name shown at allintra-zone / Local-zone traffic — expected, not a bypass No session created at allroute missing, policy deny, blacklist, session-limit reached Session exists, one direction is 0asymmetric routing, or a downstream drop on the return path NAT rule never hitspolicy source/dest isn't the real pre/post-NAT address Translation works, traffic still dropsPAT port conflict, or an anti-attack feature discarding it

Las etiquetas del diagrama se mantienen en inglés por claridad técnica.

Para la persona que reporta el problema, los síntomas de política de seguridad, tabla de sesiones y NAT a menudo se ven idénticos — “no funciona”. Revisar los hits antes que la tabla de sesiones antes que el NAT, en ese orden, es lo que realmente ahorra tiempo: cada etapa da un sí o no concluyente sobre si continuar.

Recorriendo cada etapa

Tres categorías, tres conjuntos diferentes de cosas a revisar — además de los comandos de debugging a los que recurrir cuando los comandos display por sí solos no bastan.

Etapa 1 — La política de seguridad no coincide

Si el contador de hits nunca se mueve, el tráfico no está llegando a la regla que usted cree — revise con qué está coincidiendo en realidad.

  1. Ejecute display security-policy rule enfocado en el destino, protocolo y puerto reales del tráfico. Si HITS se queda en 0 en todas las reglas, el tráfico no está coincidiendo con este conjunto de reglas como se espera — puede estar coincidiendo con otra regla de mayor prioridad, o cayendo en la regla implícita por defecto.
  2. Revise el orden de las reglas. Huawei evalúa las reglas de security-policy de arriba hacia abajo y se detiene en la primera coincidencia, así que una regla amplia con un número menor puede absorber silenciosamente tráfico destinado a una regla más específica que está debajo.
  3. Si la política debe regir a un usuario autenticado específico, compare la zona de destino de la política de autenticación con la zona de destino real de la sesión — una discrepancia ahí significa que la sesión nunca coincide con la política de autenticación, por lo que la regla de security-policy basada en el usuario tampoco se aplica.
  4. Recuerde que el tráfico intrazona, y el tráfico de gestión destinado al propio dispositivo bajo service-manage, puede pasar sin mostrar nunca un nombre de política coincidente en la tabla de sesiones. Ese es el comportamiento predeterminado esperado del filtrado de paquetes, no evidencia de un agujero en la capa de política.
<sysname> display security-policy rule destination 1.1.1.1 protocol tcp destination-port 8888
RULE ID RULE NAME                      STATE      ACTION     HITS
-------------------------------------------------------------------------------
1       1                              enable     permit     0
2       2                              enable     permit     0
5       5                              enable     permit     0
6       6                              enable     deny       0
0       default                        enable     deny       0
-------------------------------------------------------------------------------
// HITS stays at 0 on every rule -> this traffic never reached this rule set as you defined it

<sysname> display firewall session table verbose
// cross-check the session's actual destination zone against the authentication policy's configured destination zone

Etapa 2 — Tabla de sesiones anómala

O bien la sesión no existe en absoluto, o existe con contadores que indican exactamente qué dirección está rota.

  1. Ejecute display firewall session table verbose para el flujo exacto. Si no aparece nada en absoluto, la falla está aguas arriba de la propia tabla de sesiones — una ruta faltante o una denegación de security-policy — no un problema de la tabla de sesiones.
  2. Si existe una sesión, lea los contadores de paquetes/bytes en ambas direcciones (las líneas <-- y -->). Conteos distintos de cero en ambos lados confirman que las rutas de ida y vuelta realmente llegan a este dispositivo — la firma de un flujo saludable.
  3. Si una dirección se queda atascada en 0 paquetes/bytes mientras la otra se mueve, esa es la firma de un enrutamiento asimétrico o de un dispositivo aguas abajo descartando el tráfico de retorno — no una falla de política local o NAT, y no vale la pena seguir buscando en este dispositivo.
  4. Observe el campo Zone de la sesión. El tráfico de control IKE/IPSec destinado al propio dispositivo aparece en la zona local, no en la zona que esperaría según la interfaz por la que llegó físicamente — una fuente común de confusión cuando un túnel VPN comparte el mismo firewall.
<sysname> display firewall session table verbose source global 10.107.7.23 destination global 10.3.8.211 destination-port global 80
tcp  VPN: public --> public  ID: a38f5d6f74b701cf56ec2a0d
Zone: untrust --> trust  TTL: 00:20:00  Left: 00:17:57
Interface: Eth-Trunk0  NextHop: 0.0.0.0  MAC: 0000-0000-0000
<--packets: 10 bytes: 703 -->packets: 10 bytes: 703
10.107.7.23:47150 --> 10.3.8.211:80  PolicyName: 1
// non-zero packet count in both directions -> forward and return path both reach this device, networking is normal

// the same command on a failing flow instead shows:
<--packets: 0 bytes: 0 -->packets: 12 bytes: 840
// one direction stuck at 0 -> asymmetric routing or a downstream drop on the return path, not a local fault

<sysname> display firewall session table verbose
udp  VPN: public --> public  ID: a68f5bd4603f01f756c5ab54663
Zone: local --> trust  TTL: 00:02:00  Left: 00:01:58
// IKE/IPSec control traffic to the device itself lands in the local zone, not the interface's usual zone

Etapa 3 — Problema de NAT

Las fallas de NAT tienden a esconderse en uno de estos tres lugares: la dirección incorrecta configurada en la política, agotamiento de puertos en un pool PAT, o una función no relacionada descartando silenciosamente el paquete ya traducido.

  1. Confirme que la dirección configurada en la security-policy es la dirección real para esta dirección de tráfico. En un escenario de NAT de origen, la dirección de origen de la política debe ser la dirección previa al NAT; en un escenario de NAT de destino, la dirección de destino de la política debe ser la dirección posterior al NAT. Configurar el lado equivocado de ese par es invisible hasta que realmente rastree una sesión.
  2. Si la traducción misma parece fallar de forma intermitente a medida que aumenta la carga, revise display nat port conflict en busca de un historial de conflictos creciente ligado a un address-group específico.
  3. Recuerde que los pools en modo PAT permiten que una sola IP pública supere el límite bruto de sesiones por IP mediante la reutilización de puertos, pero la probabilidad de conflicto aumenta con la tasa de reutilización — la práctica de campo lo mantiene en aproximadamente 200,000 sesiones por IP pública como límite práctico, no teórico.
  4. Si tanto el NAT como el enrutamiento parecen correctos pero el tráfico sigue cayendo, revise display firewall statistic system discard antes de asumir que el NAT en sí es el culpable — una función anti-ataque (la detección de suplantación de IP es una común) puede descartar paquetes silenciosamente de una manera que, desde afuera, se ve exactamente igual a un problema de NAT o de sesión.
[sysname-diagnose] display nat port conflict
The history data of port conflict, Slot: 1 CPU: 0
2015-11-19 16:03:53 vsys:public protocol:17
192.168.1.1:2048[10.2.2.2:23878]-->8.8.8.8:53
pool:addressgroup1 porthash:**********

[FW] nat address-group addressgroup2
[FW-address-group-addressgroup2] mode no-pat global
[FW-address-group-addressgroup2] section 10.2.2.2
[FW-address-group-addressgroup2] route enable

<sysname> display firewall statistic system discard
Discard statistic information:
                IP header field invalid packets discarded:5
                       TCP session miss packets discarded:7
                   ATK packets discarded：77
// rising ATK-discard count with NAT/session otherwise healthy -> check anti-attack false positives, e.g. IP-spoofing detection

Puntos de depuración: cuando los comandos display no bastan

Una vez que las etapas anteriores le han indicado dónde está el problema pero no por qué, este es el orden para recurrir al debugging y a la captura de paquetes.

  1. Habilite primero terminal monitor y terminal debugging — sin ambos, la salida de debugging no se imprimirá en absoluto en su sesión.
  2. debugging ikev1 all / debugging ikev2 all junto con debugging ipsec all acota una falla relacionada con IPSec hasta el intercambio de negociación exacto, una vez que display ike sa / display ipsec sa por sí solos no lo han explicado.
  3. Para un flujo específico, limite una captura de paquetes a una ACL y una sola interfaz en lugar de capturar todo — mantiene el archivo de captura legible y el costo de CPU acotado.
  4. Una vez que tenga un hallazgo que valga la pena escalar, exporte un paquete de diagnóstico completo en lugar de volver a describir el síntoma de memoria en un ticket.
<sysname> terminal monitor
<sysname> terminal debugging
<sysname> debugging ikev1 all
<sysname> debugging ipsec all

[sysname] acl 3100
[sysname-acl-adv-3100] rule 5 permit ip source 10.1.1.1 0 destination 10.2.1.1 0
[sysname] packet-capture ipv4-packet 3100 interface GigabitEthernet 1/0/1
[sysname] packet-capture startup packet-num 1500
[sysname] packet-capture queue 0 to-file 1.cap

<sysname> display diagnostic-information dia-info.txt
<sysname> save logfile all

5 trampas de casos de fallas reales

Una vez que las tres etapas anteriores le han indicado dónde está el problema, estas son las trampas específicas que siguen apareciendo una vez que llega ahí.

1. Las direcciones de la política de seguridad deben ser la dirección real, no la que uno esperaría

SÍNTOMAEl tráfico se descarta aunque una regla de security-policy parece, en teoría, permitirlo — en un escenario donde también hay NAT configurado en la misma ruta.

CAUSALa security-policy siempre evalúa la dirección real para esa dirección de tráfico, no la que parece intuitiva: en un escenario de NAT de origen, la dirección de origen de la política debe ser la dirección previa al NAT, y en un escenario de NAT de destino, la dirección de destino de la política debe ser la dirección posterior al NAT. Configurar el lado equivocado de ese par produce una regla que se ve correcta y aun así nunca coincide.

SOLUCIÓNEscriba la dirección de la política con la dirección real previa o posterior al NAT, según la dirección de la traducción — no la dirección que un usuario o la documentación pública del servicio referenciaría.

[FW] nat address-group addressgroup2
[FW-address-group-addressgroup2] mode no-pat global
[FW-address-group-addressgroup2] section 10.2.2.2
[FW-address-group-addressgroup2] route enable
// security-policy source-address for this flow must reference the pre-NAT address, not 10.2.2.2

2. El tráfico de zona local e intrazona puede pasar sin mostrar nunca una política coincidente

SÍNTOMAdefault action deny está configurado y no existe ninguna regla explícita de security-policy, sin embargo el tráfico entre interfaces de la misma zona — o el tráfico de gestión hacia el propio dispositivo — sigue pasando.

CAUSAEl tráfico intrazona sí sigue coincidiendo con la ruta de evaluación de security-policy, pero bajo el comportamiento predeterminado de filtrado de paquetes no muestra un nombre de política coincidente a menos que exista una regla detallada con la zona de origen y la zona de destino explícitamente configuradas. Por separado, cuando service-manage enable está activo en una interfaz, el tráfico de gestión destinado a la zona Local omite por completo la coincidencia de security-policy — el permiso de filtrado de paquetes para ese tráfico lo decide service-manage, no el motor de políticas.

SOLUCIÓNNo interprete “sin nombre de política en la sesión” como “nada está filtrando esto”. Si necesita visibilidad o control sobre el tráfico intrazona, agregue una regla detallada con la zona de origen y la zona de destino coincidentes explícitamente configuradas; gestione deliberadamente qué servicios están abiertos bajo service-manage, ya que esa ruta omite el motor de políticas por diseño.

3. Una política basada en el usuario también necesita una zona de destino de política de autenticación coincidente

SÍNTOMAUna regla de security-policy configurada para denegar el tráfico de un usuario autenticado específico no surte efecto — se confirma que el usuario está en línea, pero su tráfico no está siendo bloqueado.

CAUSALa zona de destino de la política de autenticación no coincide con la zona de destino real de la sesión, por lo que la sesión nunca coincide con la política de autenticación en primer lugar — y una regla de security-policy basada en el usuario, aguas abajo de eso, tampoco tiene nunca la oportunidad de aplicarse, sin importar qué tan correctamente esté escrita.

SOLUCIÓNCompare display firewall session table verbose con la configuración de la política de autenticación; si la zona de destino necesita cubrir más de una zona, configúrela como any, luego verifique de nuevo que el conteo de hits de la regla basada en el usuario realmente empiece a moverse.

4. La reutilización de puertos del pool de direcciones NAT tiene un límite práctico, no solo teórico

SÍNTOMAEl NAT funciona bien con carga ligera, pero luego las sesiones a través de un pool PAT que ya funcionaba empiezan a fallar intermitentemente o a descartarse a medida que crece el tráfico.

CAUSAEl modo PAT permite que una sola IP pública supere su límite bruto de 63,488 sesiones mediante la reutilización de puertos, pero la probabilidad de un conflicto de puertos aumenta con la tasa de reutilización. La práctica de campo generalmente lo mantiene en aproximadamente 200,000 sesiones por IP pública como límite de trabajo, muy por debajo de cualquier máximo teórico.

SOLUCIÓNRevise display nat port conflict en busca de un historial de conflictos creciente antes de asumir que la configuración del pool en sí está mal; si una sola IP pública está genuinamente sobrecargada, agregue más direcciones al pool o divida el tráfico entre IP públicas adicionales.

[sysname-diagnose] display nat port conflict
The history data of port conflict, Slot: 1 CPU: 0
2015-11-19 16:03:53 vsys:public protocol:17
192.168.1.1:2048[10.2.2.2:23878]-->8.8.8.8:53
pool:addressgroup1 porthash:**********

5. Un falso positivo anti-ataque puede verse exactamente igual a una falla de NAT o de sesión

SÍNTOMAUn mapeo NAT que ha funcionado de forma confiable durante mucho tiempo deja de funcionar de repente, a menudo en un firewall de doble salida, sin ningún cambio de configuración en el lado de NAT o enrutamiento.

CAUSAUna función anti-ataque — la detección de suplantación de IP es una común — puede empezar a descartar silenciosamente paquetes que activan su heurística, sin ningún síntoma a nivel de NAT o de sesión que señalar directamente. Desde afuera, se presenta de forma idéntica a una falla de NAT o enrutamiento.

SOLUCIÓNRevise display firewall statistic system discard en busca de un conteo de descartes ATK en aumento antes de dedicar más tiempo a una configuración de NAT o de tabla de sesiones que ya es correcta; desactive o ajuste la función anti-ataque específica una vez confirmado, en lugar de dejar el anti-ataque desactivado por completo.

<sysname> display firewall statistic system discard
Discard statistic information:
                IP header field invalid packets discarded:5
                       TCP session miss packets discarded:7
                   ATK packets discarded：77

Diseños de soluciones relacionadas

Seguridad del borde de InternetLa zonificación del firewall, la política y la capa de NAT a la que este orden de solución de problemas se aplica directamente — no es hipotético, es el diseño de borde real sobre el que corren estos comandos. Protección contra ransomware y segmentación de redLa segmentación de zonas depende de que este mismo motor de security-policy realmente aplique lo que usted cree que aplica — vale la pena leerlo una vez que los fundamentos de solución de problemas estén sólidos.

Cinco preguntas que surgen constantemente

Sacadas directamente del campo — las que vale la pena tener una respuesta lista.

display firewall session table no muestra absolutamente nada para este tráfico — ¿por dónde empiezo?

Confirme primero la alcanzabilidad de la ruta, luego revise si la security-policy realmente permite el tráfico con display security-policy rule y su conteo de HITS. Una sesión que nunca se creó casi siempre significa que el paquete nunca llegó al dispositivo, o fue denegado antes de que pudiera siquiera construirse una sesión — no un error de la tabla de sesiones.

El conteo de HITS de la regla que espero nunca aumenta. ¿Qué me indica esto realmente?

Significa que el tráfico está coincidiendo con otra cosa — una regla diferente de mayor prioridad, o la regla implícita por defecto — antes de llegar siquiera a la regla que está observando. Revise el orden de las reglas y refine las condiciones de coincidencia; una regla con un conteo de hits atascado en cero rara vez está “rota”, generalmente simplemente no es la regla que realmente se está evaluando.

¿Por qué el tráfico sigue pasando cuando no he configurado ninguna regla de security-policy y default action es deny?

Esto solo aplica al tráfico intrazona y al tráfico de gestión de zona Local bajo service-manage. El tráfico intrazona todavía es evaluado por el motor de políticas pero no muestra un nombre de política coincidente bajo el comportamiento predeterminado de filtrado de paquetes a menos que exista una regla detallada; el tráfico service-manage hacia el propio dispositivo omite por completo el motor de políticas por diseño. Ninguno de los dos es un error — ambos son comportamiento predeterminado documentado.

¿Cuál es realmente la diferencia entre un problema de tabla de sesiones y un problema de política, si un ticket solo dice “el tráfico no funciona”?

Ninguna sesión en absoluto en display firewall session table verbose significa que el tráfico nunca pasó de la capa de política — revise los hits antes que nada. Una sesión que sí existe, con los contadores de paquetes/bytes de una dirección atascados en 0 mientras la otra se mueve, significa que la política ya dejó pasar el tráfico y el problema real es enrutamiento asimétrico o un descarte aguas abajo — no es en absoluto un problema de política, y no vale la pena volver a tocar la configuración de la política por eso.

¿Cuándo debo pasar de los comandos display al debugging?

Una vez que los comandos display le han dicho en qué etapa está atascado pero no por qué — por ejemplo, una negociación IKE que display ike sa muestra como ausente, sin una razón clara del lado de la política o el enrutamiento. Habilite primero terminal monitor y terminal debugging, luego ejecute el comando de debugging específico para esa función (debugging ikev1 all, debugging ipsec all, etc.) junto con una captura de paquetes acotada, y exporte un paquete de diagnóstico completo con display diagnostic-information y save logfile all antes de escalar.

Límites honestos de esta nota

Límites honestos de esta nota

Esta nota se basa en el conjunto de comandos de tabla de sesiones, security-policy y NAT del firewall Huawei serie USG, además de los casos de falla de campo que los respaldan. No cubre fallas a nivel de perfil UTM (IPS, antivirus, filtrado de URL como funciones de inspección de contenido en lugar de coincidencia de políticas), casos límite de conmutación de alta disponibilidad/activo-activo, ni en profundidad la herencia de políticas específica de sistemas virtuales (vsys) — esos temas tienen un alcance lo suficientemente diferente como para merecer su propio tratamiento.

¿Atascado con una falla específica del firewall?

Cuéntenos en qué etapa está atascado — política, tabla de sesiones o NAT — junto con la salida de display security-policy / display firewall session table, y le ayudamos a interpretarla.

WhatsApp con un ingeniero →

Lectura relacionada

Política de seguridad de firewall + VPN IPSec: recorrido de configuraciónLa configuración de referencia que este orden de solución de problemas asume que ya tiene implementada, incluyendo las reglas de política que permiten el tráfico propio del túnel. Información de fallas a recopilar antes de escalarQué capturar — paquete de diagnóstico, salida de debugging, captura de paquetes — antes de entregar una falla de firewall a un ingeniero de segunda línea. Seguridad del borde de Internet empresarialEl diseño de gateway más amplio que estos comandos de tabla de sesiones, política y NAT están diagnosticando en primer lugar.
Solo usamos cookies para analítica anónima — sin publicidad ni rastreo entre sitios.Política de privacidad