Relier Sophos Firewall à Azure VPN Gateway

Un Azure VPN Gateway relie un réseau local à un Azure Virtual Network via Site-to-Site IPsec. Sur Sophos Firewall, cela se fait généralement avec un route-based IPsec VPN. Dans les environnements plus grands ou plus dynamiques, BGP s’ajoute souvent.

Cet article décrit le flux pratique entre Sophos Firewall et Microsoft Azure : objets Azure requis, configuration côté Sophos, paramètres IPsec/IKE à faire correspondre et validation du trafic réel après l’enregistrement. Pour les bases IPsec générales, consulter configurer un Site-to-Site IPsec VPN sur Sophos Firewall. Si un tunnel existant est vert mais ne transporte pas de trafic, utiliser Sophos Firewall IPsec VPN Troubleshooting.

Quand cet article convient

L’article convient lorsqu’un réseau local derrière Sophos Firewall doit être connecté à un Azure Virtual Network. Il traite d’un tunnel Site-to-Site entre Azure VPN Gateway et le firewall local, pas d’un Point-to-Site VPN pour utilisateurs individuels ni d’un Sophos Firewall comme appliance virtuelle dans Azure.

Scénarios typiques :

réseau serveur local vers Azure VMs
site principal ou succursale vers Azure Virtual Network
scénario hybride avec AD, DNS, sauvegarde, monitoring ou management dans Azure
migration de designs policy-based vers route-based IPsec
BGP optionnel pour le routage dynamique entre réseau local et Azure

Azure et Sophos n’utilisent pas toujours les mêmes termes. Dans Azure, on travaille avec Virtual network, Gateway subnet, Virtual network gateway, Local network gateway et Connection. Sur Sophos Firewall, on travaille avec connexion IPsec, interface XFRM, routes, règles firewall et éventuellement BGP.

Planifier avant la configuration

Un tunnel Azure ne doit pas être traité comme un simple assistant graphique. La plupart des problèmes viennent de réseaux qui se chevauchent, d’une mauvaise SKU de gateway, de paramètres IPsec/IKE incompatibles, de routes manquantes ou de règles firewall sans logging.

Réseaux et espaces d’adresses

Les réseaux locaux et les espaces d’adresses Azure ne doivent pas se chevaucher. Azure route les préfixes locaux déclarés dans le Local network gateway vers Sophos Firewall. Sophos Firewall route les préfixes Azure via l’interface XFRM ou via BGP.

Documenter au préalable :

Azure Virtual Network Address Space, par exemple 10.50.0.0/16
sous-réseaux Azure, en particulier les workload subnets
réseau local derrière Sophos Firewall, par exemple 172.16.10.0/24
IP publique de Sophos Firewall ou du routeur amont
IP publique Azure du Virtual Network Gateway
BGP oui ou non
Preshared Key commun
systèmes de test prévus des deux côtés

Si les réseaux locaux et Azure se chevauchent, le design doit d’abord être corrigé. NAT over IPsec est possible, mais rend exploitation et dépannage beaucoup plus difficiles.

Route-based plutôt que policy-based

Pour Azure, route-based IPsec est le bon choix dans la plupart des designs actuels. Azure VPN Gateway est généralement exploité en route-based, surtout lorsque plusieurs préfixes, BGP, active-active ou des extensions futures sont prévus.

Sur Sophos Firewall, cela signifie :

planifier la connexion IPsec comme tunnel interface route-based ;
vérifier l’interface XFRM après l’enregistrement ;
définir routes ou BGP pour les préfixes Azure ;
créer des règles firewall entre zones locales et zone VPN ;
vérifier le trafic avec Log Viewer et l’état de la connection Azure.

Un tunnel vert ne représente qu’une partie de la validation. Le tunnel n’est vraiment validé que lorsqu’un client défini atteint une destination Azure définie et que les deux côtés montrent des logs ou compteurs.

Ne pas deviner les paramètres IPsec/IKE

Azure VPN Gateway prend en charge des paramètres IPsec/IKE définis et, avec des gateway SKUs adaptées, des policies IPsec/IKE personnalisées. Microsoft indique qu’une policy personnalisée doit être entièrement définie ; des indications partielles ne suffisent pas.

Pour l’exploitation :

choisir consciemment la version IKE, généralement IKEv2 ;
documenter encryption, integrity, DH group, PFS et lifetimes ;
comparer Azure Custom Policy et Sophos IPsec Profile ;
ne pas reprendre aveuglément des valeurs Sophos-vers-Sophos pour Azure ;
prévoir fenêtre de maintenance et rollback après chaque changement de policy.

Sans Custom Policy, le profil Sophos doit correspondre aux defaults Azure. Avec Custom Policy, toutes les valeurs doivent être maintenues proprement des deux côtés.

Préparer le côté Azure

La configuration Azure contient plusieurs objets. Les noms doivent être clairs, sinon le dépannage devient vite confus.

Virtual Network et Gateway subnet

L’Azure Virtual Network a besoin d’un GatewaySubnet dédié. Ce subnet est utilisé par Azure VPN Gateway et ne doit pas servir à des VMs normales.

Contrôler :

Azure Virtual Network existe.
Address Space ne chevauche pas les réseaux locaux.
GatewaySubnet existe et est dimensionné correctement.
Workload subnets et Network Security Groups autorisent le trafic souhaité.

Créer Virtual Network Gateway

Le Virtual network gateway est le vrai Azure VPN Gateway. Points importants :

Gateway type : VPN
VPN type : Route-based
SKU adaptée à bande passante, SLA, Availability Zone et besoin BGP
Public IP pour la gateway
Active-active uniquement si le côté local est conçu pour cela
BGP uniquement si ASN, peer IP et concept de routage sont définis

Le déploiement de la gateway dans Azure prend souvent nettement plus longtemps qu’un dialogue firewall normal.

Créer Local Network Gateway

Le Local network gateway décrit le côté local vu par Azure.

Renseigner :

Nom, par exemple lng-sophos-hq.
Endpoint comme IP publique ou FQDN du côté Sophos.
Local Address spaces si l’on travaille sans BGP.
BGP settings si le routage dynamique est utilisé.

Si Sophos Firewall est derrière NAT, il faut vérifier précisément quelle IP publique Azure voit et comment NAT-T, port forwarding et IDs sont mis en oeuvre localement. Le chemin standard simple est une Sophos Firewall avec sa propre IP publique.

Créer Connection

La Connection relie Virtual Network Gateway et Local Network Gateway.

Valeurs importantes :

Connection type : Site-to-site (IPsec)
Shared key : identique au Preshared Key Sophos
IKE Protocol : cohérent avec la configuration Sophos
BGP : uniquement si les deux côtés utilisent BGP
Custom IPsec/IKE policy : seulement si les valeurs ont été planifiées

Après la création de la Connection, le côté Azure est prêt, mais pas automatiquement productif. Le côté Sophos doit connaître le même tunnel, les mêmes paramètres et le chemin retour.

Configurer Sophos Firewall

Sur Sophos Firewall, le tunnel se crée sous Site-to-site VPN > IPsec.

Préparer le profil IPsec

Sous Profiles > IPsec profiles, utiliser ou créer un profil compatible avec Azure. Les valeurs doivent correspondre à la Azure default policy ou à la custom IPsec/IKE policy de la Connection.

Documenter :

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

Si Azure utilise une Custom Policy, le nom du profil devrait le refléter, par exemple Azure_IKEv2_AES256_G14.

Créer la connexion IPsec route-based

Chemin :

Site-to-site VPN > IPsec

Procédure :

Ouvrir Add.
Choisir Route-based ou tunnel interface comme type de connexion.
Définir un nom, par exemple azure-vnet-prod.
Définir Gateway type côté Sophos généralement sur Initiate the connection.
Saisir l’IP publique Azure du Virtual Network Gateway comme Remote Gateway.
Saisir le Preshared Key identique à la Connection Azure.
Vérifier Local ID et Remote ID, surtout avec NAT ou plusieurs tunnels.
Sélectionner le profil IPsec.
Enregistrer et activer la connexion.

Après l’enregistrement, vérifier l’interface XFRM sous Network > Interfaces. Elle reste assignée à la zone VPN. Selon le design, elle est utilisée avec route statique, SD-WAN route ou BGP.

Configurer route ou BGP

Sans BGP, Sophos Firewall a besoin d’une route vers les préfixes Azure. Il s’agit généralement d’une route statique ou SD-WAN via l’interface XFRM.

Avec BGP, les deux côtés doivent être planifiés :

ASN local de Sophos Firewall
Azure ASN
BGP peer IPs
préfixes autorisés et annoncés
route advertisement dans Azure
règles firewall pour le trafic utile réel

BGP ne remplace pas les règles firewall. Il distribue seulement des routes. L’accès à un serveur Azure dépend toujours du routage, NSG, règles firewall et système cible.

Créer les règles firewall

Le trafic dans le tunnel a besoin de règles adaptées, en général entre zone interne et zone VPN.

Recommandations de déploiement :

utiliser des réseaux ou hosts concrets comme source et destination ;
choisir les services du premier test, par exemple ICMP, RDP, HTTPS ou DNS ;
activer Log firewall traffic ;
ne pas laisser les règles sur Any après le premier test ;
contrôler le sens inverse séparément si Azure doit atteindre des systèmes locaux.

Si la règle ne matche pas, utiliser Sophos Firewall : vérifier pourquoi une règle ne s’applique pas.

Vérifier la connexion

La validation doit toujours contrôler deux niveaux : état du tunnel et trafic réel.

Vérifier Azure

Dans Azure :

Ouvrir la Connection du VPN Gateway.
Vérifier l’état de connexion.
Observer les compteurs de données.
Contrôler les effective routes de l’Azure VM concernée.
Contrôler le Network Security Group des subnets cibles.

L’état Azure seul ne suffit pas. Une VM peut rester inaccessible malgré une Connection établie à cause de NSG, Windows Firewall local, route incorrecte ou chemin retour manquant.

Vérifier Sophos Firewall

Sur Sophos Firewall :

Vérifier l’état sous Site-to-site VPN > IPsec.
Contrôler l’interface XFRM sous Network > Interfaces.
Vérifier la route vers les préfixes Azure.
Filtrer Log Viewer sur le trafic de test.
Utiliser Packet Capture ou strongswan.log si nécessaire.

Pour les logs IPsec et l’analyse CLI, utiliser Sophos Firewall IPsec VPN Troubleshooting.

Utiliser un trafic de test réaliste

ICMP est un bon début, mais pas un test complet. Ensuite, tester le service productif :

DNS vers un serveur DNS ou contrôleur de domaine Azure
RDP ou SSH vers une VM de test
HTTPS vers une application interne
trafic backup, monitoring ou management

La source compte. Un ping lancé directement depuis le firewall ne prouve pas la même chose qu’un test depuis un client derrière le firewall.

Erreurs typiques

Le tunnel reste down

Le plus souvent, IP de gateway, version IKE, Preshared Key, IDs ou paramètres IPsec/IKE ne correspondent pas. Côté Sophos, vérifier d’abord strongswan.log, puis comparer Azure Connection Settings et Sophos IPsec Profile.

Le tunnel est connecté, mais aucun trafic ne passe

Il manque souvent routes, règles firewall, règles Azure NSG ou chemin retour. Côté Sophos, vérifier Log Viewer et route. Côté Azure, vérifier Effective Routes et NSG.

Un seul sens fonctionne

Cela indique souvent routage asymétrique, NSG, host firewall ou règle inverse manquante. Tester les deux sens séparément et documenter la source du trafic de test.

BGP n’apprend aucune route

Vérifier ASN, peer IP, activation BGP, adresse XFRM et configuration Azure BGP. Ensuite contrôler quels préfixes sont réellement annoncés et appris. Un tunnel IPsec établi ne signifie pas automatiquement que BGP route correctement.

Le tunnel ne revient pas après un changement de policy

Les Custom IPsec/IKE Policies doivent être complètes et compatibles. Si Azure et Sophos interprètent une seule valeur différemment, la connexion peut échouer. Avant tout changement, documenter profil actuel, Azure Policy et état fonctionnel.

FAQ

Faut-il connecter Sophos Firewall à Azure en policy-based ou route-based ?

Pour Azure, route-based IPsec est généralement le meilleur choix, surtout avec plusieurs réseaux, BGP ou des extensions futures. Les designs policy-based sont généralement moins flexibles pour Azure.

Azure VPN Gateway a-t-il besoin de BGP ?

Non. Pour les connexions simples, des routes statiques ou Address Spaces dans Local Network Gateway suffisent. BGP est utile lorsque les préfixes doivent être appris dynamiquement ou que plusieurs chemins sont prévus.

Pourquoi le tunnel Azure est vert, mais la VM inaccessible ?

IPsec est probablement établi, mais routage, règle firewall, Azure NSG, Windows Firewall local ou chemin retour ne correspondent pas. Il faut donc tester séparément l’état du tunnel et le trafic applicatif réel.

Sophos Firewall peut-il être derrière NAT ?

C’est possible, mais ce n’est pas le cas standard simple. IP publique, NAT-T, port forwarding, Local ID, Remote ID et Azure Local Network Gateway doivent alors être planifiés et testés très soigneusement.

Faut-il définir explicitement les paramètres IPsec Azure ?

Pas toujours. Sans Custom IPsec/IKE Policy, le profil Sophos doit correspondre aux defaults Azure. Avec Custom Policy, tous les paramètres doivent être définis complètement et de manière compatible des deux côtés.