Publicar servidores con DNAT en Sophos Firewall
Con DNAT se pública un servidor interno mediante una dirección IP pública o un puerto público. Sophos Firewall reenvía el tráfico entrante al servidor interno de destino. Ejemplos típicos son servidores web, reverse proxies, VPN gateways u otros servicios en una DMZ.
Esta guía KB muestra qué puntos se deben revisar antes y después de una regla DNAT y cómo proteger la publicación de la forma más restrictiva posible.
Requisitos
- Dirección IP pública o interfaz WAN
- Servidor interno con dirección IP fija
- Servicio y puerto conocidos, por ejemplo TCP 443
- Regla de firewall adecuada
- Opcional: IPS, Webserver Protection o Reverse Proxy según el servicio
⚠️ DNAT publica un servicio interno hacia el exterior. Cada servicio publicado aumenta la superficie de ataque. Publica solo lo realmente necesario y limita origen, puerto y destino tanto como sea posible.
Aclaraciones previas
Antes de crear la regla, conviene responder estas preguntas:
- ¿Qué IP pública o interfaz WAN se usará?
- ¿Qué puerto externo debe ser accesible?
- ¿A qué IP interna se reenviará?
- ¿El puerto se mantiene igual o se traduce?
- ¿El acceso debe permitirse desde cualquier lugar o solo desde redes de origen concretas?
- ¿Hay que tener en cuenta Source NAT o Reflexive NAT?
- ¿Se necesita una Loopback rule para clientes internos que usan el FQDN público?
- ¿Se pública un único servidor interno o varios servidores con Load Balancing?
- ¿Ya existe una regla que use el mismo puerto?
- ¿Sophos Firewall está directamente en Internet o detrás de un router del proveedor?
- ¿También deben abrirse reglas en una Cloud Security Group?
Esta información evita conflictos posteriores con reglas NAT o de firewall existentes.
Si la firewall está detrás de un router
DNAT también funciona cuando Sophos Firewall no tiene directamente la dirección IP pública, sino que está detrás de un router NAT del proveedor.
En ese caso se necesitan dos reenvíos:
- En el router del proveedor, el puerto público se reenvía a la IP WAN de Sophos Firewall.
- En Sophos Firewall, el puerto se reenvía mediante DNAT al servidor interno.
Muchos routers de proveedor ofrecen port forwarding clásico o una función como Exposed Host o DMZ Host. Con una función Exposed Host, a menudo se reenvían muchos o todos los puertos entrantes a la firewall. Puede ser práctico, pero debe protegerse conscientemente, porque el control real queda entonces completamente en Sophos Firewall.
Si no hay una IP pública fija, se puede usar DynDNS. Sophos Firewall puede configurar Dynamic DNS para que un nombre DNS apunte siempre a la IP pública actual. Aun así, es importante que el port forwarding en el router del proveedor apunte a Sophos Firewall.
En entornos cloud se aplica el mismo principio. En Azure, la regla DNAT en Sophos Firewall por sí sola no basta. Además deben abrirse las Inbound rules correspondientes en la Network Security Group; de lo contrario, el tráfico ni siquiera llegará a la firewall.
Crear la regla DNAT
Un ejemplo típico de DNAT:
- Original source:
Anyo redes de origen definidas - Original destination: IP WAN o interfaz WAN
- Original service:
HTTPS - Translated destination: servidor interno
- Translated service: sin cambios o puerto interno de destino
Procedimiento:
- Abrir Rules and policies.
- Ir a la sección NAT rules.
- Crear una nueva regla NAT.
- Definir Original Source, Destination y Service.
- Establecer Translated Destination en el servidor interno.
- Opcionalmente definir Translated Service.
- Guardar y activar la regla.
Si solo deben acceder unas pocas direcciones IP externas, Original Source no debería ser Any, sino limitarse a esos orígenes.

Entender correctamente Original y Translated
En reglas NAT es importante distinguir entre Original y Translated.
- Original source / destination / service describe el tráfico tal como llega a Sophos Firewall.
- Translated source / destination / service describe el tráfico tal como sale de Sophos Firewall después de la traducción.
Para una regla DNAT entrante significa:
- Original destination es la IP pública o dirección WAN de la firewall.
- Original service es el puerto externo al que se conecta el cliente.
- Translated destination (DNAT) es el servidor interno.
- Translated service (PAT) es el puerto interno del servidor de destino, si debe traducirse el puerto.
- Translated source (SNAT) suele quedarse en Original en reglas DNAT normales.
Sophos describe los campos en la guía oficial añadir una regla NAT.
Port Forwarding y PAT
Port Forwarding es técnicamente una Service Translation. En Sophos Firewall se usa para ello Translated service (PAT).
Ejemplo:
- Externo: TCP
20120 - Interno: TCP
22
El cliente externo se conecta al puerto 20120, pero Sophos Firewall lo reenvía internamente al puerto SSH 22. Esto puede tener sentido, pero no sustituye una restricción de acceso. Cambiar el puerto externo puede reducir algo de ruido de fondo, pero no hace seguro un servicio.
Importante: el protocolo debe mantenerse. TCP puede traducirse a otro puerto TCP, UDP a otro puerto UDP. TCP a UDP no es una traducción de puerto válida.
Si se pública HTTPS, también hay que comprobar si existen conflictos con WebAdmin o User Portal de Sophos Firewall. Por defecto, la consola de administración usa HTTPS puerto 4444, y User Portal HTTPS puerto 443. Si hay solapamientos, los puertos propios de la firewall y los servicios publicados deben separarse correctamente.
Loopback, Reflexive y Linked NAT Rules
Sophos conoce varias opciones NAT que se confunden fácilmente:
- Loopback rule: Ayuda cuando clientes internos deben acceder a un servidor interno mediante la IP pública o el nombre DNS público.
- Reflexive rule: Crea una regla SNAT reflejada a partir de una regla DNAT, para que el tráfico de retorno o determinadas direcciones opuestas se traduzcan correctamente.
- Linked NAT rule: Se crea desde una regla de firewall y es una regla SNAT vinculada. No es lo mismo que una regla DNAT entrante para un servidor publicado.
Para publicaciones clásicas de servidores, lo más claro suele ser una regla DNAT independiente junto con una regla de firewall adecuada. Linked NAT Rules pueden tener sentido cuando una regla de firewall necesita directamente una traducción SNAT específica. Para entornos generales, Sophos recomienda mantener las reglas NAT lo más independientes y sencillas posible, en lugar de crear muchas reglas NAT vinculadas innecesariamente por cada regla de firewall.
Load Balancing y Health Check
Si se publican varios servidores internos detrás de una IP pública, DNAT también puede usarse para Load Balancing o Failover.
Métodos posibles, por ejemplo:
- Round robin
- First alive
- Random
- Sticky IP
- One-to-one
Si la firewall debe detectar si un servidor de destino está disponible, debe configurarse un Health check. Sin Health Check, la firewall puede reenviar tráfico a un servidor que no esté accesible.
Revisar la regla de firewall
Una regla NAT por sí sola no permite el tráfico automáticamente. Además se necesita una regla de firewall adecuada.
La regla de firewall debe definir:
- Source zone: normalmente
WAN - Source network: lo más restringido posible
- Destination zone: zona del servidor interno, por ejemplo
DMZ - Destination network: servidor interno
- Services: solo los puertos necesarios
- Security-Profile: según el servicio, IPS, Malware Scan o Web Policy
- Logging: activar
Sin una regla de firewall adecuada, el tráfico se descartará aunque exista DNAT.

El orden también importa en las reglas NAT. Sophos comprueba las reglas NAT de arriba abajo y usa la primera regla que coincide. Por eso, una regla NAT demasiado general situada por encima puede impedir que se aplique la regla DNAT específica.
Limitar el acceso todo lo posible
No todos los servicios publicados deben ser accesibles desde todo Internet. Siempre que sea posible, conviene limitar el acceso.
Restricciones útiles:
- Permitir solo direcciones IP de origen concretas.
- Permitir solo FQDN hosts conocidos si la parte remota usa IPs dinámicas.
- Permitir solo determinados países.
- Bloquear explícitamente determinados países.
- Permitir acceso solo mediante VPN.
- Usar una solución ZTNA en lugar de publicación directa.
Para servicios administrativos como SSH, RDP o portales admin internos, DNAT no suele ser la mejor solución. Si el acceso no debe ser público, VPN o ZTNA casi siempre son la mejor opción.
Más información:
Mejorar la seguridad
Para servicios publicados conviene comprobar:
- ¿El servidor está actualizado con parches?
- ¿Existe una opción WAF o Reverse Proxy?
- ¿IPS está activo en la regla de firewall?
- ¿Solo están abiertos los puertos necesarios?
- ¿Se registra el servicio en logs?
- ¿Hay restricciones por Geo-IP, Threat Feed o IP de origen?
- ¿Es posible MFA si se trata de un portal?
Para aplicaciones web, en lugar de DNAT puro también puede tener sentido Web Server Protection.
Bots y Threat Feeds
Los puertos públicos como HTTP, HTTPS, SSH o RDP están permanentemente en el foco de bots. En cuanto un puerto está accesible en Internet, a menudo se ven muy rápido intentos de conexión, escaneos, intentos de login o tráfico de exploits en Log Viewer.
Esto no significa automáticamente que el servidor esté comprometido. Pero muestra que el servicio forma parte de la superficie pública de ataque. Por eso recomendamos proteger los servicios publicados adicionalmente con IPS, logging, orígenes estrictos y Third-Party Threat Feeds.
Threat Feeds proporcionan a la firewall Indicators of Compromise actuales, por ejemplo direcciones IP o dominios maliciosos. Así, la firewall puede bloquear atacantes conocidos, botnets o scanners antes de que alcancen el servicio publicado.
Más información: Sophos Firewall Threat Feeds
Prueba
Después de crear la regla DNAT:
- Probar desde una red externa, no desde la misma LAN
- Revisar un portscan contra la IP pública
- Comprobar Log Viewer para eventos NAT y de firewall
- Revisar los logs del servidor
- Comprobar si el cliente ve la IP de origen esperada
Si la prueba desde la LAN interna debe hacerse contra la IP pública, puede ser necesario Hairpin NAT o una solución DNS interna.
Troubleshooting
Errores frecuentes:
- Falta la regla de firewall
- Se eligió la IP WAN incorrecta
- Falta el port forwarding en el router del proveedor
- Azure Network Security Group bloquea el puerto
- El servicio interno no está funcionando
- El gateway del servidor no apunta a Sophos Firewall
- La regla NAT está debajo de otra que coincide antes
- El puerto ya lo usa otro servicio
- Falta Loopback si clientes internos usan el FQDN público
- Falta Health Check o está mal configurado si se usa Load Balancing
- La prueba se hace desde la red interna y no desde fuera
El Log Viewer es el punto de partida más importante para problemas DNAT. Allí se ve si llega tráfico, qué regla coincide y si se permite o se descarta.
Recomendación
Las reglas DNAT deben revisarse regularmente. Las publicaciones antiguas son un riesgo de seguridad típico. Una buena documentación incluye propósito, servidor de destino, puertos externos, responsable, fecha de caducidad y última revisión.