Ir al contenido
Avanet

Desplegar y enrutar Sophos Firewall en Azure

Sophos Firewall

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

ModeloLicenciaLímite importante
StandaloneBYOL o PAYGUn appliance sin redundancia, para cargas controladas con una ventana de mantenimiento aceptada.
Active-active con Load BalancerUna licencia BYOL por firewall o PAYGDos firewalls independientes tras Standard Load Balancers con HA Ports; la plantilla no admite active-passive.

Para standalone, Sophos recomienda al menos Standard_F2s_v2, dos vCPU y 4 GB de RAM. 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. Definir Resource Group, región y tamaño. 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. Completar el despliegue y abrir WebAdmin en https://<dns-name>:4444.
  5. Completar de forma controlada el asistente, registro, licencia y firmware.
  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 fuerza el tráfico LAN saliente a través del firewall. Sin ella, Azure usa su ruta predeterminada. 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. Sophos solo admite explícitamente la zona 1. 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

Sophos exige detener la VM antes de fijar la IP LAN: 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.

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 positiva autorizada y otra negativa no autorizada.
  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.

Fuentes oficiales