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 con SFOS 22 y un Azure VPN Gateway actual: 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 es la opción correcta. Las SKU VpnGw*AZ actuales son route-based; un gateway policy-based real solo existe con la SKU Basic limitada e IKEv1. Un gateway Azure route-based puede usar Use policy based traffic selectors con un firewall local policy-based, pero es un modo de compatibilidad que exige selectores para cada combinación de prefijos. Con SFOS 22, un túnel route-based con XFRM es más claro y necesario para BGP, active-active y Azure NAT.

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 admite custom IPsec/IKE policies en VpnGw1–VpnGw5 y VpnGw1AZ–VpnGw5AZ, pero no en Basic. Microsoft exige una combinación completa por Connection. Revisar siempre la documentación Microsoft.

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, al menos una propuesta Sophos debe coincidir con los parámetros predeterminados de Azure. Los perfiles IPsec de SFOS 22 admiten los grupos DH 1, 2, 5, del 14 al 21 y del 25 al 31, pero no el grupo DH 24. Una Custom Policy debe usar solo valores incluidos en las listas actuales de ambos fabricantes.

Azure fija la lifetime IKE SA en 28 800 segundos; la Default Policy route-based usa 27 000 segundos y 102 400 000 KB para la Quick Mode SA. Una Custom Policy establece estos límites explícitamente, mientras Microsoft permite lifetimes SA locales diferentes. SFOS sigue recomendando una Key lifetime más corta en el initiator y una lifetime de fase 2 inferior a fase 1 para evitar colisiones de rekey. Como Sophos inicia aquí, se aplica ese orden sin inventar valores universales y se observa al menos un rekey.

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. Excepto Basic con mínimo /29, las SKU actuales exigen al menos /27; Microsoft recomienda más de /27 para ampliaciones.
4. GatewaySubnet no contiene VMs ni NSG. No admite una UDR 0.0.0.0/0 y BGP route propagation debe seguir activa.
5. 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 puede crear dos túneles hacia las dos IP públicas Azure
• BGP solo si ASN, peer IP y concepto de routing están definidos

Para gateways nuevos se usan las SKU VpnGw*AZ: VpnGw1AZ–VpnGw3AZ están en Generation 1 y Generation 2 va de VpnGw2AZ a VpnGw5AZ. Microsoft reserva VpnGw1–VpnGw5 para migraciones y desaconseja Basic en producción. Consultar la tabla SKU actual.

En active-active, ambos túneles IPsec pertenecen a la misma Connection Azure, pero cada instancia Azure tiene su propia IP pública. Sophos necesita una conexión route-based y una interfaz XFRM separadas para cada IP Azure. El routing debe admitir tráfico por ambos túneles y la pérdida de cualquiera; probar por separado establecimiento, carga y failover de cada camino.

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: todos los prefijos locales sin BGP; con BGP puede quedar vacío. Añadir prefijos estáticos solo si no se aprenden mediante BGP.
4. En Advanced, activar BGP e introducir ASN y BGP Peer IP de Sophos.

Azure suele usar una dirección privada de GatewaySubnet como peer BGP. Si Sophos usa APIPA, asignar a Azure una dirección única entre 169.254.21.0 y 169.254.22.255; la local puede estar entre 169.254.0.1 y 169.254.255.254. No deben solaparse y Sophos debe iniciar la sesión APIPA. Véase la guía BGP de Azure.

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. Entender y configurar de forma segura los perfiles IPsec de Sophos Firewall explica cómo se relacionan los campos de Sophos y cómo clonar correctamente un perfil propio. Los valores concretos deben seguir coincidiendo exactamente 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 ambos traffic selectors de Sophos como Any. El firewall crea una interfaz xfrm numerada automáticamente. Para Any-to-Any SFOS no crea reglas firewall automáticas. NAT-T siempre está activo; detrás de NAT upstream deben coincidir exactamente los ID de ambos peers.

Configurar ruta o BGP

Sin BGP, usar Download configuration en la Connection Azure para obtener los parámetros genéricos y asignar a XFRM, en Network > Interfaces, la primera IP de túnel, su netmask y el MSS indicados. En Routing > Static routes > IPv4 unicast route, añadir cada prefijo Azure por esa interfaz. Gateway puede quedar vacío o usar la dirección peer de la subnet de transferencia descargada. Con BGP, asignar a XFRM la BGP peer IP local y netmask introducidas en el Local Network Gateway; el neighbor de Sophos es la Azure BGP Peer IP mostrada en Virtual network gateway > Configuration. No inventar direcciones de transferencia.

Con BGP, ambos lados deben planificarse cuidadosamente. Configurar BGP en Sophos Firewall explica la configuración básica, la autorización segura y la validación; para Azure se utilizan después los valores de peer especificados por Azure:

• 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.

El diseño BGP Azure documentado usa IPv4. El ASN local debe ser distinto al ASN Azure y no puede ser uno de los ASN reservados: 8075, 8076, 12076, 65515, 65517, 65518, 65519 o 65520. En Administration > Device access se permite Dynamic Routing para la zona VPN y luego se verifican los prefijos aprendidos en ambos lados.

Para tráfico generado por el firewall, comprobar primero la source IP real, los prefijos anunciados y el camino de retorno. Si la fuente no pertenece a un prefijo local enrutado por Azure, puede requerirse una asignación sys-traffic-nat específica a la IP LAN del firewall; no añadirla solo por usar BGP. Enrutar selectivamente tráfico de sistema por IPsec explica pre-check, sintaxis Device Console, validación y eliminación exacta.

NAT solo como decisión de diseño

Azure NAT para redes solapadas se limita a S2S route-based en VpnGw2–VpnGw5 y VpnGw2AZ–VpnGw5AZ, sin policy-based traffic selectors. Static NAT es 1:1 y bidireccional; dynamic NAT mantiene estado y debe iniciarse desde Internal mapping. Con BGP se activa BGP route translation; APIPA BGP no es compatible con Azure NAT. Véanse los límites NAT de Microsoft.

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.

En Azure, VPN Gateway > Diagnostic settings con IKEDiagnosticLog, TunnelDiagnosticLog, RouteDiagnosticLog y GatewayDiagnosticLog aporta mejores pruebas que un reset. Comparar timestamps del mismo test y resetear solo al final, porque se reinicia la instancia activa.

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. Si varias conexiones IPsec usan los mismos endpoints, comprobar también la asignación del PSK: IKEv2 admite un PSK distinto para cada combinación de Local ID y Remote ID. IKEv1 solo admite un PSK por combinación de gateway local y remoto; SFOS aplica el PSK de la conexión configurada más recientemente. Los IDs únicos con IKEv2 evitan esta colisión.

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.

Azure inicia y expira el child SA

Cuando Azure es el iniciador, solo rekeya un child SA que expira si hay tráfico en el túnel. Sin tráfico lo elimina, aunque fase 1 permanece activa. Tráfico posterior desde Azure puede crear un child SA nuevo; tráfico iniciado únicamente detrás de Sophos Firewall no hace que Azure lo cree en este estado. Por eso Initiate the connection en Sophos es apropiado para este diseño. El rekey del IKE SA de Azure también puede causar una interrupción breve.

Rollback sin destruir el estado

Antes de un cambio, exportar o documentar conexión Sophos, perfil, dirección XFRM, rutas y reglas, además de SKU/generación Azure, Connection, Shared Key, BGP y NAT. No borrar la Connection funcional: clonar el perfil Sophos y anotar la policy Azure en Connection > Configuration o con PowerShell.

Si falla, reasignar el perfil Sophos anterior y restaurar exactamente la Custom Policy Azure previa, o eliminar solo la nueva si antes se usaban defaults. Reactivar la conexión y repetir las pruebas de túnel, rutas y aplicación. No borrar preventivamente gateway, Local Network Gateway, XFRM, rutas o NAT: se perdería el estado conocido y podrían cambiar IP pública o routing.

FAQ