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 avec SFOS 22 et une Azure VPN Gateway actuelle : 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. Les SKUs VpnGw*AZ actuelles sont route-based ; une vraie gateway policy-based n’existe qu’avec la SKU Basic limitée et IKEv1. Une gateway Azure route-based peut utiliser Use policy based traffic selectors pour une firewall locale policy-based, mais ce mode de compatibilité exige des sélecteurs pour chaque combinaison de préfixes. Avec SFOS 22, un tunnel route-based avec interface XFRM est plus clair et requis pour BGP, active-active et Azure NAT.

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 permet des policies IPsec/IKE personnalisées sur VpnGw1 à VpnGw5 et VpnGw1AZ à VpnGw5AZ, mais pas sur Basic. Microsoft exige une combinaison complète par Connection. La référence Microsoft doit être vérifiée avant tout changement.

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, au moins une proposition Sophos doit correspondre aux paramètres Azure par défaut. Les profils IPsec de SFOS 22 prennent en charge les groupes DH 1, 2, 5, 14 à 21 et 25 à 31, mais pas le groupe DH 24. Une Custom Policy doit utiliser uniquement l’intersection des listes actuelles des deux fabricants.

Azure fixe la lifetime IKE SA à 28 800 secondes ; la Default Policy route-based utilise 27 000 secondes et 102 400 000 KB pour la Quick Mode SA. Une Custom Policy définit explicitement ces limites, tandis que Microsoft autorise des lifetimes SA locales différentes. SFOS recommande néanmoins une Key lifetime plus courte sur l’initiateur et une lifetime de phase 2 inférieure à celle de phase 1 pour éviter les collisions de rekey. Comme Sophos initie ici, respecter cet ordre sans inventer de valeurs universelles et observer au moins un rekey.

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 :

1. Azure Virtual Network existe.
2. Address Space ne chevauche pas les réseaux locaux.
3. GatewaySubnet existe et est dimensionné correctement. Hormis Basic avec un minimum /29, les SKUs actuelles exigent au moins /27 ; Microsoft recommande plus grand que /27 pour les extensions.
4. GatewaySubnet ne contient ni VM ni NSG. Une UDR 0.0.0.0/0 n’y est pas prise en charge et BGP route propagation doit rester active.
5. 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 peut établir deux tunnels vers les deux IP publiques Azure
• BGP uniquement si ASN, peer IP et concept de routage sont définis

Pour une nouvelle gateway, utiliser les SKUs VpnGw*AZ. VpnGw1AZ à VpnGw3AZ existent en génération 1 ; la génération 2 va de VpnGw2AZ à VpnGw5AZ. Microsoft réserve désormais VpnGw1 à VpnGw5 aux migrations et déconseille Basic en production. Vérifier la table SKU actuelle, car débits, limites et fonctions évoluent.

En mode active-active, les deux tunnels IPsec appartiennent à la même Connection Azure, mais chaque instance Azure a sa propre IP publique. Sophos nécessite donc une connexion route-based et une interface XFRM distinctes pour chaque IP Azure. Le routage doit supporter les deux tunnels et la perte de chacun ; tester séparément établissement, charge et failover des deux chemins.

Créer Local Network Gateway

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

Renseigner :

1. Nom, par exemple lng-sophos-hq.
2. Endpoint comme IP publique ou FQDN du côté Sophos.
3. Local Address spaces : tous les préfixes locaux sans BGP ; avec BGP, le champ peut rester vide. Ajouter des préfixes statiques uniquement s’ils ne sont pas appris par BGP.
4. Sous Advanced, activer BGP et saisir ASN et BGP Peer IP Sophos.

Azure utilise normalement une adresse privée du GatewaySubnet comme peer BGP. Si Sophos utilise APIPA, attribuer à Azure une adresse unique entre 169.254.21.0 et 169.254.22.255 ; l’adresse locale peut être comprise entre 169.254.0.1 et 169.254.255.254. Les adresses ne doivent pas se chevaucher et Sophos doit initier la session APIPA. Voir le guide BGP Azure.

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. Comprendre et configurer en toute sécurité les profils IPsec Sophos Firewall explique comment les champs Sophos interagissent et comment cloner proprement un profil personnalisé. Les valeurs concrètes doivent toujours correspondre exactement à 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 :

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

Définir les deux traffic selectors sur Any. La firewall crée alors automatiquement une interface xfrm numérotée. SFOS ne crée pas de règles firewall automatiques pour Any-to-Any. NAT-T est toujours actif ; derrière un NAT amont, les IDs des peers doivent correspondre exactement.

Configurer route ou BGP

Sans BGP, utiliser Download configuration sur la Connection Azure pour obtenir les paramètres génériques, puis attribuer la première IP de tunnel, son masque et le MSS indiqués à XFRM sous Network > Interfaces. Sous Routing > Static routes > IPv4 unicast route, ajouter chaque préfixe Azure via cette interface. Gateway peut rester vide ou utiliser l’adresse peer du subnet de transfert téléchargé. Avec BGP, attribuer plutôt à XFRM l’IP et le masque du peer local saisis dans le Local Network Gateway ; le voisin Sophos est l’Azure BGP Peer IP affichée sous Virtual network gateway > Configuration. Ne pas inventer d’adresses de transfert.

Avec BGP, les deux côtés doivent être planifiés avec soin. Configurer BGP sur Sophos Firewall explique la configuration de base, l’autorisation sécurisée et la validation ; pour Azure, utiliser ensuite les valeurs de peer spécifiées par Azure :

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

Le design BGP Azure documenté utilise IPv4. L’ASN local doit différer de l’ASN Azure et ne peut être l’un des ASN réservés : 8075, 8076, 12076, 65515, 65517, 65518, 65519 ou 65520. Sous Administration > Device access, autoriser Dynamic Routing pour la zone VPN, puis vérifier les préfixes appris des deux côtés.

Pour le trafic généré par la firewall, vérifier d’abord l’adresse source réelle, les préfixes annoncés et le chemin retour. Si la source n’appartient pas à un préfixe local routé par Azure, une attribution sys-traffic-nat ciblée vers l’IP LAN de la firewall peut être nécessaire ; ne pas l’ajouter uniquement à cause de BGP. Acheminer le trafic système de manière ciblée via IPsec décrit le pre-check, la syntaxe Device Console, la validation et la suppression exacte.

NAT uniquement comme choix d’architecture

Azure NAT pour réseaux qui se chevauchent est limité aux S2S route-based sur VpnGw2 à VpnGw5 et VpnGw2AZ à VpnGw5AZ, sans policy-based traffic selectors. Le NAT statique est 1:1 et bidirectionnel ; le NAT dynamique est stateful et doit être initié depuis Internal mapping. Avec BGP, activer BGP route translation ; APIPA BGP n’est pas compatible avec Azure NAT. Voir les limites NAT Microsoft.

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 :

1. Ouvrir la Connection du VPN Gateway.
2. Vérifier l’état de connexion.
3. Observer les compteurs de données.
4. Contrôler les effective routes de l’Azure VM concernée.
5. 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 :

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

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

Dans Azure, VPN Gateway > Diagnostic settings avec IKEDiagnosticLog, TunnelDiagnosticLog, RouteDiagnosticLog et GatewayDiagnosticLog apporte de meilleures preuves qu’un reset. Comparer les timestamps d’un même test et ne reset la gateway qu’en dernier, car cela redémarre l’instance active.

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. Si plusieurs connexions IPsec utilisent les mêmes endpoints, vérifier aussi l’affectation du PSK : IKEv2 prend en charge un PSK propre à chaque combinaison de Local ID et Remote ID. IKEv1 ne prend en charge qu’un PSK par combinaison de gateway locale et distante ; SFOS applique celui de la connexion configurée en dernier. Des IDs uniques avec IKEv2 évitent cette collision.

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.

Azure est initiateur et le child SA expire

Quand Azure est l’initiateur, il ne rekey un child SA expirant que si du trafic traverse le tunnel. Sans trafic, il le supprime alors que la phase 1 reste établie. Un trafic ultérieur depuis Azure peut créer un nouveau child SA; un trafic provenant uniquement de derrière Sophos Firewall n’y parvient pas dans cet état. Initiate the connection sur Sophos convient donc à ce design. Le rekey de l’IKE SA Azure peut aussi causer une brève interruption.

Revenir en arrière sans détruire l’état

Avant tout changement, exporter ou documenter connexion Sophos, profil, adresse XFRM, routes et règles, puis SKU/génération Azure, Connection, Shared Key, BGP et NAT. Ne pas supprimer la Connection fonctionnelle : cloner le profil Sophos et relever la policy Azure dans Connection > Configuration ou via PowerShell.

En cas d’échec, réassigner l’ancien profil Sophos et restaurer exactement l’ancienne Custom Policy Azure, ou supprimer seulement la nouvelle policy si les defaults étaient utilisés. Réactiver la connexion et refaire les tests tunnel, routes et application. Ne pas supprimer préventivement gateway, Local Network Gateway, XFRM, routes ou NAT : cela détruit l’état connu et peut modifier IP publique ou routage.

FAQ