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

NAT modifica las direcciones o los puertos de un paquete. No determina si la conexión está permitida ni crea una ruta. Para que el flujo funcione, la regla NAT, la regla de firewall, el enrutamiento y la ruta de retorno deben ser coherentes.

Por tanto, el mejor punto de partida no es preguntar «¿Qué tipo de NAT necesito?», sino: ¿Qué dirección o puerto debe cambiar entre la entrada y la salida? Si no hay una respuesta clara, la solución suele estar en el enrutamiento o en la regla de firewall, no en NAT.

⚠️ Una regla NAT no concede ningún permiso. Si la regla de firewall permite el tráfico, pero no coincide ninguna regla NAT, SFOS reenvía el paquete sin traducirlo. Si falta la regla de firewall correspondiente, el paquete se descarta y se registra.

¿Cuándo debe utilizarse NAT?

• Los clientes de LAN necesitan acceso a Internet: generalmente SNAT con MASQ.
• Un servicio interno debe ser accesible a través de una dirección pública: DNAT; para HTTP/HTTPS, compruebe WAF primero.
• Los puertos externos e internos difieren: traducción del servicio Translated service (PAT).
• Los clientes internos utilizan el nombre público de un servidor interno: dé prioridad a Split DNS o utilice una Loopback Rule específica.
• Las redes no superpuestas se comunican sobre un sitio a sitio VPN: normalmente routing y reglas de cortafuegos sin NAT.
• Redes superpuestas: plan NAT basado en el tipo VPN; no improvisar con una regla MASQ genérica.
• Solo permitir o bloquear el acceso: cambiar la regla del cortafuegos; no crear una regla NAT.

Para publicar un servidor, Publicar un servidor con DNAT en Sophos Firewall explica el asistente, la regla manual, el refuerzo de la seguridad, la puesta en producción y la reversión. Este artículo presenta el modelo NAT para poder interpretar estas reglas y acotar los errores.

Otros casos especiales estrechamente relacionados NAT64 con Direct Web Proxy, Proxy ARP para direcciones IPv4 públicas adicionales, y NAT para problemas de IPsec.

Cómo interpretar Original y Translated correctamente

En Rules and policies > NAT rules > Add NAT rule, Original describe el paquete cuando llega al cortafuegos. Translated describe el cambio que SFOS aplica a él.

La regla es seleccionada sobre la base de estos campos:

• Original source
• Original destination
• Original service
• Inbound interface
• Outbound interface

El Translated source (SNAT), Translated destination (DNAT), y Translated service (PAT) campos son resultados, no criterios de coincidencia adicionales. Las reglas de NAT se evalúan de arriba a abajo; la primera regla coincidente gana.

Las reglas NAT están disponibles para IPv4 e IPv6. Antes de crearlas, seleccione la familia de direcciones en Rules and policies > NAT rules; los valores IPv4 de los ejemplos no corresponden a una regla IPv6. Add NAT rule > New NAT rule abre la configuración manual. Las nuevas reglas están habilitadas de forma predeterminada. Rule position ofrece Top y Bottom; después puede cambiar el orden arrastrando la regla. Antes de Save, compruebe los criterios y la posición para evitar que la nueva regla capture tráfico de producción sin querer.

Dos ejemplos de paquetes

Un cliente 10.10.10.80 se conecta a 198.51.100.20:443 mediante Port2. Una regla SNAT solo puede sustituir el origen por MASQ. El destino y el servicio permanecen Original.

Al publicar un servicio, un cliente externo se conecta a 203.0.113.10:5555. DNAT cambia el destino a 172.16.16.10; PAT cambia el servicio a 443. La norma resultante es:

• Original destination: 203.0.113.10
• Original service: TCP 5555
• Translated destination (DNAT): 172.16.16.10
• Translated service (PAT): TCP 443

PAT no es un tipo independiente de traducción de direcciones junto a SNAT y DNAT, sino la traducción de puertos o servicios dentro de una regla NAT.

SNAT y MASQ para tráfico de salida

SNAT cambia la dirección fuente. Una norma típica de LAN a WAN utiliza la red interna como Original source, la interfaz WAN como la Outbound interface, y MASQ como el Translated source. El destino y el servicio permanecen Original o están restringidos al alcance realmente requerido.

Por defecto, MASQ utiliza la dirección de la interfaz de salida. La configuración de la fábrica incluye Default SNAT IPv4 para este propósito. Si no es necesario, Sophos recomienda desactivarlo en lugar de borrarlo: puede ser recreado cuando se crea o actualiza una interfaz WAN.

Después de una migración desde SFOS 17.5 o antes, una regla SNAT deshabilitada adicional puede aparecer en la parte inferior de la tabla. Está destinado a reemplazar las reglas de MASQ limpiadas y no debe confundirse con una regla de fábrica de uso activo.

Varios clientes o servidores internos pueden compartir la misma IP pública de origen: SFOS distingue sus conexiones mediante números de puerto diferentes. Esta asignación de puertos de origen no es lo mismo que reenviar un servicio mediante DNAT a un servidor.

Crear una regla SNAT LAN-WAN independiente

Una regla SNAT independiente puede atender a varias reglas de firewall. Compruebe primero las reglas NAT existentes, la ruta, la interfaz de salida y el retorno; guarde el estado anterior con los ID y las posiciones. El ejemplo solo permite HTTPS desde la red de clientes a un destino de prueba concreto; sustituya todas las direcciones e interfaces por valores propios.

1. Abra Rules and policies > NAT rules, seleccione IPv4 y Add NAT rule > New NAT rule. Establezca Rule name, por ejemplo LAN-Web-Standalone-MASQ. En Rule position, elija Top o Bottom y después arrastre deliberadamente la regla por encima de otras coincidentes más generales; no la coloque siempre en primer lugar.
2. Establezca Original source en Clients_LAN (10.10.10.0/24), Original destination en un objeto host para 198.51.100.20 y Original service en HTTPS. La dirección de documentación no es un servidor de prueba real. Para acceso general a Internet puede ampliar deliberadamente el destino, manteniendo los servicios limitados a los necesarios.
3. Establezca Translated source (SNAT) en MASQ, y Translated destination (DNAT) y Translated service (PAT) en Original. Seleccione la interfaz LAN real en Inbound interface, Port2 en el ejemplo, y la WAN real en Outbound interface, aquí Port1. Seleccione Save y anote el NAT Rule ID.
4. En Rules and policies > Firewall rules, seleccione IPv4 > Add firewall rule > New firewall rule si no existe una regla de permiso adecuada. Configure nombre y posición, Action Accept, Source zones LAN, Source networks and devices Clients_LAN, Destination zones WAN, Destination networks con el mismo destino y Services HTTPS. Configure la seguridad apropiada y Log firewall traffic, luego Save. No cree otra Linked NAT Rule.
5. Establezca una nueva conexión HTTPS a su destino de prueba y ciérrela normalmente. Compare ambos Rule IDs en Log Viewer; Packet capture debe mostrar la dirección WAN de origen esperada a la salida. Si coincide una regla NAT incorrecta, revise primero las superiores; si no hay respuesta, revise enrutamiento y retorno. Para revertir, deshabilite solo las reglas añadidas y restaure las posiciones modificadas; no elimine una regla de permiso compartida. Verifique el estado anterior con una nueva sesión.

Crear una regla LAN a WAN con NAT vinculado

Para permitir un tráfico IPv4 concreto, puede vincular SNAT al crear la regla de firewall. Compruebe primero si una regla SNAT existente ya traduce el flujo como necesita; en ese caso, no hace falta otra Linked NAT Rule. La ruta y el camino de retorno deben ser correctos independientemente de NAT.

1. Abra Rules and policies > Firewall rules, seleccione IPv4 y cree una regla mediante Add firewall rule > New firewall rule. Elija un nombre claro, como LAN-Web-Out, y una posición adecuada; establezca Action en Accept y active Log firewall traffic.
2. Establezca Source zones en LAN y limite Source networks and devices a la red de clientes que necesita acceso. Por ejemplo, utilice un objeto de red Clients_LAN para 10.10.10.0/24; adapte el nombre y la subred a su entorno. Establezca Destination zones en WAN. En Destination networks, seleccione los destinos necesarios y, en Services, solo los servicios requeridos, como HTTPS para este flujo web. Any no es un requisito general. Tenga en cuenta DNS y los demás servicios necesarios por separado.
3. Seleccione Create linked NAT rule. Asigne a la regla NAT un nombre propio, como LAN-Web-MASQ, y una posición adecuada. Establezca Translated source (SNAT) en MASQ: este flujo debe utilizar la dirección de la interfaz de salida efectiva, mientras que la regla de firewall sigue limitando los orígenes, los destinos y los servicios.
4. Seleccione primero Save dentro de la configuración de NAT vinculado y después pulse de nuevo Save para guardar la regla de firewall. Guardar únicamente el diálogo de NAT anidado no completa el procedimiento.
5. Compruebe la regla de firewall en Firewall rules y la regla SNAT vinculada en NAT rules; anote ambas entradas y sus Rule IDs. Revise el orden de cada tabla por separado. Una regla NAT coincidente situada por encima puede tener prioridad; la vinculación no garantiza precedencia.
6. Desde un cliente autorizado, establezca una conexión realmente nueva al destino y servicio permitidos y después cierre la conexión de prueba de forma normal para que pueda generarse un registro de sesión. Filtre ese flujo en Log Viewer y compare Firewall Rule ID y NAT Rule ID con los ID anotados. Si el ID de firewall es incorrecto, compruebe primero los criterios y el orden de las reglas de firewall; si el ID de NAT es incorrecto, compruebe primero las reglas NAT superiores. La mera presencia de ambas entradas no confirma que el acceso a Internet funcione.

Limitaciones importantes SNAT

Además de MASQ, Translated source (SNAT) admite una IP individual o un rango IP. La descripción de SFOS 22 menciona expresamente cualquier IP asignada a una interfaz como origen y Add para crear un objeto IP/rango. La descripción de los tipos NAT de SFOS 23 sigue incluyendo IP individuales y rangos; que falten esas frases en la descripción Add no significa que se haya eliminado el soporte. La dirección fija debe ser alcanzable en su entorno y compatible con el retorno previsto.

• Un rango configurado en Translated source no crea una asignación fija de uno a uno. SFOS utiliza la siguiente dirección disponible en el rango.
• Una interfaz pública que es miembro de un puente no puede servir como una interfaz fuente NAT. Si una interfaz en uso se hace más tarde un miembro del puente, SFOS elimina las reglas SNAT afectadas.
• Override source translation for specific outbound interfaces permite que una regla SNAT utilice diferentes fuentes traducidas para diferentes interfaces de salida. Utilice Expand para añadir más asignaciones.
• Para VPNs basados en la ruta con Any como subredes locales y remotas, o con una configuración dual-IP, MASQ puede utilizar la dirección XFRM como fuente interna. La dirección WAN sigue siendo visible en el encabezado del túnel exterior.

Antes de cambiar un puente o modificar los pools SNAT de producción, documentar las reglas afectadas y luego probarlas utilizando un nuevo flujo de tráfico genuino.

DNAT, PAT, Loopback y Reflexive Rules

DNAT cambia la dirección de destino. PAT también cambia el servicio o el puerto que se está abordando. El protocolo debe seguir siendo el mismo: TCP puede ser traducido a otro puerto TCP y UDP a otro puerto UDP, pero TCP no puede ser traducido a UDP.

Si se seleccionan varios servicios originales o Any, Translated service (PAT) debe ser Original. Un reenvío de puerto inequívoco utiliza un servicio original concreto y uno traducido concreto. Translated destination (DNAT) puede ser una dirección IP o un FQDN. La traducción de servicios admite un único puerto de destino o el mismo número de puertos originales y traducidos: por ejemplo, varios puertos de un solo servicio original a uno (many-to-one), o conjuntos de puertos de igual tamaño (many-to-many). Many-to-many exige igual número de puertos; varios servicios originales seleccionados por separado no permiten traducción PAT. El protocolo siempre debe mantenerse.

La regla del cortafuegos correspondiente a DNAT

Para el tráfico de entrada, SFOS determina primero la regla DNAT coincidente. Luego evalúa la regla del cortafuegos. Esto resulta en una asignación inusual pero importante:

• Destination zone: la zona del destino interno después de DNAT, como DMZ.
• Destination networks: la dirección de destino pública antes de DNAT.
• Services: sin PAT, el servicio que se accede. Con PAT, el ejemplo oficial Sophos incluye tanto los servicios originales como traducidos en la regla del cortafuegos.

En la dirección inversa, la regla del cortafuegos se evalúa primero; SFOS aplica la regla SNAT coincidente.

Una regla NAT no reemplaza esta regla de cortafuegos. Para una configuración DNAT completa, incluyendo restricciones de origen, IPS, registro y una prueba de aceptación externa, use el DNAT runbook.

Loopback Rule

Un Loopback Rule puede permitir que los clientes internos se conecten a través de la dirección IP pública o FQDN pública. Split DNS es a menudo más transparente: internamente, el mismo nombre se resuelve directamente a la dirección interna del servidor, evitando la necesidad de horquilla NAT.

El Asistente de Acceso al Servidor crea un Loopback Rule solo si se selecciona una interfaz de firewall WAN como dirección pública y External source networks and devices se establece Any. Entrar una dirección IP pública o una fuente externa más restrictiva no crea este Loopback Rule automático.

En la configuración DNAT manual, Create loopback rule es una opción independiente. La regla DNAT de partida debe usar Original source Any, Translated source (SNAT) MASQ y Translated destination (DNAT) distinta de Original. No son los campos del asistente. No quite una restricción de orígenes externos solo para obtener loopback: valore primero Split DNS o una regla interna planificada por separado. Tras guardar, pruebe por separado el acceso interno y las restricciones externas.

Reflexive Rule

Una Reflexive Rule crea una regla SNAT inversa para una regla DNAT. Invierte los criterios de coincidencia y puede traducir el tráfico saliente del servidor con la identidad pública correspondiente. Si el destino original no es una dirección IP o se traduce, utiliza MASQ como origen traducido.

Durante la creación manual de DNAT, Create reflexive rule genera esta regla espejo; Create loopback rule es independiente. Las reglas generadas usan el ID y el nombre de la regla original, pero siguen siendo entradas separadas. Para revertir, identifique y deshabilite cada entrada generada por separado y compruebe con nuevas conexiones internas y externas.

Las reglas de retroceso y reflejo siguen siendo reglas separadas. Cambiar o eliminar la regla DNAT original no actualiza o elimina automáticamente. Después de cambiar la dirección pública, destino interno o servicio, compruebe las reglas derivadas por separado.

Si una regla DNAT distribuye el tráfico entre varios destinos internos, SFOS los considera disponibles si no hay un Health check. La comprobación es obligatoria para First alive; para los otros métodos de distribución, debe ser habilitado deliberadamente y configurado con ICMP o TCP para adaptarse al servicio, de modo que SFOS no envía tráfico nuevo a un servidor fallido.

Linked NAT Rules y Server Access Assistant

Una Linked NAT Rule es siempre una regla SNAT vinculada a una regla de cortafuegos. Todos los criterios de coincidencia de la regla del cortafuegos siguen siendo aplicables, incluyendo usuarios y horarios. Sólo las fuentes traducidas y las fuentes traducidas específicas de la interfaz pueden cambiarse en la regla NAT.

La vinculación no evita el orden normal de NAT: una regla NAT independiente situada más arriba puede coincidir primero. Si una regla SNAT genérica ya cubre el mismo tráfico, Sophos no recomienda añadir otra Linked NAT Rule. En modo MTA, SFOS crea una automáticamente.

El Server access assistant (DNAT) crea una regla DNAT, una Reflexive Rule y una regla de firewall. Añade una Loopback Rule solo para la combinación descrita de interfaz WAN y origen externo Any. Coloca las reglas al principio de las tablas y las habilita. Después compruebe los orígenes, las posiciones, las reglas adicionales generadas y el uso de alias IP. Para un alias IP, inicialmente utiliza la interfaz física como origen traducido en las Reflexive o Loopback Rules; para utilizar la dirección alias, seleccione manualmente el IP Host correspondiente.

Diferenciar NAT, VPN y SD-WAN

NAT no cambia una decisión de enrutamiento. Incluso después de la traducción, SFOS necesita una ruta al destino. Para el tráfico VPN, el lugar correcto para configurar la traducción también depende del tipo de túnel:

• IPsec basado en políticas: use la configuración NAT de la conexión IPsec para traducir los subredes locales y remotos, especialmente cuando se solapan. Si una regla adicional SNAT debe coincidir con el tráfico basado en políticas, establezca su Outbound interface a Any; no se aplica cuando se seleccionan interfaces WAN específicas.
• IPsec basado en la ruta con subredes locales y remotas seleccionadas: use la configuración NAT de la conexión IPsec para traducir estas subredes.
• IPsec basado en la ruta con Any/Any: use las reglas NAT para el tráfico reenviado.

Para tráfico VPN en reglas NAT, establezca Inbound interface en Any. Para VPN y DNAT de IP públicas a privadas, Outbound interface también debe ser Any. Es un requisito de coincidencia de interfaces, no un permiso para cualquier origen o servicio; los criterios Original y las reglas de firewall siguen restringiéndolos.

Las redes no superpuestas generalmente no requieren NAT. Para las redes superpuestas, documente las redes reales y traducidas en ambos lados; de lo contrario, DNS, reglas y registros se vuelven ambiguos más adelante.

Para DNAT a un servidor detrás de un túnel IPsec basado en la ruta, Sophos documenta una configuración SD-WAN especial: la regla DNAT utiliza MASQ como el Translated source para que las respuestas regresen al cortafuegos. La ruta SD-WAN coincide con la dirección WAN original o la interfaz WAN como destino y, cuando se utiliza PAT, el puerto externo. El objeto gateway apunta a la interfaz XFRM. No aplique este caso especial a servidores locales como patrón general DNAT.

Acceder a un servidor remoto con DNAT y una ruta SD-WAN

Este procedimiento IPv4 solo corresponde a un servidor detrás del firewall remoto. Compruebe primero las conexiones IPsec basadas en rutas en ambos firewalls, el estado del túnel, la conectividad remota, los orígenes autorizados, el servicio, el retorno y el orden NAT/SD-WAN existente. Guarde configuración y posiciones afectadas. El ejemplo usa TCP 5555 externo y TCP 443 interno, no RDP público; sustituya las direcciones de documentación por valores propios. Siguen siendo necesarios un permiso de firewall separado y el refuerzo de seguridad.

1. En Hosts and services > IP host > Add, cree Remote_Web: IP version IPv4, Type IP, IP address con la dirección del servidor remoto, por ejemplo 172.16.16.10; Save.
2. En Routing > Gateways, IPv4 gateway > Add, elija un nombre claro. Establezca Gateway IP en la dirección del gateway remoto, por ejemplo 10.12.13.2, e Interface en su interfaz XFRM, por ejemplo xfrm1-10.12.13.1. En Monitoring condition, introduzca la dirección IP de un host realmente alcanzable detrás del gateway; compruebe el estado del gateway y del túnel antes de publicar.
3. En Rules and policies > NAT rules > Add NAT rule > New NAT rule, cree una regla IPv4 con nombre. Limite Original source a los orígenes externos autorizados. Establezca Original destination en la interfaz WAN publicada, como #Port1, Translated source (SNAT) en MASQ, Translated destination (DNAT) en Remote_Web, Original service en un objeto TCP 5555 y Translated service (PAT) en TCP 443. En este caso VPN-DNAT, ambos campos de interfaz deben ser Any. Revise la posición y seleccione Save. En este caso especial, MASQ proporciona el retorno al firewall.
4. En Routing > SD-WAN routes, seleccione IPv4 > Add e introduzca un nombre. En Destination networks, quite Any y seleccione la misma interfaz WAN original #Port1, no Remote_Web. En Services, quite Any y seleccione el servicio externo TCP 5555, no TCP 443. En Link selection settings, elija Primary and Backup gateways y configure Primary gateway con el gateway remoto; elija un respaldo solo si su ruta remota existe y se ha comprobado. Seleccione Save.
5. Establezca una conexión nueva desde un origen externo autorizado. Compruebe ID NAT/firewall, destino y servicio traducidos, salida XFRM y respuestas en la captura. Si la salida es incorrecta, revise criterios SD-WAN, orden y monitorización del gateway; si faltan respuestas, servicio remoto y retorno. Para otros servidores con el mismo gateway, amplíe la misma ruta SD-WAN con sus puertos externos/direcciones WAN; utilice rutas separadas para gateways diferentes. Las combinaciones añadidas deben seguir restringidas por NAT y firewall.

Si falla, deshabilite la nueva regla DNAT remota, elimine la nueva ruta SD-WAN o restaure su configuración anterior y las posiciones. No elimine objetos gateway/host compartidos. Revierta por separado las reglas NAT derivadas y verifique el flujo anterior con una nueva conexión.

Traducir el tráfico generado por el firewall con sys-traffic-nat

Reglas NAT en WebAdmin traducen tráfico reenviado. Para el tráfico generado por el firewall y para traducir direcciones de interfaz de firewall, uso sys-traffic-nat en el Device Console.

Motivos habituales para traducir el origen mediante CLI:

• Enviar solicitudes DHCP y de autenticación generadas por el firewall a través de IPsec site-to-site; la traducción también puede apoyar solicitudes a servicios del firewall por túneles VPN. No sustituye la configuración de servicios y VPN.
• Usar direcciones alias cuando hay más enlaces WAN que interfaces WAN físicas, traduciendo la interfaz física al alias adecuado.
• Enviar correo con el origen alias requerido por el relay ascendente o el registro MX.
• Ocultar direcciones internas ante destinos WAN, por ejemplo solicitudes DHCP de una interfaz LAN; usar una identidad de origen específica para destinos MPLS internos o determinados servidores web.

Anote previamente destino, identidad de origen requerida, ruta y requisitos de la contraparte. Después vuelva a activar el servicio concreto y compruebe el origen real y la respuesta en la captura. Una entrada CLI no demuestra por sí sola que funcionen DHCP, autenticación o correo.

El siguiente ejemplo traduce el tráfico al destino único 192.0.2.10 que deja pasar Port1, utilizando la dirección de alias 203.0.113.10:

show advanced-firewall
set advanced-firewall sys-traffic-nat add destination 192.0.2.10 netmask 255.255.255.255 interface Port1 snatip 203.0.113.10
show advanced-firewall

El destino, la máscara de red, la interfaz y la dirección SNAT deben corresponder al entorno. Para un único host se requiere 255.255.255.255; una máscara más amplia abarca toda la red de destino correspondiente. Sin interface, la entrada se aplica al tráfico dirigido al destino indicado a través de cualquier interfaz del firewall.

⚠️ Este comando Device Console cambia el tráfico generado por el sistema. Guarde primero la salida completa de show advanced-firewall. Las entradas CLI NAT se procesan en el orden que se muestra allí.

Para revertir el cambio, utilice la misma asignación completa con delete:

set advanced-firewall sys-traffic-nat delete destination 192.0.2.10 netmask 255.255.255.255 interface Port1 snatip 203.0.113.10
show advanced-firewall

Por defecto, el tráfico generado por el sistema utiliza WAN Link Load Balancing. Con un alias IP, la interfaz principal sigue siendo decisiva para la decisión de enrutamiento; sys-traffic-nat sólo garantiza que la dirección de alias requerida aparezca como fuente. Por lo tanto, una entrada visible confirma la configuración, no la ruta, la ruta de retorno o el servicio.

Modificar y probar reglas NAT de forma segura

Utilizar la tabla y los contadores de forma deliberada

En Rules and policies > NAT rules, IPv4 o IPv6 selecciona la familia de reglas. Disable filter oculta el filtro, Enable filter lo muestra y Reset filter lo restablece. Ocultar el filtro no deshabilita una regla NAT. Compruebe que las entradas correctas estén visibles antes de cambiar nada.

Las reglas seleccionadas pueden deshabilitarse juntas con Disable o eliminarse con Delete. Arrastre el Rule handle para mover una regla; las específicas deben preceder a las generales. More options ofrece el interruptor de activación, edición, eliminación e inserción de una regla adyacente. Unlink rule quita la vinculación con la regla de firewall: documente antes esa dependencia y no lo utilice como atajo de diagnóstico.

Reset usage count en More options restablece el contador de uso. Anote primero el valor y la hora, genere un nuevo flujo de prueba y compruebe el incremento junto con los Rule IDs; un contador no identifica por sí solo el flujo. El valor anterior no se recupera. Antes de modificar reglas, guarde ID, criterios, estado y orden, prefiera deshabilitar a eliminar y cambie solo las entradas seleccionadas. Ante problemas, restaure estado y posiciones y pruebe con una sesión nueva; una regla eliminada debe recrearse a partir de la configuración guardada.

SFOS evalúa NAT sólo para el primer paquete de una conexión. Las sesiones existentes conservan su traducción anterior cuando una regla se cambia o se mueve. Por lo tanto, una prueba de cambio debe crear una nueva conexión; de lo contrario, usted puede estar evaluando el estado antiguo.

Una prueba confiable comienza con un flujo documentado: fuente, destino, servicio, interfaces de entrada y salida, y el Firewall Rule ID esperado y NAT Rule ID. Entonces:

1. Cree una nueva conexión y filtre por origen, destino y servicio en Log Viewer.
2. Compare el esperado Firewall Rule ID y NAT Rule ID.
3. Si el NAT Rule ID está equivocado, compruebe las reglas sobre él, todo Original campos y las interfaces.
4. En Diagnostics > Packet capture, verifique que el paquete llega y se envía con las direcciones esperadas.
5. Compruebe la ruta, la ruta de retorno, el sistema de destino y su firewall local.

Para DNAT, realice al menos una prueba desde fuera de la red. El acceso interno al nombre público solo comprueba Split DNS o loopback, no la publicación efectiva desde Internet.

Interpretar correctamente las conclusiones

• Firewall Rule ID y NAT Rule ID son correctos: la coincidencia es correcta; después investigar el sistema de destino, la ruta de retorno y Security Profiles.
• Firewall Rule ID es correcto, NAT Rule ID está mal: otra regla NAT tiene precedencia, o Original criterios no coinciden.
• No hay NAT Rule ID aunque se esperaba una traducción: no coincide ninguna regla NAT; si la regla del firewall permite el flujo, continúa sin traducción.
• Diferente Firewall Rule ID: zonas de control, redes, servicio y orden de reglas de cortafuegos.
• No hay ninguna entrada de registro: el registro está desactivado o el tráfico no llega al firewall. Capture en la interfaz WAN o de entrada y compruebe los routers anteriores o las reglas de la nube.
• DNAT coincide, pero el servidor no responde: Compruebe el servicio del servidor, firewall local, pasarela predeterminada y la ruta de retorno asimétrica.

Para un análisis más profundo, vea Prueba una regla de cortafuegos, Investigar reglas que coincidan, Clasificar paquetes caídos, y Packet Capture en WebAdmin.

FAQ