Ir al contenido
Avanet

Conectar Sophos Firewall con Azure VPN Gateway

Un Azure VPN Gateway conecta una red local con un Azure Virtual Network mediante Site-to-Site IPsec. En Sophos Firewall normalmente se construye como route-based IPsec VPN. En entornos más grandes o dinámicos se añade BGP.

Este artículo explica el flujo práctico entre Sophos Firewall y Microsoft Azure: objetos Azure necesarios, configuración del lado Sophos, parámetros IPsec/IKE que deben coincidir y validación del tráfico real. Para bases generales de IPsec, empezar por configurar Sophos Firewall Site-to-Site IPsec VPN. Si un túnel está verde pero no transporta tráfico, usar Sophos Firewall IPsec VPN Troubleshooting.

Cuándo encaja este artículo

Encaja cuando una red local detrás de Sophos Firewall debe conectarse a un Azure Virtual Network. Trata un túnel Site-to-Site entre Azure VPN Gateway y el firewall local, no Point-to-Site VPN para usuarios individuales ni Sophos Firewall como appliance virtual en Azure.

Escenarios típicos:

  • red de servidores local hacia Azure VMs
  • sede principal o sucursal hacia Azure Virtual Network
  • escenario híbrido con AD, DNS, backup, monitoring o management en Azure
  • migración de diseños policy-based a route-based IPsec
  • BGP opcional para routing dinámico entre red local y Azure

Azure y Sophos no siempre usan los mismos términos. En Azure se trabaja con Virtual network, Gateway subnet, Virtual network gateway, Local network gateway y Connection. En Sophos Firewall con conexión IPsec, interfaz XFRM, rutas, reglas firewall y opcionalmente BGP.

Planificar antes de configurar

Un túnel Azure no debe tratarse como un simple asistente. La mayoría de errores viene de redes solapadas, SKU de gateway incorrecta, parámetros IPsec/IKE no compatibles, rutas ausentes o reglas firewall sin logging.

Redes y espacios de direcciones

Las redes locales y los address spaces de Azure no deben solaparse. Azure enruta los prefijos locales definidos en Local network gateway hacia Sophos Firewall. Sophos Firewall enruta los prefijos Azure mediante la interfaz XFRM o BGP.

Documentar antes:

  • Azure Virtual Network Address Space, por ejemplo 10.50.0.0/16
  • subredes Azure, especialmente workload subnets
  • red local detrás de Sophos Firewall, por ejemplo 172.16.10.0/24
  • IP pública de Sophos Firewall o router superior
  • IP pública Azure del Virtual Network Gateway
  • BGP sí o no
  • Preshared Key compartido
  • sistemas de prueba en ambos lados

Si las redes locales y Azure se solapan, primero hay que corregir el diseño. NAT over IPsec es posible, pero complica mucho operación y troubleshooting.

Route-based en lugar de policy-based

Para Azure, route-based IPsec suele ser la opción correcta. Azure VPN Gateway se opera normalmente como route-based, especialmente con varios prefijos, BGP, active-active o ampliaciones futuras.

En Sophos Firewall significa:

  • planificar la conexión IPsec como tunnel interface route-based;
  • comprobar la interfaz XFRM después de guardar;
  • configurar rutas o BGP para prefijos Azure;
  • crear reglas firewall entre zonas locales y zona VPN;
  • verificar tráfico con Log Viewer y estado de Azure Connection.

Un estado de túnel verde solo es parte de la aceptación. El túnel está realmente validado cuando un cliente definido alcanza un destino Azure definido y ambos lados muestran logs o contadores.

No adivinar parámetros IPsec/IKE

Azure VPN Gateway soporta parámetros IPsec/IKE definidos y, con SKUs adecuadas, custom IPsec/IKE policies. Microsoft indica que una policy personalizada debe especificarse completa; no bastan valores parciales.

Para operación:

  • elegir conscientemente la versión IKE, normalmente IKEv2;
  • documentar encryption, integrity, DH group, PFS y lifetimes;
  • comparar Azure Custom Policy y Sophos IPsec Profile;
  • no trasladar defaults Sophos-a-Sophos a Azure sin verificar;
  • planificar ventana de mantenimiento y rollback tras cada cambio de policy.

Sin Custom Policy, el perfil Sophos debe coincidir con los defaults Azure. Con Custom Policy, todos los valores deben mantenerse correctamente en ambos lados.

Preparar el lado Azure

La configuración Azure consta de varios objetos. Los nombres deben ser claros para no complicar troubleshooting.

Virtual Network y Gateway subnet

El Azure Virtual Network necesita un GatewaySubnet dedicado. Este subnet lo usa Azure VPN Gateway y no debe usarse para VMs normales.

Comprobar:

  1. Azure Virtual Network existe.
  2. Address Space no se solapa con redes locales.
  3. GatewaySubnet existe y tiene tamaño suficiente.
  4. Workload subnets y Network Security Groups permiten el tráfico deseado.

Crear Virtual Network Gateway

El Virtual network gateway es el Azure VPN Gateway real. Importante:

  • Gateway type: VPN
  • VPN type: Route-based
  • SKU adecuada a ancho de banda, SLA, Availability Zone y requisito BGP
  • Public IP para el gateway
  • Active-active solo si el lado local está diseñado para ello
  • BGP solo si ASN, peer IP y concepto de routing están definidos

El despliegue del gateway en Azure suele tardar bastante más que un diálogo normal de firewall.

Crear Local Network Gateway

El Local network gateway describe el lado local desde la perspectiva de Azure.

Introducir:

  1. Nombre, por ejemplo lng-sophos-hq.
  2. Endpoint como IP pública o FQDN del lado Sophos.
  3. Local Address spaces si se trabaja sin BGP.
  4. BGP settings si se usa routing dinámico.

Si Sophos Firewall está detrás de NAT, revisar cuidadosamente qué IP pública ve Azure y cómo se implementan NAT-T, port forwarding e IDs. El camino estándar simple es Sophos Firewall con IP pública propia.

Crear Connection

La Connection une Virtual Network Gateway y Local Network Gateway.

Valores importantes:

  • Connection type: Site-to-site (IPsec)
  • Shared key: idéntica al Preshared Key de Sophos
  • IKE Protocol: compatible con la configuración Sophos
  • BGP: activar solo si ambos lados usan BGP
  • Custom IPsec/IKE policy: solo si los valores se planificaron conscientemente

Después de crear la Connection, Azure está preparado, pero no automáticamente productivo. El lado Sophos debe conocer el mismo túnel, los mismos parámetros y el camino de retorno.

Configurar Sophos Firewall

En Sophos Firewall el túnel se crea en Site-to-site VPN > IPsec.

Preparar IPsec profile

En Profiles > IPsec profiles, usar o crear un perfil compatible con Azure. Los valores deben coincidir con la Azure default policy o la custom IPsec/IKE policy de la Connection.

Documentar:

  • IKE version
  • Phase 1 encryption y authentication
  • DH group
  • Phase 2 encryption y authentication
  • PFS
  • Key lifetime

Si Azure usa Custom Policy, el nombre del perfil debería reflejarlo, por ejemplo Azure_IKEv2_AES256_G14.

Crear conexión IPsec route-based

Ruta:

Site-to-site VPN > IPsec

Procedimiento:

  1. Abrir Add.
  2. Elegir Route-based o tunnel interface como tipo de conexión.
  3. Definir nombre, por ejemplo azure-vnet-prod.
  4. Configurar Gateway type en Sophos normalmente como Initiate the connection.
  5. Introducir la IP pública Azure del Virtual Network Gateway como Remote Gateway.
  6. Definir Preshared Key idéntica a la Connection Azure.
  7. Revisar Local ID y Remote ID, especialmente con NAT o varios túneles.
  8. Seleccionar IPsec profile.
  9. Guardar y activar la conexión.

Después de guardar, comprobar la interfaz XFRM en Network > Interfaces. Queda asignada a la zona VPN. Según el diseño, se usa con ruta estática, SD-WAN route o BGP.

Configurar ruta o BGP

Sin BGP, Sophos Firewall necesita una ruta hacia los prefijos Azure. Normalmente es una ruta estática o SD-WAN route por la interfaz XFRM.

Con BGP ambos lados deben planificarse:

  • ASN local de Sophos Firewall
  • Azure ASN
  • BGP peer IPs
  • prefijos permitidos y anunciados
  • route advertisement en Azure
  • reglas firewall para el tráfico real

BGP no sustituye reglas firewall. Solo distribuye rutas. Que un servidor Azure sea alcanzable sigue dependiendo de routing, NSG, reglas firewall y sistema destino.

Crear reglas firewall

El tráfico por el túnel necesita reglas adecuadas, normalmente entre zona interna y zona VPN.

Recomendación de despliegue:

  • usar redes o hosts concretos como source y destination;
  • elegir servicios concretos para la primera prueba, por ejemplo ICMP, RDP, HTTPS o DNS;
  • activar Log firewall traffic;
  • no dejar reglas en Any después de la primera prueba;
  • revisar el sentido contrario por separado si Azure debe alcanzar sistemas locales.

Si la regla no coincide, usar Sophos Firewall: comprobar por qué una regla no coincide.

Verificar la conexión

La aceptación debe comprobar siempre dos niveles: estado del túnel y tráfico real.

Verificar Azure

En Azure:

  1. Abrir la Connection del VPN Gateway.
  2. Comprobar estado de conexión.
  3. Observar contadores de datos.
  4. Revisar effective routes de la Azure VM afectada.
  5. Comprobar Network Security Group de las subredes destino.

El estado de Azure por sí solo no basta. Una VM puede ser inaccesible pese a una Connection activa por NSG, Windows Firewall local, ruta incorrecta o retorno ausente.

Verificar Sophos Firewall

En Sophos Firewall:

  1. Comprobar estado en Site-to-site VPN > IPsec.
  2. Revisar la interfaz XFRM en Network > Interfaces.
  3. Comprobar la ruta hacia prefijos Azure.
  4. Filtrar Log Viewer por tráfico de prueba.
  5. Usar Packet Capture o strongswan.log si hace falta.

Para logs IPsec y análisis CLI, usar Sophos Firewall IPsec VPN Troubleshooting.

Usar tráfico de prueba realista

ICMP es un buen inicio, pero no una prueba completa. Después probar el servicio productivo:

  • DNS hacia un DNS o domain controller en Azure
  • RDP o SSH hacia una VM de prueba
  • HTTPS hacia una aplicación interna
  • tráfico de backup, monitoring o management

La source importa. Un ping directo desde el firewall no demuestra lo mismo que una prueba desde un cliente detrás del firewall.

Errores típicos

El túnel permanece down

Normalmente no coinciden IP de gateway, versión IKE, Preshared Key, IDs o parámetros IPsec/IKE. En Sophos Firewall, revisar primero strongswan.log y comparar Azure Connection Settings con Sophos IPsec Profile.

El túnel está conectado, pero no fluye tráfico

Suelen faltar rutas, reglas firewall, reglas Azure NSG o camino de retorno. En Sophos, revisar Log Viewer y ruta. En Azure, Effective Routes y NSG.

Solo funciona una dirección

Suele indicar routing asimétrico, NSG, host firewall o regla inversa ausente. Probar ambas direcciones por separado y documentar la source del tráfico de prueba.

BGP no aprende rutas

Comprobar ASN, peer IP, activación BGP, dirección XFRM y configuración Azure BGP. Luego verificar qué prefijos se anuncian y aprenden realmente. Un túnel IPsec activo no significa que BGP enrute correctamente.

El túnel no vuelve tras cambiar policy

Las Custom IPsec/IKE Policies deben ser completas y compatibles. Si Azure y Sophos interpretan un solo valor de forma diferente, la conexión puede fallar. Antes de cambios, documentar perfil actual, Azure Policy y estado funcional.

FAQ

¿Sophos Firewall hacia Azure debe ser policy-based o route-based?

Para Azure, route-based IPsec suele ser la mejor opción, especialmente con varias redes, BGP o ampliaciones futuras. Los diseños policy-based son menos flexibles para Azure.

¿Azure VPN Gateway necesita BGP?

No. Para conexiones simples bastan rutas estáticas o Address Spaces en Local Network Gateway. BGP es útil si los prefijos deben aprenderse dinámicamente o se planifican varios caminos.

¿Por qué el túnel Azure está verde, pero la VM no es alcanzable?

IPsec probablemente está establecido, pero routing, regla firewall, Azure NSG, Windows Firewall local o camino de retorno no coinciden. Por eso hay que probar por separado estado del túnel y tráfico real.

¿Puede Sophos Firewall estar detrás de NAT?

Puede funcionar, pero no es el caso estándar simple. IP pública, NAT-T, port forwarding, Local ID, Remote ID y Azure Local Network Gateway deben planificarse y probarse con especial cuidado.

¿Hay que definir explícitamente los parámetros IPsec de Azure?

No siempre. Sin Custom IPsec/IKE Policy, el perfil Sophos debe coincidir con los defaults Azure. Con Custom Policy, todos los parámetros deben definirse completa y compatiblemente en ambos lados.