Desplegar y enrutar Sophos Firewall en Azure

Sophos Firewall puede desplegarse desde Azure Marketplace como una appliance o mediante una plantilla con Load Balancer y dos firewalls. Sophos denomina active-active al segundo diseño, pero no es un clúster HA nativo de SFOS. Configuración, sesiones y estado no se sincronizan como entre dos appliances HA.

⚠️ El routing de Azure forma parte de la configuración firewall. Una regla SFOS correcta no basta si falta una User Defined Route, una Network Security Group o el retorno del Load Balancer. Cada apertura se valida como trayecto completo de ida y vuelta.

Elegir modelo operativo y licencia

Los costes de infraestructura Azure y software Sophos son independientes. PAYG se factura por hora, sin compromiso mínimo en el modelo documentado, e incluye Xstream; no admite suscripciones individuales ni Enhanced Plus Support adicionales. Solo está disponible en países de remesa de Microsoft: verificar país de facturación y oferta antes de comprar y usar BYOL si PAYG no está disponible. BYOL se adquiere mediante un reseller autorizado y permite elegir paquetes, suscripciones individuales como Network Protection, Web Protection y Zero-Day Protection, y soporte incluido Enhanced Plus Support. Los plazos documentados son uno, dos o tres años; confirmar oferta y derechos reales sin prometer precios o soporte. Dejar de usar el software no elimina automáticamente recursos Azure facturables.

Sophos especifica como tamaño mínimo Standard_F2s_v2, con dos vCPU, 4 GB de RAM y al menos dos NIC. El tamaño real también depende del rendimiento, las funciones de protección activadas y las cuotas de Azure. La IP pública usa Standard SKU y asignación estática. Basic SKU está retirada y no se utiliza en despliegues nuevos.

Desplegar standalone desde Marketplace

Crear y proteger el appliance

1. Seleccionar Sophos Firewall en Azure Marketplace y elegir BYOL o PAYG.
2. En Basics, definir Subscription, Resource Group, Region, VM name y una contraseña inicial segura para admin. En Instance details, seleccionar BYOL o PAYG, el tamaño comprobado, VNet, LAN subnet, WAN subnet, la IP Standard SKU creada previamente en Public IP name y un Storage Account. VNet, subredes y redes remotas no se solapan.
3. Asociar PortA a LAN y PortB a WAN. Abrir las NSG inicialmente solo a las fuentes administrativas necesarias.
4. Tras superar la validación de Azure, seleccionar Create, copiar el DNS en Virtual machines > y abrir WebAdmin en https://<dns-name>:4444.
5. Iniciar sesión con admin y la contraseña del despliegue, aceptar las condiciones y completar de forma controlada el asistente y el registro.
6. Fijar la IP privada de la NIC LAN como Static. Añadir a cada subnet de cargas una UDR 0.0.0.0/0, Virtual appliance, con esa IP LAN como Next Hop.
7. Probar IP Forwarding, NSG, reglas SFOS y retorno con un cliente definido.

La UDR predeterminada dirige el tráfico de Internet de la subred de cargas asociada al firewall. Las rutas de Azure más específicas siguen teniendo prioridad. Para una conexión route-based con Azure VPN Gateway, la interfaz XFRM usa además rutas estáticas, SD-WAN o BGP.

Preparar el plan de direccionamiento

Para un despliegue nuevo, crear primero la IP pública en Public IP addresses > Create con IP version: IPv4, SKU: Standard, Availability zone: 1, Tier: Regional, IP address assignment: Static y Routing preference: Microsoft network. Definir un DNS name label único y elegir Domain name label scope: None. Sophos también indica DDoS protection > Protection type: Network para este procedimiento. Esta opción requiere un plan Azure DDoS adecuado y puede generar costes adicionales; por eso se valida el plan con el responsable de Azure antes de crear la dirección. Seleccionarla después en Public IP name. Availability zone: 1 es la selección del ejemplo documentado. Por separado, existe un límite de una zona de disponibilidad; esto no demuestra soporte exclusivo para la zona 1 ni valida otras zonas o diseños multizona. La antigua opción Basic dinámica dejó de ser válida tras su retirada por Azure.

Un ejemplo adaptable usa VNet 10.20.0.0/16, LAN 10.20.10.0/24 en PortA, WAN 10.20.20.0/24 en PortB e IP LAN estática 10.20.10.4. Estos valores RFC 1918 se sustituyen por rangos libres sin solapamiento con peering, VPN ni redes on-premises.

Crear la UDR LAN con los campos exactos de Azure

Programar una ventana de mantenimiento: Sophos exige detener la VM antes de fijar la IP LAN. Conservar la IP LAN actual o introducir la dirección reservada y guardarla: Virtual machines > > Stop, después NIC LAN, Settings > IP configurations > ipconfig, Allocation: Static. Tras reiniciar, crear la tabla en Route tables > Create. En Subnets > Associate, asociar cada subred de clientes o cargas cuyo tráfico deba atravesar el appliance. Si los clientes están directamente en la subred LAN de PortA, asociar esa subred LAN, como en el ejemplo básico de Sophos. No asociar la subred WAN del firewall. En Routes > Add, usar Route name: default-via-sfos, Destination type: IP Addresses, Destination IP addresses/CIDR ranges: 0.0.0.0/0, Next hop type: Virtual appliance y Next hop address: 10.20.10.4. Verificar Enable IP forwarding en ambas NIC. Mantener Propagate gateway routes: Yes solo si encaja con VPN/ExpressRoute. Crear una regla LAN-WAN restrictiva y con logging en Rules and policies > Firewall rules.

Operar active-active con Load Balancer

La plantilla Sophos crea dos firewalls y un Standard Load Balancer externo e interno con HA Ports. Exige una VNet /16 y subnets LAN y WAN /24; Sophos pide consultar con su representante antes de usar otros tamaños.

Las health probes alcanzan WebAdmin en 4444 y el proxy en 3128. Las probes internas también dependen de rutas especiales hacia la dirección de plataforma 168.63.129.16, que el Automation Runbook inyecta en la tabla de routing del kernel. Estas rutas no persisten tras un firmware upgrade; después se vuelve a ejecutar y verificar el runbook incluido.

Durante el despliegue, Trusted network debe ser inicialmente *, pues Azure Automation Runbook accede desde IP públicas de Azure. Tras su éxito, restringir inmediatamente la NSG a los CIDR administrativos documentados. La primera firewall usa WebAdmin 4444 y SSH 2222; la segunda, 4445 y 2223. Registrar ambas appliances por separado y mantener iguales sus reglas firewall, NAT y routing.

Configurar probes y egress

En ambos firewalls configurar gateways en Routing > Gateways y rutas de probe en Routing > SD-WAN routes; la ruta externa debe preceder a la interna. La UDR de cargas 0.0.0.0/0 usa Next hop type: Virtual appliance y la IP frontend del Load Balancer interno. En la appliance, las probes TCP 4444 y 3128 aparecen con origen 168.63.129.16. Si cambian los puertos, las probes interna y externa deben seguir siendo distintas. En la NSG, permitir su trayecto con Source Service Tag AzureLoadBalancer; los listeners SFOS y las rutas especiales de Sophos también deben coincidir. Ni el Service Tag ni la dirección de plataforma son una fuente de Internet de confianza general. Verificar ambos backends en Load balancer > Monitoring > Insights o Health Probe Status; una probe saludable no valida aplicación ni retorno.

Desplegar la plantilla con controles previos

Abrir el recurso de despliegue active-active, revisar y registrar su revisión y seleccionar Deploy to Azure. Antes de Next > Create comprobar:

• Subscription, Resource group, Region, Location y disponibilidad de Automation accounts en esa suscripción/región.
• Base URL de la revisión comprobada, VM name, Admin password almacenado de forma segura, Image SKU (BYOL/PAYG-new), VM size con al menos dos NIC.
• Net new or existing, Net RG, Net name, Net prefix (/16), WAN name/prefix, LAN name/prefix (/24); Loadbalancer Int IP libre en LAN.
• Opciones nuevo/existente, grupos y nombres de Public IP, Storage, Network security group, Availability set, Automation account; Public IP DNS, Storage type, NIC WAN, NIC LAN, Number of instances: 2. Verificar recursos existentes y etiqueta DNS única.
• Registrar reglas NSG originales y duración autorizada de Trusted network: *; restringir de nuevo la administración incluso si falla la automatización. Sin excepción temporal aprobada, detener el despliegue público sin restricciones.

Después, inventariar NIC/subredes, gateways, frontends LB, probes y puertos de administración reales; no copiar los valores standalone.

Gateways y rutas de probes en ambas appliances

En Routing > Gateways > Add, crear y guardar dos gateways:

El ejemplo conservado usa 10.54.11.1/10.54.22.1 y WAN para ambos gateways, pero vincula luego las rutas interna/externa a #PortA/#PortB. Es una asignación particular del despliegue, no universal. Verificar NIC, interfaces SFOS y alcance de subred; ante contradicción, detenerse y resolverla con el responsable, sin copiar IP ni inventar otra asignación.

En Routing > SD-WAN routes > Add, crear primero la interna y luego la externa, ambas en Top:

Contrastar objetos y definición de servicio con el flujo real: HTTP no significa cambiar probes TCP 4444/3128 a 80. No convertir el servicio interno no especificado en una ruta general; origen/destino siguen restringidos. Guardar, mantener la externa encima de la interna y repetir la asignación comprobada en la segunda appliance. Revisar Load balancers > Monitoring > Metrics > Health probe status, agregación Avg, filtro Backend IP address, en ambos backends/LB; probar salida y retorno reales.

Recuperar rutas inyectadas tras firmware

Reservar mantenimiento: el runbook documentado reinicia la VM y puede cortar sesiones. Exportar backups SFOS, guardar runbook/NSG y verificar el otro backend antes de intervenir una VM. Si ambos fallan, planificar interrupción; no prometer recuperación sin corte.

1. Network security groups > [NSG firewall] > Inbound security rules > allow_ssh: verificar acceso del runner al puerto SSH asignado. La fuente usa Source: IP address, Source IP addresses/CIDR ranges: 0.0.0.0/0, una excepción temporal de alto riesgo, no permanente. Preferir acceso más restringido verificado; si no existe, exigir aprobación explícita, plazo corto y solo el mapping SSH requerido. No adivinar CIDR Azure ni ampliar otros puertos.
2. Grupo de recursos > Automation account > Runbooks > [runbook desplegado] > Edit > Edit in portal. La revisión conservada indica comentar líneas 20–24: identificar el bloque previsto en el script real y guardar su original; no usar números de otra revisión. Si no se entiende, detenerse. Save > Publish, revisar diff, Start.
3. Introducir los parámetros de esta VM:

4. Revisar salida, errores y estado del job. Completed solo confirma finalización: esperar reinicio/acceso, comprobar ruta 168.63.129.16, ambos probes y aplicación/salida real. Solo entonces recuperar la segunda VM con sus propios parámetros.
5. Restaurar inmediatamente restricciones NSG registradas, también tras fallo, y comprobar acceso efectivo. Mantener el backend sano, conservar errores, restaurar script si el cambio era incorrecto y escalar antes de repetir o tocar el otro. Completed no demuestra 100 % de salud ni internet.

DNAT y retorno

El Load Balancer externo elige un firewall. Los HA Ports transportan flujos NVA entre protocolos y puertos, pero no sustituyen una publicación específica del servicio. Para el servicio TCP publicado, crear en el Load Balancer externo una health probe adecuada y una regla de Load Balancing vinculada a esa probe. La regla NAT de SFOS traduce después al servidor. En Rules and policies > NAT rules, Translated source (SNAT): MASQ hace que el servidor responda a la IP LAN de ese mismo firewall. Sin MASQ, el retorno puede cruzar el otro firewall y romper la sesión.

No se recomienda publicar RDP directamente. Se prefiere VPN o ZTNA. Si el servicio debe publicarse, se limitan origen, servicio y destino en Azure y SFOS, se activan logging e IPS y se realiza una prueba negativa.

Validar, solucionar y revertir

Controles de aceptación

1. En Effective routes de una VM de prueba, comprobar que 0.0.0.0/0 apunta a la IP LAN de SFOS o, en active-active, a la IP del Load Balancer interno.
2. Probar DNS, HTTPS y la aplicación; confirmar Rule ID, origen y destino en Log viewer > Firewall. Para un servicio publicado, realizar una prueba desde una red de origen permitida y otra desde una no permitida; comprobar por separado el destino DNAT y la ruta de retorno del servidor.
3. En active-active, revisar Health Probe Status y Backend Pool. Solo durante una ventana de mantenimiento, retirar un firewall, probar conexiones nuevas por el otro y restaurar un backend saludable antes del segundo ensayo. Las sesiones existentes no se sincronizan y pueden interrumpirse.

Errores típicos

Sin egress, revisar Effective Routes, asociación de subnet de cargas, IP LAN estática, IP forwarding, NSG y Rule ID de SFOS. Para una probe unhealthy, revisar protocolo/puerto TCP, listener, NSG y rutas SD-WAN a 168.63.129.16. Tras un firmware upgrade las rutas inyectadas no persisten: ejecutar de nuevo el runbook de Sophos en ambas VM, comprobar las probes y restaurar enseguida los CIDR admin en la NSG SSH. Para DNAT intermitente, comparar reglas en ambas appliances, MASQ, Backend Pool y ruta de retorno del servidor.

Antes de revertir el egress, registrar el Next Hop aprobado anteriormente. Volver a asociar la Route Table previa o aislar la subnet de cargas durante el cambio. Una simple desasociación puede activar la ruta de sistema de Azure 0.0.0.0/0 -> Internet y eludir el firewall; hacerlo solo si ese trayecto se ha revisado y aceptado expresamente. Eliminar la UDR y las reglas temporales únicamente después de validar el retorno restaurado. Para DNAT, desactivar primero la regla del Load Balancer externo. Los snapshots de Azure no sustituyen un backup SFOS exportado. Documentar por separado el backup, la reconstrucción, la asignación de licencias, el responsable y la alarma de costes.

Continuar con el runbook interno Azure VPN Gateway o la configuración Entra Domain Services del runbook AD.