Troubleshooting NAT

Contenido complementario

Este tema no está en las notas de tus cursos que tengo (la lección de Troubleshooting NAT de PCNSE está pendiente de ver); está completado con conocimiento general de PAN-OS. La parte de orden de operaciones sí coincide con tus notas de Packet Flow. Compáralo con lo que veas en la lección y corrígelo si difiere.

Resumen

Un problema de NAT casi siempre se reduce a tres causas: la regla de NAT no coincide (zonas, direcciones o servicio mal escritos), la regla de Security Policy no está escrita con la lógica correcta para tráfico traducido, o la sesión ya existe y no se reevalúa. El error más frecuente en NAT de destino es escribir la Security Policy con la IP traducida cuando el firewall la evalúa con la IP original del paquete (la que el cliente de Internet usa, la pública), y con la zona de destino real (después de traducir).
Para diagnosticar con orden hay que recordar el flujo: el firewall busca la sesión, consulta la ruta, evalúa la NAT Policy con las zonas y direcciones originales (antes de traducir), evalúa la Security Policy con la zona de destino posterior al NAT y la IP de destino original, procesa App-ID y Content-ID y, por último, aplica la traducción (ver Packet Flow y Sessions). Esta nota da un procedimiento con comandos para encontrar la causa en Source NAT, Destination NAT, U-Turn y NAT bidireccional (ver Source NAT y Destination NAT).

Requisitos previos

• Los datos de la prueba: IP origen, IP destino original, puerto y protocolo, y la zona de entrada
• Saber qué traducción esperas: la IP traducida y la zona de destino real tras el NAT
• Haber leído Packet Flow y Sessions y el Troubleshooting Toolkit
• Un host de prueba externo (para NAT de destino) o interno (para Source NAT)
• Logs activados en las reglas de NAT/seguridad involucradas (Log at Session End)

Recordatorio del orden de operaciones

graph TD
    A["1. Sesión existente?"] --> B["2. Consulta de ruta<br/>(IP destino original)"]
    B --> C["3. NAT Policy<br/>zonas y IPs ORIGINALES (pre-NAT)"]
    C --> D["4. Security Policy<br/>zona destino POST-NAT,<br/>IP/puerto destino ORIGINALES"]
    D --> E["5. App-ID y Content-ID"]
    E --> F["6. Se aplica la traducción<br/>y el paquete sale"]

Elemento	Se evalúa con
Zona de origen (NAT y Security)	La zona de entrada del paquete
Zona de destino en NAT Policy	La zona pre-NAT (la de la ruta hacia la IP destino original)
Zona de destino en Security Policy	La zona post-NAT (donde está realmente el servidor)
IP/puerto de destino en Security Policy	Los originales (los que envió el cliente)

La confusión clásica

Un servidor en la DMZ con IP privada 10.30.0.100 publicado como 23.1.2.100: la NAT Policy se escribe de outside a outside con destino 23.1.2.100 (pre-NAT), y la Security Policy de outside a dmz con destino 23.1.2.100 (IP original) y zona de destino dmz (post-NAT).

Procedimiento

Paso 1: ¿La regla de NAT coincide?

test nat-policy-match from outside to outside source 203.0.113.50 destination 23.1.2.100 destination-port 443 protocol 6
test nat-policy-match from inside to outside source 10.10.0.20 destination 8.8.8.8 destination-port 443 protocol 6

La respuesta nombra la regla y la traducción. Si no coincide ninguna, revisa:

1. Zonas de la regla frente a las reales (usa la zona pre-NAT para el destino).
2. Dirección y servicio originales (el servicio es el puerto original que usa el cliente).
3. Orden: una regla anterior (por ejemplo una No NAT) puede coincidir primero.

Paso 2: ¿La Security Policy coincide con la lógica correcta?

test security-policy-match from outside to dmz source 203.0.113.50 destination 23.1.2.100 destination-port 443 protocol 6 application ssl

Zona de origen outside, zona de destino post-NAT (dmz), y destino la IP original (23.1.2.100). Si el resultado es interzone-default, tu regla no coincide por zona o dirección.

Paso 3: ¿Se creó la sesión con la traducción esperada?

show session all filter destination 23.1.2.100
show session id <n>

En show session id busca:

Campo	Qué mirar
c2s flow	Origen y destino antes de traducir, interfaz de entrada
s2c flow	Origen y destino después de traducir (el servidor real), interfaz de salida
nat / nat-rule	La regla de NAT aplicada
source-nat / dest-nat	Si se hizo SNAT o DNAT
rule	Regla de seguridad que permitió
state	ACTIVE, DISCARD, etc.

Si el s2c muestra la IP traducida esperada, el NAT funcionó; si faltan paquetes en s2c, el servidor no responde o la respuesta no vuelve.

Paso 4: ¿Qué ven los paquetes? (captura)

Haz un Packet Capture con las cuatro etapas (ver Troubleshooting Toolkit):

1. receive: el paquete con la IP original de destino (pública).
2. transmit: el paquete saliendo con la IP traducida (privada) hacia el servidor.
3. En la respuesta, receive del servidor y transmit hacia el cliente con la IP original.
4. drop: si algo se descarta.

Paso 5: ¿Hay ARP y proxy-ARP?

Para NAT de destino con una IP pública en la misma subred que la interfaz externa (la que recibe el tráfico, outside), el firewall debe contestar ARP por esa IP.

show arp interface ethernet1/6
show arp all

Si el enrutador del ISP no resuelve la IP pública, no enviará el tráfico al firewall. Una regla de NAT hace que el firewall conteste ARP por la dirección (proxy ARP) cuando la IP pertenece a la subred de la interfaz; si la IP es de otra subred, el ISP debe enrutarla hacia ti.

Paso 6: Casos específicos

Port forward (DNAT con cambio de puerto):

1. En la regla de NAT, el campo Service debe tener el puerto original (el que usa el cliente), por ejemplo un objeto tcp-8443 si el cliente va al 8443.
2. En Translated Packet > Destination Address Translation: la IP del servidor y el Translated Port (por ejemplo 443).
3. En la Security Policy, el servicio/aplicación va con el puerto original (tcp-8443), no el traducido.

U-Turn NAT (usuarios internos que acceden al servidor por su IP pública):

1. Necesita dos traducciones: DNAT hacia el servidor y SNAT del origen interno (con la IP de la interfaz interna o una dirección dedicada) para que la respuesta vuelva por el firewall.
2. Sin SNAT, el servidor responde directo al cliente (misma red), el cliente ve un origen inesperado y descarta la respuesta.

NAT bidireccional (Static IP con Bi-directional):

1. Crea automáticamente la regla inversa. Comprueba el orden y que no haya otra regla antes.

Doble ISP (Source NAT):

1. Una regla de Source NAT por interfaz de salida, con la zona/interfaz correcta; si falta una, el tráfico de la otra sale sin NAT o con la IP equivocada.

DIPP y agotamiento de puertos:

1. Si hay muchos clientes con una sola IP traducida y se agotan los puertos, las nuevas conexiones fallan. Mira show running nat-policy y las estadísticas del pool (show running ippool).

Verificación

Comando o lugar	Qué debes ver	Si no lo ves
test nat-policy-match ...	La regla de NAT esperada con la traducción correcta	Si no coincide, revisa zonas pre-NAT, direcciones, servicio y orden
test security-policy-match ...	La regla Allow esperada	Si es interzone-default, usa zona destino post-NAT e IP original
show session id <n>	c2s con IP original y s2c con IP traducida, y la regla de NAT	Si falta s2c, la respuesta no vuelve
show running nat-policy	Las reglas de NAT cargadas y su orden	Si falta, no hubo commit
show running ippool	Uso de los pools de DIPP	Si está lleno, amplía el pool o las IP
show arp interface <if>	ARP de la IP pública cuando corresponde	Si falta, el vecino no resuelve la IP
Captura receive/transmit	Las IP antes y después de la traducción	Si transmit no sale, mira drop
Monitor > Logs > Traffic: columnas NAT Source IP / NAT Destination IP (agrégalas)	Las IP traducidas	Si están vacías, no se aplicó NAT

Errores comunes

La Security Policy usa la IP privada del servidor y no coincide

• Causa: se escribió el destino con la IP traducida en lugar de la original.
• Solución: usa la IP pública (original) como destino y la zona real del servidor como zona de destino.

La regla de NAT de destino no coincide

• Causa: la zona de destino de la regla es la del servidor (post-NAT) en lugar de la pre-NAT.
• Solución: usa la zona por la que se llega a la IP pública (normalmente outside).

El port forward no funciona

• Causa: el Service de la regla tiene el puerto traducido en lugar del original, o la Security Policy usa el puerto traducido.
• Solución: usa el puerto original en el servicio de NAT y de Security Policy; el traducido va solo en Translated Port.

Los clientes internos no acceden al servidor por la IP pública

• Causa: falta U-Turn NAT (DNAT más SNAT).
• Solución: crea la regla de DNAT y la de SNAT del origen interno (o resuelve el nombre a la IP interna con DNS).

Cambié el NAT y no se nota

• Causa: la sesión existente conserva la traducción previa.
• Solución: clear session all filter ... y vuelve a probar.

Internet funciona para unos y no para otros con doble ISP

• Causa: falta la regla de Source NAT para una de las interfaces de salida.
• Solución: crea una regla por interfaz de salida (ver Source NAT).

Se agotan los puertos de DIPP

• Causa: demasiadas conexiones con una IP traducida.
• Solución: agrega IP al pool o ajusta el tipo de NAT (ver Source NAT).

El servidor responde pero el cliente no recibe

• Causa: la respuesta sale por otra interfaz o sin traducir, o el servidor no tiene ruta de retorno al firewall.
• Solución: revisa la ruta de retorno del servidor y que el flujo s2c de la sesión tenga la traducción esperada.