Comprender NAT en Sophos Firewall: SNAT, DNAT, MASQ, PAT

NAT es uno de los temas del Sophos Firewall que rápidamente se vuelve confuso en la práctica. Los términos suenan similares, la máscara de regla funciona con Original y Translated, y en Log Viewer ve direcciones diferentes a las esperadas según la ubicación.

Este artículo explica los tipos de NAT más importantes, muestra casos prácticos típicos y describe un ejemplo de DNAT con una regla de firewall adecuada.

El punto práctico más importante es: NAT debe considerarse junto con la regla de firewall, el enrutamiento, la ruta de retorno y el registro. Muchos problemas de NAT surgen no de la traducción en sí, sino de un orden de reglas incorrecto, un Original destination mal entendido, registros faltantes o pruebas de la red incorrecta.

Orientación

Antes de crear una regla NAT, primero debe quedar claro qué problema se está resolviendo realmente. NAT traduce direcciones o puertos, pero no reemplaza la limpieza del firewall ni el diseño de enrutamiento limpio.

¿Qué artículo NAT encaja?

NAT se superpone rápidamente con reglas de firewall, enrutamiento, WAF, VPN y Packet Capture. Dependiendo de la tarea, este artículo básico no siempre es la mejor forma de empezar:

• Comprender NAT, SNAT, DNAT, MASQ, PAT, Loopback y reglas reflexivas: este artículo.
• Publicar un servidor interno mediante reenvío de puertos: Publicar servidor mediante DNAT en Sophos Firewall.
• Publicar una aplicación HTTP o HTTPS: Sophos Firewall WAF: publicar un servidor web de forma segura.
• Clasificar reglas de firewall y NAT conjuntamente: Comprender y configurar de forma segura las reglas Sophos Firewall.
• Probar una conexión individual con registros y Packet Capture: Probar una regla de firewall con Log Viewer, Policy Test y Packet Capture.
• Comprobar NAT para IPsec, XFRM, SD-WAN o redes solapadas: Resolución de problemas de IPsec VPN en Sophos Firewall.
• Analizar drops, Violation, Rule ID o NAT Rule ID: Analizar paquetes descartados en Sophos Firewall.

Esto hace que la resolución de problemas sea más precisa: primero aclare si se trata de traducción, publicación, enrutamiento, protección del servidor web o flujo de paquetes. Después de eso, solo se debe cambiar la capa afectada.

NAT es traducción, no publicación

Traducción de direcciones de red cambia las direcciones o puertos de un paquete a medida que pasa por Sophos Firewall. Sin embargo, NAT no decide por sí solo si se permite el tráfico.

⚠️ Una regla NAT no permite el tráfico. La regla solo traduce direcciones o puertos. También siempre se requiere una regla de firewall adecuada para el tráfico a través del firewall.

Casos típicos de NAT:

• Los clientes internos acceden a Internet a través del público WAN-IP.
• Un servidor interno se publica a través de un IP público.
• Un puerto público se traduce a otro puerto interno.
• Las redes superpuestas se traducen para conexiones VPN.
• Los clientes internos acceden a un servidor interno a través del nombre DNS público.

Decisión rápida: ¿NAT o no NAT?

Muchos errores NAT surgen porque NAT se utiliza como solución predeterminada, aunque el enrutamiento o una regla de firewall serían suficientes. Antes de cada nueva regla NAT, primero debe decidir si realmente es necesario cambiar una dirección o un puerto.

• El cliente del LAN debe acceder a Internet normalmente: Una regla general SNAT o MASQ suele ser suficiente.
• Se debe poder acceder al servidor interno desde Internet: Utilice DNAT o para HTTP/HTTPS marque WAF primero.
• Se debe utilizar un puerto diferente externamente que internamente: Planifique DNAT con PAT y agregue la regla de firewall adecuada.
• Los usuarios internos acceden al mismo FQDN público: Primero verifique el DNS dividido, use el loopback NAT solo si es necesario.
• Las redes VPN locales y remotas son claras: Generalmente no use NAT, pero cree reglas de enrutamiento y firewall de manera limpia.
• Las redes VPN se superponen o la estación remota requiere una fuente específica: Utilice SNAT o DNAT de destino con una red de reemplazo documentada.
• Solo se debe permitir o restringir una regla de firewall: No compilar NAT. Ajuste la regla del firewall.

Si la respuesta a “¿Qué debería traducirse?” no está claro, no se debe crear una regla NAT. Luego, primero verifique el flujo de paquetes, la dirección de destino, la ruta de retorno y Log Viewer. Especialmente para VLAN internas, VPN de sitio a sitio sin redes superpuestas y redes de servidores enrutadas, ningún NAT suele ser la solución más limpia.

Comprender los conceptos básicos de NAT

La máscara de reglas se vuelve mucho más sencilla si primero diferencia entre el tráfico original y el tráfico traducido. Entonces quedará más claro si es necesario cambiar el origen, el destino o el servicio.

Las principales especies NAT

• SNAT: Traduce la fuente IP. Normalmente, cuando se supone que los clientes o servidores internos acceden a Internet con un IP público específico.
• MASQ: Traduce el IP de origen al IP de la interfaz saliente. Este es el caso estándar para LAN a WAN.
• DNAT: Traduce el destino IP. Esto hace que se pueda acceder a un servidor interno a través de un IP público.
• PAT: Traduce puerto o servicio. Esto significa que un puerto externo apunta a otro puerto interno.
• Loopback NAT: Permite el acceso interno a través de IP público o FQDN público. Los clientes internos utilizan el mismo nombre DNS que los usuarios externos.
• Regla reflexiva: Crea una regla de fuente reflexiva NAT. Esto permite que un servidor publicado aparezca ante el tráfico saliente con una identidad pública adecuada.

Como modelo mental, ayuda: NAT no responde a la pregunta “¿Está permitido este tráfico?”, sino “¿Cómo debería verse la dirección o el puerto en el camino?”

Leer el original y traducir correctamente.

En las reglas NAT, Original describe el tráfico que llega al Sophos Firewall. Translated lo describe después de la traducción.

• Original source: Dirección de origen anterior a NAT.
• Translated source (SNAT): Dirección de origen a NAT.
• Original destination: Dirección de destino anterior a NAT.
• Translated destination (DNAT): Dirección de destino después de NAT.
• Original service: Servicio o puerto anterior a NAT.
• Interfaces y VPN: Any suele ser correcto para interfaces de entrada y salida en escenarios DNAT o VPN, porque los túneles VPN no siempre se tratan como interfaces físicas normales.
• Servicio traducido (PAT): Servicio o puerto a NAT.

Si hay errores, primero debe observar cómo se ve el paquete antes de NAT. Luego defines qué debe hacer el firewall con él.

Agenda NAT antes del cambio

Antes de realizar un cambio NAT, no solo debes mirar la regla NAT en sí. Todo el flujo de paquetes es crucial: ¿dónde llega el paquete, qué regla de firewall permite el tráfico, qué regla NAT lo traduce, adónde va la respuesta y cómo se verifica el resultado?

Estos puntos deben quedar claros antes del cambio:

• Paquete anterior a NAT: El origen, el destino y el servicio deben coincidir con el lado Original de la regla NAT.
• Paquete según NAT: Translated source, Translated destination y Translated service deben configurarse deliberadamente.
• Regla de firewall que permite: NAT no permite el tráfico. Sin una regla de firewall adecuada, la traducción resulta ineficaz.
• Reglas NAT más generales: La primera regla NAT que coincida gana. Una regla amplia SNAT o MASQ puede ocultar reglas más específicas.
• Ruta de retorno: Muchos problemas de NAT son en realidad problemas de ruta, ruta de retorno o sistema de destino.
• Método de prueba: Log Viewer, ID de regla, NAT Rule ID y Packet Capture deben prepararse antes de realizar la prueba.

Comprender y configurar de forma segura las reglas Sophos Firewall le ayuda a encontrar la regla de firewall adecuada. Si no está claro si la regla se aplica, La regla Sophos Firewall no se aplica: verificar las causas es el mejor comienzo para la solución de problemas.

Ejemplos prácticos: ¿Cuándo usas qué?

• Los clientes del LAN deberán acceder a Internet: MASQ o SNAT. Ejemplo: 10.10.10.80 sale con el firewall WAN-IP.
• El servidor web interno debe ser accesible desde el externo: DNAT. Ejemplo: el público WAN-IP apunta a 172.16.16.10.
• Se utiliza un puerto diferente externamente que internamente: PAT. Ejemplo: TCP 5555 externo, TCP 443 interno.
• Los usuarios internos utilizan el mismo FQDN que los usuarios externos: Loopback NAT. Ejemplo: service.example.com apunta al mismo servicio interna y externamente.
• El servidor publicado debe aparecer saliente con IP público específico: SNAT o regla reflexiva. Ejemplo: un servidor de correo envía con IP público definido.
• Las redes VPN se superponen: SNAT o DNAT. Ejemplo: el sitio A ve el sitio B a través de una red traducida.
• El tráfico interno debe permanecer sin cambios: No NAT. Las reglas de enrutamiento y firewall son suficientes.

No todo el tráfico necesita NAT. Entre VLAN internas, a través de VPN de sitio a sitio sin redes superpuestas o hacia redes enrutadas directamente, NAT a menudo es incluso dañino porque los registros, las estaciones remotas y los sistemas de destino pierden la fuente real IP. Por lo tanto, una buena planificación NAT decide primero si es necesario realizar una traducción.

NAT especies en la práctica

Los siguientes tipos NAT resuelven diferentes tareas. En entornos productivos, se debe seleccionar conscientemente qué traducción es necesaria en lugar de utilizar NAT como solución alternativa general para los problemas de enrutamiento.

SNAT: Fuente NAT

SNAT cambia la dirección de origen. El caso clásico es el acceso saliente a Internet desde el LAN. Los clientes conservan internamente sus direcciones IP internas, pero la dirección pública del firewall o una IP pública definida aparece externamente.

Regla SNAT típica para LAN a WAN:

• Original source: LAN interno o red de servidores.
• Translated source (SNAT): MASQ o público fijo IP.
• Original destination: Any.
• Translated destination (DNAT): Original.
• Original service: Any o Services definido.
• Servicio traducido (PAT): Original.
• Inbound interface: interfaz interna o Any.
• Interfaz de salida: Interfaz WAN. Para entornos simples, una regla SNAT genérica suele ser más clara que muchas reglas NAT individuales vinculadas.

MASQ: Enmascaramiento

MASQ es una variante conveniente de SNAT. De forma predeterminada, MASQ traduce la dirección de origen a la dirección IP de la interfaz saliente. Para un acceso normal a Internet, este suele ser el WAN-IP.

En la configuración básica, el Sophos Firewall tiene una regla SNAT predeterminada con MASQ. Si no desea utilizar esta regla, desactivar suele ser más limpio que eliminar. De lo contrario, la regla predeterminada puede volver a aparecer al crear o actualizar una interfaz WAN.

Obstáculo: con las VPN basadas en rutas, MASQ puede verse diferente de lo esperado. Si las subredes locales y remotas están configuradas en Any o se utilizan configuraciones duales IP, el firewall puede usar XFRM-IP como fuente traducida. En Packet Capture o tcpdump, puede ver WAN-IP en el encabezado externo y XFRM-IP en el contexto interno. Otros obstáculos se aplican al IPsec basado en políticas. Si es necesario asignar el tráfico traducido a un túnel IPsec específico, las rutas IPsec y la configuración de interfaz de salida en las reglas SNAT pueden ser fundamentales. El proceso está en IPsec Crear ruta en Sophos Firewall.

NAT en VPN, SD-WAN y redes superpuestas

NAT rápidamente se vuelve más complejo en entornos VPN y SD-WAN que el simple tráfico LAN a WAN. El principio más importante sigue siendo el mismo: primero, el camino esperado debe estar claro. Luego decide si es necesario NAT.

Escenarios típicos:

• VPN de sitio a sitio con redes únicas: Mayormente no hay NAT, pero reglas de firewall y enrutamiento limpios.
• VPN de sitio a sitio con redes superpuestas: Regla SNAT o DNAT dirigida con red de respaldo documentada.
• VPN basado en ruta con XFRM y SD-WAN: Verifique la interfaz XFRM, la ruta, la ruta SD-WAN y NAT juntos.
• IPsec basado en políticas con tráfico traducido: Verifique la ruta IPsec y la regla SNAT con Outbound interface coincidente.
• Remote Access VPN a redes internas: Normalmente no hay NAT, a menos que un sistema de destino espere una fuente específica.

Para redes superpuestas, no se debe improvisar NAT. Ambas partes necesitan saber qué red real está detrás de qué red traducida. De lo contrario, las pruebas individuales funcionan, pero las aplicaciones, el DNS, el registro o las reglas de acceso se vuelven difíciles de entender más adelante. Si un túnel VPN está en verde pero no circula tráfico útil, NAT es solo una de varias causas posibles. Entonces deben comprobarse en paralelo el estado IPsec, Route Lookup, la regla de firewall, la ruta SD-WAN y Packet Capture. Para un proceso estructurado son adecuados Resolución de problemas de IPsec VPN en Sophos Firewall, enrutamiento SD-WAN para Reply Packets y System Traffic y comprobar MTU y MSS en Sophos Firewall ante problemas de VPN.

DNAT: Destino NAT

DNAT cambia la dirección de destino. Por ejemplo, puede publicar un servidor interno a través de un IP público o un puerto público. El tráfico entrante a la dirección WAN se traduce al servidor interno.

Regla típica DNAT:

• Original source: Any o redes IP de origen definido.
• Original destination: Objeto host WAN-IP o WAN.
• Original service: servicio externo, por ejemplo HTTPS o Synology_5555.
• Translated destination (DNAT): servidor interno.
• Servicio traducido (PAT): Original o puerto de destino interno.
• Translated source (SNAT): principalmente Original.
• Inbound interface: Interfaz Any o WAN.
• Interfaz de salida: principalmente Any en DNAT.

Para los servicios públicos, no solo debe compilar NAT, sino también verificar inmediatamente el registro, IPS, restricciones de origen, lógica geo-IP y nivel de parche del servidor de destino. Puede encontrar instrucciones paso a paso más detalladas en el artículo Publicar servidor en Sophos Firewall mediante DNAT. Para aplicaciones HTTP y HTTPS, también debe verificar si un Sophos Firewall WAF se adapta mejor que un DNAT puro. DNAT es un reenvío de puertos. WAF puede incluir nombres de host, certificados, rutas, perfiles de protección web y, opcionalmente, autenticación. Para servicios simples que no son HTTP, DNAT a menudo sigue siendo correcto; para aplicaciones web de acceso público, WAF suele ser un mejor punto de partida.

PAT: Traducción de dirección de puerto

PAT cambia el servicio o puerto. En el Sophos Firewall, el campo Servicio traducido (PAT) es responsable de esto.

Ejemplo:

• TCP 5555 externo a TCP 443 interno.
• TCP 20120 externo a TCP 22 interno.
• TCP 8443 externo a TCP 443 interno.

El cliente externo se conecta a un puerto público, pero internamente se accede a un puerto diferente. Importante: El protocolo debe ser correcto. TCP se puede traducir a TCP, UDP a UDP. Una traducción de TCP a UDP no es un reenvío de puertos limpio.

Ejemplo de DNAT con regla de firewall

El ejemplo muestra la publicación típica de un servicio interno. Lo crucial es que la regla NAT y la regla del firewall coincidan.

Ejemplo práctico: publicar Synology mediante DNAT

En el ejemplo, se debe poder acceder a un servicio a través de un WAN-IP público. El servicio Synology_5555 se aborda desde el exterior. Internamente el servidor escucha HTTPS. Entonces, la regla NAT traduce la dirección de destino pública al servidor interno y el servicio público al servicio interno.

DNAT regla campo por campo

• Rule name: Nombre claramente, por ejemplo DNAT_SYNOLOGY_5555.
• Descripción: Documente por qué existe la regla y quién la creó. Esto será de gran ayuda más adelante.
• Rule position: Las reglas específicas deben colocarse por encima de las reglas generales.
• Original source: Puede restringirse en la regla NAT. En la práctica, suele ser más limpio mantener la restricción de origen en la regla del firewall para que no sea necesario mantener la misma restricción dos veces.
• Original destination: La dirección de destino pública anterior a NAT. Es mejor utilizar un objeto host para WAN-IP que la interfaz WAN directamente. Un objeto host suele permanecer más estable durante los cambios o ajustes de la interfaz.
• Original service: El servicio o puerto al que se puede llegar desde el exterior, por ejemplo Synology_5555.
• Translated source (SNAT): Para las reglas clásicas DNAT generalmente Original. Cambie solo si el servidor interno debe ver el firewall como fuente. Pero luego pierdes el cliente real IP.
• Translated destination (DNAT): El servidor interno o una lista de servidores a los que redirigir.
• Servicio traducido (PAT): El servicio interno o puerto en el que se va a reescribir, por ejemplo HTTPS. Si no es necesario ningún cambio de puerto, el servicio sigue siendo Original.
• Inbound interface: Interfaz por donde entra el tráfico. Para DNAT suele ser Any o WAN. Any suele ser necesario para contextos VPN porque las VPN no se tratan como interfaces normales.
• Interfaz de salida: Para DNAT generalmente Any, ya que el firewall decide el enrutamiento y la zona de destino.

Crear regla de firewall para la regla DNAT

Una regla DNAT no es suficiente. Además, se requiere una regla de firewall que permita el tráfico.

Para DNAT es importante: La regla de firewall se refiere al tráfico en el contexto DNAT. Esto parece inusual al principio, especialmente en zonas objetivo y redes objetivo.

• Source zones: Principalmente WAN cuando el acceso proviene de Internet.
• Source networks and devices: Si es posible, no Any si se puede evitar. Es mejor utilizar países, IP individuales, redes, hosts o grupos FQDN.
• Destination zones: La zona del objetivo interno, por ejemplo SERVER o DMZ, no simplemente WAN.
• Destination networks: La dirección de destino pública o el objeto host WAN de Original destination.
• Services: El servicio externo de Original service, es decir, el puerto al que acceden los clientes desde fuera.
• Log firewall traffic: Habilitar para servicios publicados. Sin iniciar sesión, el Log Viewer no es útil con esta regla. Si los usuarios globales necesitan acceso y Source networks and devices no se puede restringir de manera significativa, aún así debe endurecer la regla: solo abra los puertos requeridos, active IPS, active el registro, mantenga el sistema de destino actualizado y use MFA, VPN o ZTNA si es posible.

💡 Los bots suelen escanear muy rápidamente los servicios de acceso público. Sophos Firewall Threat Feeds ayudan a bloquear IP, dominios o URL maliciosos conocidos de forma temprana. Esto no reemplaza una regla limpia, pero reduce significativamente el tráfico de bots innecesarios.

Regla de bucle invertido: acceso interno a través del nombre DNS público

Se requiere una Regla de bucle invertido si los clientes internos deben llegar a un servidor interno a través de su IP público o FQDN público.

Ejemplo:

• Externamente service.example.com apunta al público WAN-IP.
• Internamente los clientes utilizan el mismo nombre service.example.com.
• Sin loopback, el tráfico del LAN va al IP público del firewall y tiene que volver al servidor interno.

En entornos simples, el DNS dividido suele ser más limpio: internamente, service.example.com apunta directamente al servidor interno IP. Entonces no hay necesidad de Hairpin-NAT. Si no es posible dividir el DNS, una regla de bucle invertido puede tener sentido.

Con Server Access Assistant, el Sophos Firewall puede crear automáticamente reglas de loopback. Sin embargo, esto solo funciona bajo ciertas condiciones, por ejemplo si la interfaz WAN se usa como Pública IP y las fuentes externas están definidas adecuadamente en general. Con reglas manuales, el loopback debe planificarse conscientemente y luego probarse.

Regla reflexiva: reflejar el tráfico saliente del servidor

Una Regla reflexiva es una regla SNAT generada automáticamente para la regla DNAT. Esta regla puede resultar útil si desea que el servidor publicado aparezca comenzando con un IP público específico. Importante: Las respuestas normales a una conexión DNAT entrante generalmente no requieren una regla reflexiva separada. El firewall con estado garantiza que los paquetes de respuesta pertenezcan a la conexión existente.

Sólo debes activar reglas reflexivas si entiendes el propósito. En entornos con varias IP WAN, varias reglas DNAT o varios servidores, una regla SNAT adicional puede generar un comportamiento difícil de entender.

⚠️ Las reglas Loopback o Reflexive generadas automáticamente siguen siendo reglas independientes. Si la regla DNAT original se modifica o elimina más tarde, estas reglas derivadas no se actualizan lógicamente de forma automática. Después de cada cambio en la regla original, las reglas Loopback y Reflexive relacionadas deben revisarse manualmente.

Funciones avanzadas de NAT

Estas opciones no son necesarias en todos los entornos. Se vuelven importantes cuando los clientes internos usan el mismo nombre público, están involucrados varios servidores de destino o se crean reglas NAT a partir de reglas de firewall.

¿Asistente de acceso al servidor o regla manual NAT?

Server Access Assistant puede crear automáticamente reglas DNAT, loopback, reflexivas y de firewall. Esto es útil si desea publicar rápidamente un servicio.

Para entornos productivos, las reglas manuales suelen ser más fáciles de entender:

• Puedes ver exactamente qué regla hace qué.
• Las restricciones de origen se mantienen deliberadamente en las reglas del firewall.
• La regla NAT sigue siendo más delgada.
• La posición de la regla y el registro se establecen limpiamente.
• Los cambios posteriores son menos sorprendentes.

El Asistente es útil, pero no reemplaza la comprensión de las reglas individuales.

Reglas NAT vinculadas

Se crea una Regla NAT vinculada a partir de una regla de firewall. Es una regla de origen NAT en la tabla de reglas NAT.

Esto suena práctico, pero tiene límites:

• La mayoría de los criterios coincidentes provienen de la regla del firewall.
• En la regla NAT solo puedes ajustar ciertos campos NAT.
• Una regla NAT más general anterior aún puede coincidir primero.
• Muchas reglas NAT vinculadas rápidamente hacen que la tabla NAT sea confusa.

Para configuraciones nuevas y simples, una regla NAT independiente en Rules and policies > NAT rules suele ser más comprensible. Las reglas NAT vinculadas son particularmente útiles en escenarios de migración o casos especiales muy específicos.

Equilibrio de carga y Health Check en DNAT

DNAT puede hacer más que un simple reenvío de puertos. Si varios servidores internos están almacenados como Translated destination, el firewall puede distribuir el tráfico.

Posibles métodos:

• Round robin: distribución simple sin persistencia de sesión.
• Primero activo: servidor primario con conmutación por error.
• Aleatorio: distribución aleatoria.
• Sticky IP: la misma combinación de origen y destino permanece en el mismo servidor.
• Uno a uno: asignación fija entre el destino original y el traducido. Si desea que el firewall detecte si un servidor de destino está disponible, se debe habilitar Comprobación de estado. Sin Health Check, el firewall considera que los servidores están disponibles incluso si no responden.

NAT orden

Sophos procesa las reglas NAT de arriba a abajo. La primera regla coincidente gana. Después de eso, ya no se comprobarán más reglas NAT.

Recomendación:

• Reglas específicas DNAT arriba
• Reglas específicas SNAT por encima de las reglas generales MASQ
• Posicione conscientemente la regla SNAT predeterminada
• Verifique las reglas NAT vinculadas con regularidad
• Eliminar o desactivar reglas de migración antiguas si ya no son necesarias

Un orden probado y comprobado en muchos entornos se ve así:

1. Agujero negro DNAT o reglas de bloqueo para fuentes no deseadas conocidas, si se utilizan dichas reglas.
2. Reglas DNAT muy específicas para los servicios publicados.
3. Reglas especiales SNAT para servidores individuales, redes de socios o casos especiales VPN.
4. Reglas en bucle o reflexivas cuando se necesitan conscientemente.
5. Reglas generales SNAT o MASQ para el acceso normal a Internet.

Esta no es una ley estricta y rápida, pero es un buen marco de prueba. El flujo de prueba específico siempre es crucial. Si una regla MASQ amplia o una regla NAT antigua vinculada se coloca encima de una regla específica, la nueva regla parece correcta pero nunca se alcanza. Al realizar cambios, no sólo debe comprobar la regla en sí, sino también las reglas directamente encima y debajo de ella.

Para los servicios públicos, una regla de agujero negro DNAT antes de la regla productiva DNAT puede ser útil si ciertas listas o países malos IP deben ser interceptados tempranamente. El proceso se describe en Sophos Firewall: Bloquear países e IP maliciosas.

NAT cambie y verifique de forma segura

Los cambios NAT alteran el flujo de paquetes. Es por eso que debes tratarlo como un cambio productivo: preparar, probar, registrar y revertir limpiamente si es necesario.

Implemente los cambios NAT de forma segura

Los cambios NAT a menudo afectan el tráfico productivo de inmediato. Esto es particularmente crítico para servidores publicados, casos especiales de VPN, múltiples direcciones WAN-IP o reglas de firewall utilizadas por socios externos. Por lo tanto, NAT no debe tratarse como un cambio de objeto puro, sino más bien como un pequeño cambio con una ruta de prueba y alternativa.

Antes de realizar un cambio productivo, debes tener en cuenta brevemente:

• NAT Rule ID anterior y nombre de regla: En Log Viewer puede verificar si la nueva regla realmente se aplica.
• Flujo de prueba esperado: El origen, el destino, el servicio y la dirección deben estar claros antes de guardar.
• Regla de firewall dependiente: NAT y la regla de firewall deben coincidir, pero se deben verificar por separado.
• Ruta alternativa: Si hay problemas, la nueva regla se puede desactivar y la regla anterior se puede activar nuevamente.
• Ventana de prueba: Los servicios externos, los sitios remotos VPN o el acceso de socios no deben interrumpirse sin que nadie se dé cuenta.

Al realizar cambios importantes, recomendamos primero duplicar las reglas NAT existentes o crear una nueva regla específica encima de ellas en lugar de convertir directamente la única regla que funciona. La antigua regla inicialmente permanece desactivada o permanece a continuación como referencia. Después de una prueba exitosa, se puede eliminar o documentar claramente.

La posición de la regla también es importante: una nueva regla específica SNAT o DNAT no sirve de nada si una regla más general anterior ya coincide con el mismo tráfico. Por lo tanto, el cambio siempre incluye una prueba del visor de registros con Firewall Rule ID y NAT Rule ID esperados. Para servicios accesibles externamente, la prueba no debe realizarse únicamente desde su propio LAN. Una prueba interna para el FQDN público a menudo verifica el bucle invertido o el DNS dividido, pero no el acceso real desde Internet. La aceptación de DNAT requiere al menos una prueba externa, por ejemplo a través de comunicaciones móviles, una ubicación externa o una prueba de puerto controlado.

Verifique NAT y la regla de firewall juntos

Un error de pensamiento común es: “La regla NAT es correcta, por lo que debería funcionar”. Eso es sólo una verdad a medias.

Para que el tráfico funcione necesitas:

1. Enrutamiento al firewall
2. regla NAT adecuada si es necesaria la traducción
3. regla de firewall adecuada
4. ruta de regreso correcta
5. perfiles de seguridad adecuados
6. sin bloqueo ascendente, por ejemplo, enrutador del proveedor, grupo de seguridad en la nube o firewall de destino Lo siguiente también se aplica a DNAT: Las reglas de firewall para el tráfico DNAT utilizan la zona de destino después de NAT, pero la dirección de destino pública anterior a NAT como red de destino. Es precisamente este punto el que es crucial en muchas soluciones de problemas.

Lea Firewall Rule ID y NAT Rule ID correctamente

En el caso de errores NAT, no solo debe verificar si existe alguna entrada de registro. Lo crucial es si la entrada del registro coincide con la regla de firewall esperada y la regla NAT esperada. Por esta razón, Firewall Rule ID y NAT Rule ID son más útiles que el nombre de la regla por sí solo, porque los nombres se pueden cambiar, elegir de manera similar o cortar en las capturas de pantalla.

Una breve interpretación ayuda:

• Firewall Rule ID esperado y NAT Rule ID esperado visible: La coincidencia de reglas es básicamente correcta. Luego verifique la ruta de retorno, el sistema de destino, el perfil de seguridad y la aplicación.
• Se esperaba Firewall Rule ID visible, pero NAT Rule ID incorrecto: La regla del firewall coincide, pero el orden NAT o los criterios NAT no coinciden. Verifique la posición de la regla NAT, los campos Original y las reglas NAT más generales.
• Otro Firewall Rule ID visible: Otra regla de firewall gana. Verifique el orden de las reglas del firewall, zonas, origen, destino y servicio.
• No hay NAT Rule ID visible, aunque se espera NAT: No se aplicó ninguna regla NAT o se está viendo el tipo de registro o flujo incorrecto. Consultar criterios NAT, dirección y flujo de prueba real.
• No hay ninguna entrada de registro visible: Falta el registro o el tráfico no llega al firewall. Verifique el registro de reglas, el enrutador del proveedor, VLAN, Gateway y Packet Capture. Especialmente con DNAT, una única prueba exitosa o fallida sin una comparación de ID no es suficiente. Debe tener en cuenta qué ID se esperan, ejecutar la prueba exactamente una vez y luego comparar Log Viewer y Packet Capture. Si los ID no coinciden con las expectativas, primero se corrige la coincidencia y el orden, no el servidor de destino.

Errores comunes NAT

Cuando se trata de problemas NAT, resulta útil no reconstruir las reglas inmediatamente. Primero, se debe clasificar el defecto observado.

• No hay entradas de registro en Log Viewer: El tráfico no llega al firewall, falta el registro o el filtro es incorrecto. Verifique el enrutador del proveedor, el grupo de seguridad de la nube, el cliente Gateway, el registro y los filtros de las reglas del firewall.
• Entrada de registro sin NAT Rule ID esperado: La regla NAT no coincide o una regla superior gana. Original source, Original destination, consultar servicio y pedido NAT.
• La regla DNAT coincide, la conexión aún no funciona: La regla del firewall, el servidor de destino, la ruta de retorno o el firewall del servidor local están bloqueados. Compare Firewall Rule ID, Packet Capture y los registros del servidor.
• El acceso interno al FQDN público no funciona: Falta el DNS dividido o el loopback NAT. Verifique la resolución del DNS interno y decida si el DNS dividido o el loopback son más limpios.
• El cliente externo ve la fuente incorrecta-IP: SNAT o la regla reflexiva cambia la fuente inesperadamente. Verifique Translated source (SNAT) y las reglas generadas automáticamente.
• El tráfico VPN utiliza la fuente inesperada IP: La ruta SNAT, XFRM, SD-WAN o la ruta IPsec no coinciden. Verifique la búsqueda de rutas, la ruta SD-WAN, la ruta IPsec y la posición de la regla NAT.
• Puerto público que apunta a un servicio interno incorrecto: PAT o el objeto de servicio está configurado incorrectamente. Compare Original service y Translated service (PAT). La tabla no reemplaza el análisis del flujo de paquetes, pero ahorra tiempo: separa los problemas frente al firewall, en la lógica NAT, en la regla del firewall y en el sistema de destino.

Prueba de aceptación después de los cambios NAT

Después de un cambio NAT, no solo debes comprobar si un único ping o un sitio web funciona una vez. La prueba debe coincidir con el tipo de traducción.

Para SNAT o MASQ:

1. Defina el cliente de prueba y el servicio de destino.
2. Verifique la regla del firewall con Log firewall traffic.
3. En Log Viewer verifique qué Firewall Rule ID y NAT Rule ID están vigentes.
4. En el sistema de destino o en el servicio de prueba externo, verifique qué fuente IP está visible.
5. Pruebe la ruta de retorno y el comportamiento de la sesión en varios enlaces WAN.

Para DNAT o PAT:

1. Realiza la prueba desde fuera de tu propia red, no sólo desde el LAN.
2. Compare el destino público IP, el puerto externo y el servidor de destino interno.
3. Verifique Log Viewer Firewall Rule ID y NAT Rule ID.
4. Utilice Packet Capture para comprobar si los paquetes llegan y continúan hasta el servidor interno.
5. Compruebe en el servidor de destino si el firewall local, el servicio y la ruta de retorno son correctos.

Para VPN-NAT:

1. Verifique el estado del túnel y las asociaciones de seguridad.
2. Definir un flujo de prueba concreto con origen, destino y servicio.
3. Verifique la posición de la regla NAT y la búsqueda de ruta.
4. Utilice Packet Capture en ambos lados si el sitio remoto permite el acceso.
5. Incluya registros de la aplicación o del sistema de destino para que no solo se evalúe el lado del firewall.

Especialmente en ubicaciones remotas, solo se debe cambiar un caso de prueba por cambio. Si la regla de firewall, NAT, la ruta, SD-WAN y el sistema de destino se ajustan al mismo tiempo, difícilmente se podrá explicar una prueba exitosa más adelante.

Solución de problemas

Este pedido ayuda con los problemas NAT:

1. Abra Visor de registros y filtre por Origen IP, Destino IP y Servicio.
2. Compruebe qué Firewall Rule ID y NAT Rule ID se muestran.
3. Verifique la posición de control NAT.
4. Verifique la posición de la regla del firewall.
5. Utilice Diagnostics > Captura de paquetes para comprobar si los paquetes llegan y continúan.
6. Para un análisis más profundo, consulte nat_rule.log, firewall_rule.log y fwlog.log.
7. Para el contexto VPN o XFRM, verifique también charon.log, strongswan.log y xfrmi.log. Si la regla NAT aún no funciona, La regla de firewall no funciona: verifique el orden, las coincidencias y los registros y Usar la herramienta Packet Capture en WebAdmin lo ayudarán a reducirla. Los nombres de servicios y archivos de registro relevantes se pueden encontrar en Solución de problemas Sophos Firewall: Services y registros. Para casos de soporte, puede exportar los registros con Sophos Firewall Guardar registros para soporte y análisis.

NAT Lista de verificación de reglas

• La regla NAT tiene un nombre y una descripción únicos.
• Se documenta finalidad, responsable y última revisión.
• Los campos Original y Translated se probaron frente a un flujo de prueba real.
• La regla NAT está por encima de las reglas NAT más generales.
• Existen reglas de firewall adecuadas y el registro está activo.
• Los Firewall Rule ID y NAT Rule ID esperados se verificaron en Log Viewer.
• Para DNAT, la zona de destino está configurada correctamente después de NAT y la red de destino antes de NAT.
• El DNAT se probó externamente, no solo el LAN interno.
• Para servicios públicos se verificaron restricciones de fuente, IPS, alternativa WAF y nivel de parche.
• Para VPN-NAT, se documentan el enrutamiento, la ruta IPsec, SD-WAN y las redes superpuestas.
• Loopback o DNS dividido es una decisión consciente.
• Las reglas reflexivas sólo están activas si realmente es necesario reflejar el tráfico saliente del servidor.
• Las reglas NAT antiguas o temporales están deshabilitadas o eliminadas.

Preguntas frecuentes