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 que no se solapan se comunican a través de una VPN site-to-site: normalmente basta con el enrutamiento y las reglas de firewall, sin NAT.
• Las redes se solapan: planifique NAT según el tipo de VPN; no improvise con una regla MASQ genérica.
• Solo se necesita permitir o bloquear el acceso: modifique la regla de firewall; no cree 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 relacionados son 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 firewall. Translated describe el cambio que SFOS le aplica.

La regla se selecciona según estos campos:

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

Los campos Translated source (SNAT), Translated destination (DNAT) y Translated service (PAT) indican el resultado de la traducción, no criterios de coincidencia adicionales. Las reglas NAT se evalúan de arriba abajo; se aplica la primera regla que coincide.

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 regla 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 de origen. Una regla típica de LAN a WAN utiliza la red interna como Original source, la interfaz WAN como Outbound interface y MASQ como Translated source. El destino y el servicio permanecen en Original o se limitan al alcance realmente necesario.

Por defecto, MASQ utiliza la dirección de la interfaz de salida. La configuración de fábrica incluye la regla Default SNAT IPv4 para este propósito. Si no se necesita, Sophos recomienda deshabilitarla en lugar de eliminarla: puede volver a crearse cuando se crea o actualiza una interfaz WAN.

Después de una migración desde SFOS 17.5 o una versión anterior, puede aparecer una regla SNAT adicional deshabilitada al final de la tabla. Está destinada a sustituir las reglas Linked MASQ eliminadas durante la limpieza y no debe confundirse con una regla de fábrica activa.

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 de 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 forma parte de un puente no puede utilizarse como interfaz SNAT. Si una interfaz en uso se incorpora después a un puente, SFOS elimina las reglas SNAT afectadas.
• Override source translation for specific outbound interfaces permite que una regla SNAT utilice distintos orígenes traducidos según la interfaz de salida. Utilice Expand para añadir más asignaciones.
• En las VPN basadas en rutas con Any como subredes locales y remotas, o con una configuración dual-IP, MASQ puede utilizar la dirección XFRM como origen dentro del túnel. La dirección WAN sigue siendo visible en la cabecera exterior del túnel.

Antes de cambiar un puente o modificar los pools SNAT de producción, documente las reglas afectadas y después pruébelas con un flujo de tráfico realmente nuevo.

DNAT, PAT, Loopback y Reflexive Rules

DNAT cambia la dirección de destino. PAT también cambia el servicio o el puerto solicitado. El protocolo debe seguir siendo el mismo: un puerto TCP puede traducirse a otro puerto TCP y uno UDP a otro puerto UDP, pero TCP no puede traducirse 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. Después evalúa la regla de firewall. De ahí surge una correspondencia poco habitual, 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 solicitado por el cliente. Con PAT, el ejemplo oficial de Sophos incluye tanto el servicio original como el traducido en la regla de firewall.

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

Una regla NAT no sustituye esta regla de firewall. Para una configuración DNAT completa, con restricciones de origen, IPS, registro y una prueba de aceptación externa, utilice la guía DNAT.

Loopback Rule

Una Loopback Rule puede permitir que los clientes internos se conecten a través de la dirección IP pública o del FQDN público. Split DNS suele ser más transparente: dentro de la red, el mismo nombre se resuelve directamente a la dirección interna del servidor, sin necesidad de hairpin NAT.

El Server Access Assistant crea una Loopback Rule solo si se selecciona una interfaz WAN del firewall como dirección pública y External source networks and devices se establece en Any. Si se introduce una dirección IP pública o se restringen más los orígenes externos, no se crea esta Loopback Rule automática.

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 Loopback Rules y Reflexive Rules siguen siendo reglas separadas. Modificar o eliminar la regla DNAT original no las actualiza ni las elimina automáticamente. Después de cambiar la dirección pública, el destino interno o el 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 demás métodos de distribución, habilítela expresamente y configure ICMP o TCP según el servicio, para que SFOS no envíe tráfico nuevo a un servidor que haya fallado.

Elegir la distribución entre varios destinos DNAT

Elija Load balancing method según el comportamiento necesario, no solo el número de servidores:

• Round robin: las conexiones se envían por turno. Con 10.10.10.1 a 10.10.10.3, la cuarta solicitud vuelve a .1. Sirve para distribuir sin persistencia de sesión.
• First alive: todas las solicitudes van al primer servidor disponible; los demás son de reserva. El Health Check determina cuándo cambiar.
• Random: selección aleatoria, sin asignación fija de un cliente.
• Sticky IP: un hash del origen y el destino original vincula ese par a un servidor. Con Health Check habilitado, un destino disponible toma el relevo si falla. Al recuperarse el servidor original, solo vuelven las conexiones nuevas; las sesiones existentes se mantienen.
• One-to-one: primer destino original al primer destino traducido, segundo al segundo, etc. Ambas listas deben contener el mismo número de direcciones IP. Es una asignación DNAT fija, no una asignación desde un pool SNAT.

En Health check, seleccione Probe method ICMP o TCP y, para TCP, el puerto real que desea comprobar. Probe interval define el intervalo entre pruebas, Response time-out el plazo de respuesta y Deactivate host after el número de intentos fallidos. Un ping confirma la conectividad del host, no el funcionamiento de un servicio web. Adapte los intervalos al servicio: valores demasiado sensibles pueden excluir innecesariamente un destino lento. Antes de producción, compruebe la distribución con conexiones nuevas y una interrupción y recuperación planificadas. Guarde el método y los valores anteriores para revertir.

Comprobar conflictos de puertos antes de publicar

Antes de reenviar HTTPS, anote los puertos reales de WebAdmin, User Portal y VPN Portal en Administration > Admin and user settings. No deduzca qué servicio utiliza 443 de una guía NAT antigua. WebAdmin y User Portal necesitan un puerto exclusivo cada uno. Resuelva primero los conflictos con otra IP publicada u otro puerto externo; no cambie los puertos de administración sin prepararlo. Si es necesario, asegure un acceso de administración independiente y pruebe después los portales, los clientes VPN y el acceso DNAT externo por separado. La guía DNAT explica la publicación.

Linked NAT Rules y Server Access Assistant

Una Linked NAT Rule es siempre una regla SNAT vinculada a una regla de firewall. Siguen aplicándose todos los criterios de coincidencia de la regla de firewall, incluidos los usuarios y los horarios. En la regla NAT solo pueden modificarse los orígenes traducidos y las asignaciones de origen traducido específicas de cada interfaz.

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.

Limpiar con cuidado las reglas Linked MASQ migradas

Tras una migración puede aparecer un aviso bajo el filtro. Delete linked NAT rules (only MASQ; Destination: WAN) elimina solo las reglas vinculadas con origen traducido MASQ cuya regla de firewall usa exclusivamente la zona de destino WAN. No es una limpieza sin riesgos: las condiciones de usuario y horario y el orden anterior pueden formar parte del comportamiento deseado.

Guarde primero configuración, ID y flujos afectados. La regla deshabilitada Default SNAT IPv4 o Default SNAT IPv6, o una regla SNAT independiente planificada, debe sustituir la traducción necesaria en la posición correcta. Compruebe el reemplazo y las restricciones del firewall, actívelo y compare flujos nuevos permitidos y prohibidos antes de eliminar las reglas antiguas. Si hay diferencias, restaure las reglas y el orden guardados. Understood. Don’t delete rules conserva las reglas y oculta el aviso permanentemente; X lo oculta temporalmente. Ante la duda, documente antes de eliminar.

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: utilice la configuración NAT de la conexión IPsec para traducir las subredes locales y remotas, especialmente cuando se solapan. Si una regla SNAT adicional debe coincidir con el tráfico basado en políticas, establezca Outbound interface en Any; la regla no se aplica si se seleccionan interfaces WAN específicas.
• IPsec basado en rutas con subredes locales y remotas seleccionadas: utilice la configuración NAT de la conexión IPsec para traducir estas subredes.
• IPsec basado en rutas con Any/Any: utilice 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 que no se solapan generalmente no requieren NAT. Si se solapan, documente las redes reales y traducidas en ambos extremos; de lo contrario, DNS, las reglas y los registros pueden resultar ambiguos más adelante.

Para DNAT a un servidor detrás de un túnel IPsec basado en rutas, Sophos documenta una configuración SD-WAN especial: la regla DNAT utiliza MASQ como Translated source para que las respuestas regresen al firewall. La ruta SD-WAN utiliza como criterios de coincidencia 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 de 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 los ID NAT/firewall, el destino y el servicio traducidos, la salida XFRM y las respuestas en la captura. Si la salida es incorrecta, revise los criterios SD-WAN, el orden y la monitorización del gateway; si faltan respuestas, compruebe el servicio remoto y la ruta de retorno. Para otros servidores con el mismo gateway, amplíe la misma ruta SD-WAN con sus puertos externos y 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

Las reglas NAT de WebAdmin traducen el tráfico reenviado. Para el tráfico generado por el firewall y para traducir las direcciones de sus interfaces, utilice sys-traffic-nat en 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 el destino, la identidad de origen requerida, la ruta y los requisitos del extremo remoto. Después genere una nueva solicitud desde el servicio correspondiente 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.

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

Inicie sesión en Command-line console y seleccione 4 – Device Console, no Advanced Shell. El siguiente ejemplo traduce el tráfico al destino único 192.0.2.10 que sale por Port1, utilizando la dirección 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.

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 determinando el enrutamiento; sys-traffic-nat solo garantiza que la dirección alias requerida aparezca como origen. Por tanto, una entrada visible confirma la configuración, no la ruta, el retorno ni el funcionamiento del 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 solo para el primer paquete de una conexión. Las sesiones existentes conservan su traducción anterior cuando se modifica o se mueve una regla. Por tanto, para probar un cambio debe crear una conexión nueva; de lo contrario, puede estar evaluando el estado anterior.

Una prueba fiable comienza con un flujo documentado: origen, destino, servicio, interfaces de entrada y salida, y los valores esperados de Firewall Rule ID y NAT Rule ID. A continuación:

1. Cree una nueva conexión y filtre por origen, destino y servicio en Log Viewer.
2. Compare Firewall Rule ID y NAT Rule ID con los valores esperados.
3. Si el NAT Rule ID es incorrecto, compruebe las reglas situadas por encima, todos los campos Original 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 investigue el sistema de destino, la ruta de retorno y los Security Profiles.
• Firewall Rule ID es correcto, pero NAT Rule ID es incorrecto: otra regla NAT tiene precedencia o los criterios Original 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.
• Firewall Rule ID es distinto del esperado: compruebe las zonas, las redes, el servicio y el orden de las reglas de firewall.
• 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, su firewall local, la puerta de enlace predeterminada y si la ruta de retorno es asimétrica.

Para un análisis más profundo, consulte Probar una regla de firewall, Investigar por qué una regla no coincide, Clasificar los paquetes descartados y Packet Capture en WebAdmin.

Interpretar NATRule mediante la API XML

Para las automatizaciones, NATRule representa el mismo modelo Original/Translated. La descripción del objeto Add NAT policy / Edit NAT policy es idéntica en las referencias de SFOS 22 y SFOS 23 comparadas. Esto acredita el estado de la documentación, no la ejecución correcta en una compilación concreta. Antes de una tarea de escritura, se aplican las reglas centrales de seguridad de la API XML: acceso de administración restringido, validación de TLS, cuenta de servicio independiente, secretos protegidos, copia de seguridad, consulta de lectura y una operación explícita en Set confirmada para el objeto y la compilación instalada. La descripción del objeto por sí sola no constituye una solicitud ejecutable completa.

Criterios de coincidencia, traducción e identidad de la regla

• OriginalSourceNetworks contiene entradas Network repetibles para los orígenes originales; OriginalDestinationNetworks contiene entradas Network para los destinos originales. OriginalServices contiene entradas Service repetibles. Son referencias a objetos para la coincidencia antes de NAT, no permisos de firewall. Para estos nombres de redes y servicios, la referencia indica un máximo de 60 caracteres en cada caso.
• TranslatedSource, TranslatedDestination y TranslatedService son valores individuales para la traducción. Cuando un campo no cambia, el ejemplo utiliza Original; para el enmascaramiento del origen, MASQ. Indicaciones como IPAddress, IPRange, IPList, FQDN o TCPUDP_Service describen en el ejemplo el tipo de objeto adecuado, no un valor literal arbitrario que deba enviarse. Compruebe los objetos de host, rango, lista, FQDN y servicio que realmente existen, así como su compatibilidad con la compilación. Las limitaciones de PAT descritas anteriormente siguen siendo válidas. Para el valor o nombre del objeto de servicio en TranslatedService, la tabla de parámetros documenta expresamente un máximo de 60 caracteres; para TranslatedSource y TranslatedDestination, esta tabla no indica ningún máximo correspondiente.
• InboundInterfaces y OutboundInterfaces contienen, cada uno, entradas Interface repetibles. Limitan la coincidencia de interfaces, pero no crean ninguna ruta. Las condiciones de VPN/DNAT explicadas anteriormente también se aplican a las automatizaciones: la entrada y la salida VPN utilizan Any; para DNAT de direcciones públicas a privadas, la salida también es Any. Esto no elimina las restricciones de los criterios Original ni de las reglas de firewall.
• Name, directamente bajo NATRule, es el nombre obligatorio de la regla: máximo de 60 caracteres, UTF-8 permitido, sin comas. Description es opcional y está limitado a 255 caracteres. IPFamily admite IPv4 o IPv6; la referencia indica IPv4 como valor predeterminado. Status admite Enable o Disable; el estado predeterminado documentado es habilitado. Establezca deliberadamente la familia y el estado en el payload de escritura aprobado, en lugar de confiar en los valores predeterminados sin comprobarlos.
• En el ejemplo, LinkedFirewallrule está previsto únicamente para crear una Linked NAT Rule dentro de una solicitud Set. Para ello, identifique con precisión la regla de firewall existente. La vinculación no convierte la regla SNAT en una regla DNAT ni le garantiza prioridad; las limitaciones de Linked NAT siguen siendo aplicables.

Planificar por separado la posición y la anulación por interfaz

Position muestra en el ejemplo XML los valores top, bottom, after y before con esa grafía. Para la colocación relativa, After o Before contiene un Name propio con el nombre de la regla de referencia. Este nombre no es el nombre obligatorio de la regla nueva o editada. El ejemplo indica expresamente que ambos bloques solo son aplicables a solicitudes Set. Utilice únicamente la referencia correspondiente a la posición deseada; no copie a ciegas ambos bloques de ejemplo. Compruebe antes la existencia y la posición actual de la regla de anclaje y, después, verifique el orden realmente guardado. Un estado de objeto correcto no demuestra todavía que el tráfico previsto coincida primero con esta regla.

OverrideInterfaceNATPolicy es un interruptor independiente con Enable o Disable, valor predeterminado documentado Disable y relación con la traducción del origen SNAT específica de cada interfaz. La correspondiente InterfaceNATPolicyList solo forma parte del caso previsto cuando la anulación está habilitada. Contiene bloques Override repetibles con specific_interface para la interfaz de salida y specific_translatedsourceid para el origen traducido deseado en esa interfaz. Por tanto, la interfaz específica descrita como campo obligatorio es un requisito dentro de este caso condicional de anulación, no una obligación para todas las reglas NAT.

En un punto, los comentarios del ejemplo mencionan el nombre distinto OverrideInterfaceDefaultNATPolicy, mientras que el elemento y la tabla de parámetros utilizan OverrideInterfaceNATPolicy. No invente una etiqueta XML adicional a partir de esta discrepancia. La tabla describe la lista como opcional, con el valor predeterminado NULL; esto no es una instrucción para enviar el texto NULL. El ejemplo tampoco proporciona una ubicación clara para el monitorindex mencionado allí. Si una automatización depende de estos detalles sin aclarar, resuélvalos antes de escribir mediante API help de la compilación instalada o con soporte; no deduzca sintaxis ni efectos adicionales.

El balanceo de carga y las comprobaciones de estado son campos condicionales

NATMethod es relevante para el caso de distribución DNAT, no como selección obligatoria para una regla SNAT normal. La referencia de la API describe su aplicabilidad con la zona de origen WAN del Hosted Server y un Protected Server de tipo IP Range o IP List. No convierta estas denominaciones antiguas en campos XML adicionales ausentes del ejemplo. Los valores documentados son Round-robin, First_alive, Random, StickyIP y OnetoOne; el valor predeterminado de la referencia se denomina Sticky IP. La orientación para elegir entre los cinco métodos y el requisito de igual número de direcciones para One-to-one se encuentran arriba.

HealthCheck admite Enable o Disable y la tabla de la API lo describe como opcional, con valor predeterminado OFF y aplicable únicamente al balanceo de carga. Esto no significa que toda solicitud NAT necesite campos de comprobación de estado. Tampoco garantiza que First_alive deba funcionar sin comprobaciones: las instrucciones concretas de NAT hacen obligatorio el Health Check para First alive. Para este caso, planifique deliberadamente la comprobación y sus valores y verifíquelos en el estado guardado, en lugar de confiar en el valor predeterminado general OFF.

Cuando el Health Check está habilitado, los valores de comprobación se encuentran en el bloque LoadBalance:

• ProbeMethod: ICMP o TCP. La indicación de obligatoriedad se aplica aquí al caso de comprobación activa.
• Port: solo para TCP, rango 1–65535; no deduzca una obligación general de especificar un puerto para ICMP.
• ProbeInterval: intervalo de comprobación en segundos, rango 5–65535, valor predeterminado documentado 60. El rango procede de la tabla de parámetros; el elemento vacío del ejemplo no establece ningún valor numérico propio.
• ResponseTimeOut: plazo de respuesta en segundos, rango 1–10, valor predeterminado documentado 2.
• DeactivateHostAfter: número de intentos de comprobación fallidos hasta la desactivación, opcional, rango 1–10, valor predeterminado documentado 3.

No separe las indicaciones de obligatoriedad del método, el intervalo y el plazo de respuesta de su contexto de Health Check habilitado. Estos datos también confirman únicamente el contrato de API descrito. El funcionamiento de la comprobación, el servicio y la conmutación por error deseada debe verificarse con el nuevo flujo de tráfico descrito anteriormente y una prueba planificada de interrupción y recuperación.

Evaluar las respuestas de NATRule de forma específica para el objeto

Las siguientes correspondencias proceden de Status Message Information para este objeto. Son códigos de estado de objetos XML, no códigos de estado HTTP. Los valores Message.* son claves de mensajes sin resolver de la referencia, no textos de mensajes verificados de un firewall. Por tanto, evalúe conjuntamente la operación, el código, la respuesta real y el estado guardado; no deduzca un límite ni la seguridad de un reintento a partir del nombre de la clave.

• Add NAT policy: 200 está asociado a Message.NATPolicyAddSuccess, 500 a Message.NATPolicyAddFail y 502 a Message.NATPolicyRecordExists.
• Edit NAT policy: 200 está asociado a Message.NATPolicyUpdateSuccess, 500 a Message.NATPolicyUpdateFail y 502 a Message.NATRuleUpdateRecordExist. En particular, la clave de 502 difiere de la utilizada para la creación.

Para ambas operaciones, Add NAT policy y Edit NAT policy, se documentan además las mismas correspondencias:

Por tanto, en particular, 504 no debe interpretarse aquí únicamente según la tabla general de la API como una eliminación fallida debido a una referencia: estas filas de NATRule corresponden a Add/Edit e incluyen la clave de conflicto de puertos. Tampoco los códigos 548 y 549, pese a compartir la misma clave, acreditan un número máximo concreto de servidores.

Antes de cada nuevo intento de escritura, incluso tras un timeout o un éxito aparente, lea la entrada NAT realmente guardada y compruébela en Rules and policies > NAT rules: nombre, familia, estado, valores Original/Translated, interfaces, asignaciones de anulación, valores de comprobación condicionales y posición. Compare la respuesta con el estado guardado previamente; ante conflictos, no intente eludirlos cambiando nombres, ampliando criterios o repitiendo a ciegas. Las diferencias sin aclarar obligan a detener la tarea. Solo después de comprobar el estado, verifique ambos Rule IDs y la traducción real con una sesión nueva. Para revertir, restaure el estado guardado y el orden, y tenga en cuenta las reglas derivadas por separado; la publicación práctica del servidor sigue descrita en la guía DNAT.

FAQ