Configurer un VPN IPsec Site-to-Site Sophos Firewall

Un VPN IPsec Site-to-Site relie deux sites, ou une Sophos Firewall et un pare-feu tiers, au moyen d’un tunnel chiffré. Dans la pratique, ce type de tunnel échoue rarement à cause d’un seul paramètre de l’interface. Les causes sont plus souvent des réseaux mal définis, des profils IPsec différents, des règles de pare-feu manquantes, des cas particuliers de NAT ou un chemin de retour oublié d’un côté.

Procédure rapide : Choisir le type de tunnel, aligner le profil et les IDs, créer la connexion, router l’interface XFRM pour un route-based Any-to-Any, configurer les règles de pare-feu et de NAT, puis valider le tunnel avec du trafic réel, les logs et Packet Capture.

Cette procédure convient aux connexions Sophos à Sophos ou avec un équipement tiers entre un siège, une succursale ou une cloud gateway. Microsoft Azure et AWS exigent des détails supplémentaires propres au fournisseur : Connecter Sophos Firewall à Azure VPN Gateway et Connecter Sophos Firewall à AWS Site-to-Site VPN. Pour le Remote Access d’utilisateurs individuels, utilisez plutôt la comparaison entre Sophos Connect et SSL VPN. Si un tunnel existant est déjà vert mais qu’aucun trafic ne passe, consultez Sophos Firewall IPsec VPN Troubleshooting.

Si la connexion relie exclusivement deux Sophos Firewall et que la succursale doit établir le tunnel comme client vers un siège joignable de manière stable, SSL Site-to-Site VPN constitue une alternative plus simple. Pour les pairs tiers, la redondance, le routage dynamique ou les réseaux en croissance, IPsec route-based reste le choix le plus flexible.

Pour plusieurs pare-feu administrés par Sophos Fusion (anciennement Sophos Central), un groupe de connexions SD-WAN peut générer automatiquement les tunnels basés sur les routes, les interfaces XFRM, les routes et les règles facultatives. Cela ne remplace ni la planification de la topologie ni la validation locale du trafic.

Choisir entre policy-based et route-based

Avant la configuration, il faut décider si le tunnel sera policy-based ou route-based. En dehors de l’interface Sophos, route-based est aussi souvent appelé tunnel-based. Les deux termes désignent un tunnel doté de sa propre interface XFRM. En revanche, le terme “root-based”, parfois rencontré, n’est pas un mode VPN.

Sophos recommande les VPN route-based pour les nouveaux designs. Any-to-Any est particulièrement flexible pour les réseaux en croissance, car les modifications de routes ne coupent pas le tunnel. Les modifications de sous-réseaux ou de Traffic Selectors interrompent en revanche les connexions existantes. Les deux extrémités du tunnel doivent utiliser le même type : policy-based d’un côté et route-based de l’autre n’est pas pris en charge.

Pour utiliser OSPF ou BGP à travers le tunnel, une architecture route-based Any-to-Any avec des interfaces XFRM adressées est la plus explicite. Avant de mettre à niveau une ancienne configuration policy-based, vérifier si les réseaux VPN sont annoncés via redistribute kernel ; SFOS 22 : routes IPsec et redistribute kernel explique le changement de version et le cadre d’une migration sûre.

Ce que confirme réellement un tunnel vert

Un état tel que Established confirme que les pairs ont négocié IKE et au moins une Child SA. Il ne confirme pas qu’une route est sélectionnée, que la règle de pare-feu correspond, que le NAT est correct, que le pair connaît le chemin de retour ni que l’hôte cible répond. Un tunnel peut donc être vert sans transporter de trafic intersite utilisable.

Sophos Firewall utilise ESP en mode tunnel. ESP protège l’intégrité des données, authentifie l’origine des données transportées et offre une protection anti-rejeu contre les paquets rejoués.

Le chemin des données peut être représenté par le modèle mental suivant :

Policy-based
Source -> Règle de pare-feu -> Selector Local/Remote -> Child SA -> Pair -> Route de retour et règle -> Cible

Route-based Any-to-Any
Source -> Route ou SD-WAN Route -> Règle de pare-feu -> XFRM -> Child SA -> Pair -> Route de retour et règle -> Cible

Il s’agit d’un modèle de diagnostic et non d’une représentation complète de l’ordre de traitement interne de SFOS. La distinction reste néanmoins essentielle pour la recette : avec policy-based, la paire de réseaux de la connexion IPsec détermine le trafic qui appartient au tunnel. Avec route-based Any-to-Any, cette sélection est effectuée par le routage ou le SD-WAN.

Prérequis et données de planification

Avant la mise en place, documenter au minimum les informations suivantes :

• Extrémité locale : interface WAN de Sophos Firewall et adresse par laquelle le pair atteint cette interface.
• Remote Gateway : adresse IP publique ou DNS hostname du pair.
• Gateway type : généralement Respond only au siège et Initiate the connection dans la succursale.
• IP version : IPv4, IPv6 ou Dual. Dual est disponible uniquement pour les interfaces de tunnel route-based avec Any-to-Any comme sous-réseaux local et distant. Avec Dual, les règles de pare-feu IPv4 et IPv6 doivent être planifiées séparément.
• Réseaux locaux : par exemple 172.16.10.0/24 et 172.16.20.0/24.
• Réseaux distants : par exemple 10.20.30.0/24.
• Type de VPN : policy-based ou route-based. Le Connection type Host-to-host existe également, mais ce n’est pas le sujet de cette procédure pour les liaisons de sites.
• Listening interface : interface WAN du pare-feu local. Une bridge interface ne peut pas être utilisée.
• Version IKE : de préférence IKEv2 si le pair la prend en charge.
• Authentication type : Preshared key, Digital certificate ou RSA key.
• Local ID et Remote ID : particulièrement importants avec des FQDN, des pairs dynamiques, NAT-T ou une wildcard gateway.
• Profil IPsec : Encryption, Authentication, DH Group, PFS et Key life.
• Règles de pare-feu : Sources, Destinations et Services autorisés.
• NAT : aucun NAT ou SNAT/DNAT en raison de réseaux qui se chevauchent ou d’exigences du fournisseur.
• Exploitation : responsable, fenêtre de maintenance, plan de test, monitoring et procédure de retour.

Exemple cohérent pour les deux pare-feu

Les valeurs suivantes facilitent le suivi des étapes. Remplacez-les toutes par vos adresses WAN, réseaux et noms :

Créez d’abord les deux réseaux LAN comme objets sous Hosts and services > IP host. Au siège, 10.10.10.0/24 est le Local subnet et 10.20.20.0/24 le Remote subnet ; inversez-les dans la filiale. De même, la Local ID d’un côté doit être attendue comme Remote ID par l’autre. Le réseau de transfert 10.255.0.0/30, réservé au route-based Any-to-Any, ne doit chevaucher aucun réseau de production, VPN ou d’administration.

⚠️ Un VPN Site-to-Site ne doit pas être mis en œuvre sans chemin de retour documenté. Si le pare-feu local envoie le trafic dans le tunnel mais que le pair ne connaît pas la route retour ou attend un NAT différent, le tunnel paraît souvent sain alors que les applications ne fonctionnent pas.

Réseaux, profil, IDs et certificats

Les réseaux locaux et distants ne doivent pas se chevaucher involontairement. Les réseaux par défaut fréquents comme 192.168.0.0/24, 192.168.1.0/24 ou les réseaux de succursales réutilisés sont particulièrement problématiques. Des réseaux qui se chevauchent exigent un design NAT volontaire. Utiliser la même plage d’adresses des deux côtés et la traduire ensuite « d’une manière ou d’une autre » produit des tunnels difficiles à maintenir.

Un plan d’adressage IP propre est donc utile pour les nouveaux sites. Si les VLANs ou les zones ne sont pas encore correctement modélisés, consultez Configurer les zones et interfaces Sophos Firewall.

Les deux côtés doivent utiliser des paramètres compatibles en Phase 1 et Phase 2. Cela inclut le chiffrement, l’authentification, le DH group, PFS et la lifetime. Pour les connexions vers des pare-feu tiers, le plus simple est souvent de consigner d’abord un profil commun par écrit, puis de configurer les deux côtés.

Avec IKEv2, Sophos peut utiliser des Preshared Keys uniques pour chaque combinaison de Local ID et Remote ID. IKEv1 est plus limité, car un seul PSK s’applique par combinaison de gateways. Dans les environnements comportant plusieurs tunnels vers le même pair, il est préférable d’utiliser IKEv2 avec des IDs clairement définis.

⚠️ Avec IKEv1, le pare-feu utilise le PSK de la connexion configurée le plus récemment pour la même combinaison de gateway local et distant. Cela s’applique aux configurations IPsec site-to-site et d’accès distant. Configurer ensuite une connexion pour cette combinaison de gateways avec un PSK différent peut entraîner un échec d’authentification des connexions existantes lors d’une négociation ultérieure. Avant d’ajouter une telle connexion ou de modifier un PSK, vérifier toutes les configurations IKEv1 concernées et aligner le PSK avec leurs pairs respectifs avant la prochaine négociation.

NAT Traversal est toujours actif sur Sophos Firewall. Si un côté se trouve derrière un routeur ou un NAT fournisseur, les IDs deviennent plus importants, car l’adresse publique de la gateway n’identifie pas le pair de manière unique. Le Local ID d’un côté doit correspondre au Remote ID attendu par l’autre. Les IDs de type DNS, IP ou e-mail n’ont pas besoin d’être résolus publiquement, mais leurs formats et leurs valeurs doivent correspondre de manière croisée.

Sophos Firewall ne propose pas de commutateur NAT-T distinct : Les appareils détectent automatiquement la présence d’un NAT. Sans NAT, les négociations IKE utilisent UDP 500 et le trafic utile emploie ESP via IP protocol 50. Lorsque le pare-feu détecte un équipement NAT, il encapsule dans UDP 4500 les négociations IKE et de phase 2 suivantes ainsi que les paquets ESP.

Si un équipement NAT se trouve sur le chemin IPsec et que le pair est un pare-feu tiers, NAT-T doit également y être activé. Le réglage est vérifié à l’aide de la documentation de ce pair ; aucun commutateur supplémentaire n’est nécessaire sur Sophos Firewall.

Les pairs détectent un équipement NAT pendant l’échange IKE de phase 1 et conviennent alors d’utiliser NAT-T. ESP est un protocole de couche 3 sans informations de ports de couche 4, tandis que PAT peut également traduire les ports. L’encapsulation UDP via le port 4500 fournit donc une enveloppe UDP identifiable sur le chemin NAT ; le pair retire cette enveloppe et traite le paquet IPsec d’origine.

Si Sophos Firewall se trouve lui-même derrière un routeur, ce dernier doit appliquer une règle DNAT ou une redirection de ports de l’adresse publique vers le Listening interface privé du pare-feu. Le chemin NAT-T doit autoriser UDP 500 et UDP 4500 ; ESP natif via IP protocol 50 n’est nécessaire que sur un chemin sans NAT. Cette logique est distincte de la planification ultérieure de SNAT ou DNAT pour des réseaux qui se chevauchent ou un trafic utile traduit.

Avec Digital certificate, les formats et les rôles des certificats doivent correspondre exactement des deux côtés. Sophos ne prend pas en charge les certificats ECDSA pour les connexions IPsec ; des certificats RSA sont requis. Il ne faut pas utiliser une CA publique de manière générale comme Remote CA Certificate, car cela accorderait trop de confiance à des certificats tiers. RSA key est un Authentication type distinct : les deux pare-feu échangent leurs clés publiques et doivent utiliser le même format PKCS1 ou DNS.

La modification de la CA locale Default d’un Sophos Firewall constitue un changement de trust anchor, pas une modification cosmétique du certificat. Les pairs avec un Default.pem importé et les certificats signés localement doivent être migrés de manière contrôlée. Renouveler de manière contrôlée la Default CA de Sophos Firewall explique l’inventaire, la fenêtre de maintenance, les tests et la récupération.

Si Digital certificate est sélectionné, le choix dans le formulaire ne suffit pas. La confiance envers la CA, les certificats locaux, ceux du pair ainsi que les Certificate IDs doivent être préparés. La procédure complète est décrite dans Configurer un IPsec Site-to-Site avec des certificats. Si la CA révoque des certificats avant leur expiration, la liste de révocation actuelle doit aussi figurer dans le plan d’exploitation. Une procédure distincte explique l’importation de la CRL, le contrôle de nextUpdate et le test négatif contrôlé sur Sophos Firewall.

Si un tunnel ne monte pas, NO_PROPOSAL_CHOSEN, les erreurs d’ID ou les erreurs d’authentification sont des indices typiques. La section Tester le tunnel et résoudre les erreurs commence par les contrôles adaptés.

Configurer un IPsec policy-based

Le policy-based IPsec est la variante classique pour les connexions Site-to-Site simples. Les réseaux locaux et distants sont définis directement dans la connexion IPsec.

1. Vérifier ou créer le profil IPsec

Chemin de menu :

Profiles > IPsec profiles

Vérifier d’abord si un profil existant correspond au pair. Si un profil dédié est nécessaire, lui donner un nom explicite, par exemple Branch-Zurich-IKEv2. Le nom doit rester compréhensible lorsque plusieurs tunnels et pairs existent.

Documenter au minimum :

• Version IKE
• Phase 1 Encryption et Authentication
• DH Group
• Phase 2 Encryption et Authentication
• PFS
• Key life

Pour les pare-feu tiers, le pair doit confirmer les mêmes valeurs par écrit. Une capture d’écran seule ne suffit souvent pas, car certains champs portent des noms différents selon le fabricant.

L’interaction entre Phase 1, Phase 2, PFS, Lifetimes, Rekeying et DPD est expliquée dans Comprendre et configurer en toute sécurité les profils IPsec Sophos Firewall. Avant l’activation, vérifiez Dead peer detection : Sophos prévoit Hold ou Disconnect pour le peer qui répond et Re-initiate pour l’initiateur. Un groupe de failover IPsec modifie ce comportement et ne suit pas la même logique DPD.

2. Ajouter la connexion IPsec

Chemin de menu :

Site-to-site VPN > IPsec

Créer une nouvelle connexion IPsec et choisir Policy-based comme Connection type. Définir ensuite les données de base :

• Nom du tunnel, par exemple branch-zurich
• IP version, généralement IPv4
• Gateway type, par exemple Respond only au siège ou Initiate the connection dans la succursale
• Listening interface comme interface WAN locale
• Gateway address du pair sous forme d’adresse IP ou de DNS hostname
• Authentication type : Preshared key, Digital certificate ou RSA key
• Local ID et Remote ID si nécessaire
• IPsec profile
• Local subnet
• Remote subnet

Avec un IPsec policy-based, un seul côté au maximum des Traffic Selectors peut être défini sur Any. Avec plusieurs réseaux locaux et distants spécifiques, Sophos crée une Phase 2 SA pour chaque combinaison.

Avec Respond only, l’adresse wildcard * peut être utile si plusieurs succursales ou pairs dynamiques se connectent au siège. Au moins un Local ID ou Remote ID doit alors être défini ; les deux IDs sont généralement utiles pour une attribution sans ambiguïté. Le Local ID d’un côté correspond au Remote ID attendu par l’autre. Initiate the connection ne prend pas en charge une adresse wildcard ; le pair doit donc être défini par une adresse IP ou un DNS hostname.

Utiliser une Preshared Key forte et unique et la documenter de manière sûre. Réutiliser une ancienne clé par défaut partagée entre plusieurs sites représente un risque d’exploitation inutile.

Créez ensuite la connexion en miroir sur le peer. Ici, le siège attend 203.0.113.20 avec Respond only ; ses réseaux Local/Remote sont 10.10.10.0/24 et 10.20.20.0/24. La filiale utilise Initiate the connection, l’adresse de gateway 198.51.100.10 et inverse les réseaux et IDs Local/Remote. Profil, authentification et PSK doivent être compatibles. N’activez la connexion qu’après avoir enregistré les deux entrées et vérifié les règles.

Les paramètres avancés de User authentication mode concernent uniquement les profils IKEv1 avec une logique XAuth, par exemple de très anciens designs client-serveur. Pour les connexions Site-to-Site normales avec IKEv2, il ne faut pas en déduire une étape d’authentification supplémentaire. De même, les anciens paramètres d’idle connection ne doivent pas être intégrés à un design d’exploitation moderne.

3. Activer le tunnel

Lors de l’enregistrement, Activate on save peut être sélectionné. En environnement de production, cela doit se faire pendant une fenêtre de maintenance définie, lorsque le pair est joignable et que les deux côtés peuvent contrôler les logs.

Après l’enregistrement, la liste affiche deux états pertinents :

• si la connexion est active
• si le tunnel est réellement established

Une entrée active n’est pas automatiquement un tunnel établi. Avec plusieurs réseaux locaux ou distants, il peut également y avoir plusieurs Security Associations.

Configurer un IPsec route-based

Le route-based IPsec sépare la négociation VPN de la sélection de route. Avec Any-to-Any, SFOS fournit une interface XFRM dédiée et adressable. Pour des Traffic Selectors spécifiques, la documentation SFOS 22 actuelle se contredit sur la création de l’interface, comme expliqué ci-dessous.

1. Créer la connexion en route-based

Chemin de menu :

Site-to-site VPN > IPsec

Choisir Route-based (Tunnel interface) pour la connexion. Les paramètres de gateway, d’authentification, d’IDs et de profil IPsec doivent toujours correspondre au pair. Il faut également comprendre quelle interface XFRM sera créée et comment elle sera routée.

2. Mettre en œuvre Any-to-Any ou Traffic Selectors

Pour Any-to-Any, Sophos affiche l’interface XFRM générée sous l’interface physique utilisée dans :

Network > Interfaces

Une interface XFRM générée reste toujours affectée à la zone VPN. Les deux variantes se configurent différemment.

Any-to-Any avec IPv4, IPv6 ou Dual

Lorsque Local subnet et Remote subnet sont tous deux définis sur Any, SFOS crée automatiquement l’interface XFRM de la connexion IPsec route-based. Il n’y a pas d’interface XFRM distincte à ajouter. Sous Network > Interfaces, développez l’interface physique choisie comme Listening interface, puis ouvrez l’interface XFRM générée. Attribuez 10.255.0.1/30 au siège et 10.255.0.2/30 à la filiale. Avec Dual, des règles IPv4 et IPv6 distinctes sont aussi requises.

Le champ Name modifiable est le nom d’affichage. Il ne faut pas le confondre avec les valeurs attribuées par SFOS : Hardware est le nom de l’enregistrement, IPsec connection la connexion route-based associée et Network zone toujours VPN. Configurez uniquement les champs d’adresse correspondant à la version IP sélectionnée dans la connexion IPsec :

• IPv4/netmask : saisissez l’adresse IPv4 de transit prévue et sélectionnez son subnet.
• IPv6/prefix : saisissez l’adresse IPv6 de transit prévue et son préfixe.
• Avec Dual, configurez les deux familles. Si la connexion utilise uniquement IPv4 ou IPv6, SFOS n’applique pas les valeurs saisies pour l’autre version.

Sous Advanced settings > Interface settings, conservez le MTU par défaut ou saisissez la valeur testée explicitement. SFOS calcule la valeur par défaut en soustrayant la surcharge IPsec maximale du MTU de l’interface physique. Activez Override MSS et saisissez une valeur uniquement si le réseau exige une valeur différente de celle par défaut du pare-feu ; ne supposez pas de valeur numérique non documentée.

Avant toute modification, relevez le nom, les adresses, le MTU, l’état et la valeur d’Override MSS ainsi que les routes ou gateways dépendants. Après l’enregistrement, rouvrez l’interface et vérifiez que Hardware, IPsec connection et la zone VPN attribués n’ont pas changé. Exécutez ensuite Route lookup sur les deux peers et testez du trafic réel dans les deux sens, y compris un transfert volumineux si MTU ou MSS a changé. Pour revenir en arrière, restaurez les champs relevés et les routes ou gateways précédents. Pour une nouvelle connexion, désactivez-la et supprimez uniquement ses routes et règles dépendantes ; n’essayez pas de supprimer ou recréer séparément l’interface XFRM générée.

Créez ensuite, des deux côtés, la route vers le LAN distant via Routing > Static routes > IPv4 unicast route > Add :

• Siège : Destination 10.20.20.0/24, Interface l’interface XFRM locale.
• Filiale : Destination 10.10.10.0/24, Interface l’interface XFRM locale.

Vous pouvez aussi employer une SD-WAN Route ou un routage dynamique via BGP ou OSPF. Avec une SD-WAN Route, décidez explicitement si un autre chemin peut servir de secours. Sinon, activez Route only through specified gateways et testez séparément la panne du tunnel.

Les routes et les règles de pare-feu décident quel trafic entre dans le tunnel. Une route statique simple peut pointer directement vers l’interface XFRM. Pour plusieurs liaisons, des contrôles SLA ou certains designs de Failover, une Custom Gateway avec l’adresse IP XFRM du pair est créée en plus et utilisée dans une SD-WAN Route.

Les tunnels Any-to-Any peuvent contrôler plusieurs XFRM Gateways directement via SD-WAN et des contrôles SLA ; aucun VPN Failover Group supplémentaire n’est nécessaire. Les tunnels Policy-based et les tunnels Route-based avec Traffic Selectors utilisent en revanche un groupe de failover IPsec pour les connexions redondantes. La procédure associée explique l’ordre, le Health Check, Automatic failback et le test de panne contrôlé. Le groupe désactive DPD pour les connexions affectées et définit Key negotiation tries sur 3.

Après l’enregistrement, vérifiez quatre points :

1. L’interface XFRM est visible sous Network > Interfaces et possède l’IP de transfert prévue.
2. La route vers le réseau distant pointe directement vers l’interface XFRM ou, dans un design avec gateway/SD-WAN, vers le gateway XFRM approprié.
3. Diagnostics > Tools > Route lookup renvoie l’interface ou le gateway XFRM attendu pour un hôte réel du LAN distant. Répétez le test sur le peer.
4. Les règles n’autorisent que les directions et services prévus.

Traffic Selectors

Avec des subnets spécifiques, le comportement de SFOS 22 dans ce cas particulier n’est pas univoque : une interface XFRM peut être absente, mais le pare-feu peut aussi en créer une par configuration de Traffic Selectors. Développez la Listening interface sous Network > Interfaces et vérifiez l’état réel du build installé ; une interface XFRM existante peut également être sélectionnée sous Diagnostics > Packet capture. Si une interface XFRM apparaît, ne lui attribuez ni adresse IP ni route. La route statique est créée automatiquement une fois le tunnel established. Any d’un seul côté avec un selector spécifique de l’autre n’est pas pris en charge.

Cette variante convient aux petits réseaux clairement définis. Si l’interface est visible, utilisez-la comme documenté pour confirmer le trafic sortant sous Diagnostics > Packet capture ; vérifiez aussi la route automatique, les Child SAs, les logs et le trafic dans les deux sens. WAF via IPsec route-based avec Traffic Selectors n’est pas pris en charge.

Un tunnel Any-to-Any ne peut pas être modifié directement pour utiliser des Traffic Selectors spécifiques. Il faut cloner ou recréer la connexion, puis effectuer une bascule contrôlée.

3. Tenir compte de XFRM et MTU

Les VPN route-based sont plus sujets aux malentendus concernant le routage, MTU et MSS. Si de petits tests fonctionnent mais que des transferts plus importants restent bloqués, ne pas modifier immédiatement le profil IPsec. Vérifier d’abord MTU, MSS, la fragmentation et le chemin réel. La procédure adaptée est décrite dans Vérifier MTU et MSS sur Sophos Firewall en cas de problèmes VPN.

Règles de pare-feu, NAT et Device Access

Règles de pare-feu et règles automatiques

Après la configuration IPsec, des règles sont nécessaires pour le trafic de production. Sans règles adaptées, le tunnel peut être vert mais les applications ne fonctionneront pas.

Chemin de menu :

Rules and policies > Firewall rules

Règles typiques :

• Réseau local vers réseau distant : par exemple LAN vers VPN.
• Réseau distant vers réseau serveur local : par exemple VPN vers Server.
• Management ou monitoring : autoriser uniquement les systèmes d’administration ou de monitoring définis.
• DNS, AD, RDP, HTTPS : autoriser uniquement les services nécessaires, pas un Any global.

Les interfaces XFRM appartiennent toujours à la zone VPN. Lorsque les deux directions sont utilisées, des règles inbound et outbound correspondantes sont nécessaires. Des règles séparées avec logging montrent plus clairement, lors de la recette, quels services sont accessibles depuis chaque côté. La structure générale est décrite dans Créer et vérifier en toute sécurité les règles Sophos Firewall.

Les paquets IPsec entrants sont d’abord désencapsulés et déchiffrés. La règle de pare-feu correspondante applique ensuite ses politiques de sécurité au trafic utile avant son transfert vers la destination. Pour le trafic sortant, la règle de pare-feu correspondante s’applique avant l’encapsulation et le chiffrement.

L’option Create firewall rule crée des règles distinctes avec les préfixes Incoming et Outgoing en haut de la liste. Ensuite :

• Vérifier la position des règles.
• Restreindre Source et Destination.
• Réduire Any aux Services nécessaires.
• Activer Log firewall traffic pour le déploiement et l’analyse des erreurs.
• Sélectionner consciemment IPS, Web, Application Control et les autres Security Features.
• Donner à la règle un nom explicite, par exemple LAN_to_Branch_Zurich.

⚠️ Les règles de pare-feu créées automatiquement sont un point de départ, pas un design de sécurité terminé. En particulier pour les tunnels de sites vers des réseaux serveurs, réduire les services, les Sources et les Destinations après le premier test.

Sophos ne peut pas créer automatiquement de règles pour un route-based Any-to-Any. Avec Dual, les règles IPv4 et IPv6 sont créées séparément. Si le trafic Internet d’une succursale doit passer par le siège, un design NAT et sécurité distinct est également nécessaire.

Planifier le NAT selon le type de tunnel

Le NAT n’est pas interdit avec IPsec, mais doit être justifié. Cas typiques : réseaux qui se chevauchent, exigences cloud ou adresses source imposées par un tiers. Le NAT ne remplace pas une route et ne modifie pas la décision de routage : indépendamment de la traduction, SFOS doit sélectionner une route VPN, statique, SD-WAN ou dynamique adaptée.

Chemin de menu :

Rules and policies > NAT rules

Avant de créer une règle NAT, répondre aux questions suivantes :

• Le pair attend-il les adresses IP originales ou des adresses traduites ?
• Existe-t-il des réseaux qui se chevauchent ?
• NAT est-il configuré dans la connexion IPsec ou au moyen de règles NAT séparées ?
• Le sens retour est-il documenté ?
• Log Viewer montre-t-il les Source et Destination attendues après NAT ?

La logique NAT diffère selon le type de VPN :

• Avec un IPsec policy-based et un VPN route-based avec Traffic Selectors, le NAT pour les réseaux qui se chevauchent peut être configuré directement dans la connexion IPsec.
• Avec un route-based Any-to-Any, utiliser des règles SNAT et DNAT sous Rules and policies > NAT rules.
• Avec des réseaux qui se chevauchent, les deux côtés doivent comprendre le même plan de traduction. Un NAT unilatéral sans planification du chemin retour produit souvent des tunnels verts sans trafic exploitable.

⚠️ Avec IPsec route-based et Traffic Selectors, utilisez le NAT de la connexion IPsec et n’attribuez ni adresse IP ni route manuelle à une interface XFRM si le build installé en affiche une. IPsec avec NAT pour des réseaux qui se chevauchent présente la configuration symétrique complète des adresses, du DNS et du NAT.

Si le trafic d’un VPN route-based avec Traffic Selectors correspond à une règle SNAT avec Translated source = MASQ, le pare-feu rejette les paquets, car ces interfaces XFRM n’ont pas d’adresse IP attribuée. Cela peut expliquer un tunnel vert sans trafic exploitable. Pour le flux de test concerné, vérifier la règle NAT correspondante et sa position, puis corriger uniquement la règle en conflit ; ne pas désactiver MASQ de façon générale pour les autres connexions. Vérifier ensuite à nouveau le même flux dans les deux sens avec Log Viewer et Packet Capture.

Si le trafic utile IPsec policy-based est traduit par une règle SNAT distincte, son Outbound interface doit être Any. Une règle limitée à certains ports WAN — généralement la règle SNAT par défaut — ne s’applique pas à ce trafic VPN. Avec Any, le pare-feu utilise la valeur Translated source configurée dans la règle SNAT correspondante. Ce comportement s’applique également lorsque Override source translation (SNAT) est activé pour des interfaces de sortie spécifiques.

Depuis SFOS 22, IPsec policy-based crée la route VPN dans le backend. Une ipsec_route manuelle n’est pertinente que pour certains scénarios de trafic transféré et n’est pas une étape standard ; le trafic généré par le système n’en a pas besoin. Voir aussi Comprendre les règles NAT de Sophos Firewall.

Device Access pour les connexions IPsec entrantes

Pour les requêtes IPsec entrantes, le pare-feu doit pouvoir accepter le trafic IPsec sur la zone WAN appropriée. Cela ne se règle pas par une règle LAN-to-WAN normale, mais par les services locaux du pare-feu.

Chemin de menu :

Administration > Device access

IPsec doit être autorisé pour WAN lorsque le pare-feu accepte des requêtes entrantes, par exemple avec Respond only. Cela ne remplace pas les règles pour le trafic utile dans le tunnel. Vérifier en même temps si WebAdmin, SSH, User Portal ou VPN Portal sont accessibles trop largement. Pour durcir ces services locaux, consultez Sécuriser l’accès Sophos Firewall : configurer correctement Device Access.

Tester le tunnel et résoudre les erreurs

Un bon test de recette ne vérifie pas seulement l’état vert. Il vérifie le flux de données réel.

Définir une matrice de recette

Avant le premier test, définir une petite matrice de recette. Elle indique clairement quelles connexions doivent fonctionner et lesquelles doivent volontairement rester bloquées.

Cas de test utiles :

• Réseau client local vers réseau serveur distant : test applicatif typique, par exemple HTTPS, RDP, SMB, SQL ou ICMP uniquement comme test de base.
• Réseau client distant vers réseau serveur local : vérifier le sens inverse si la connexion est utilisée dans les deux directions.
• DNS ou AD à travers le tunnel : tester uniquement si ces services doivent réellement passer par le tunnel. Définir précisément Source, serveur cible et port.
• Monitoring ou sauvegarde : vérifier que les systèmes prévus accèdent depuis le bon sens et ne nécessitent pas accidentellement des règles Any.
• Test bloqué : un port ou un réseau volontairement non autorisé doit être bloqué. Sinon, la base de règles est trop large.
• Transfert volumineux : pour les transferts de fichiers, RDP, VoIP ou les problèmes applicatifs, observer également MTU/MSS et la fragmentation.

Pour chaque cas de test, noter la Source IP, la Destination IP, le Service, la règle de pare-feu attendue, la règle NAT attendue et le sens attendu. Après chaque test, comparer Log Viewer, Packet Capture et les compteurs d’octets. Si seul le ping est testé, le tunnel n’est pas encore validé.

1. Vérifier le statut

Dans l’interface WebAdmin :

Site-to-site VPN > IPsec

Vérifier :

• La connexion est active.
• Le statut du tunnel est established.
• Avec plusieurs réseaux, toutes les Child SAs attendues sont établies.

Sous Current activities > IPsec connections, filtrez les connexions réellement établies par Connection name, Local subnet ou Remote subnet, puis actualisez la vue avec Refresh. Disconnect interrompt une SA de manière contrôlée, par exemple quand les deux côtés sont prêts pour une modification ; il ne remplace pas la désactivation ou le retour arrière.

Déterminez le nombre attendu : route-based Any-to-Any crée une connexion Phase 2 par interface XFRM ; Dual en crée une pour IPv4 et une pour IPv6. Policy-based et route-based avec Traffic Selectors en créent une pour chaque combinaison de Local et Remote subnet.

Avant d’envoyer le premier trafic utile via le tunnel route-based Any-to-Any, vérifiez l’adresse réelle de l’hôte de destination sous Diagnostics > Tools > Route lookup. Sur chaque pare-feu, le résultat doit pointer vers l’interface ou le gateway XFRM prévu.

2. Vérifier Log Viewer

Chemin de menu :

Log viewer

Générer un trafic de test avec une Source, une Destination et un Service clairs. Vérifier ensuite dans Log Viewer quelle règle de pare-feu correspond et si NAT, Webfilter, IPS ou d’autres modules influencent le trafic. La procédure est décrite dans Tester une règle de pare-feu avec Log Viewer, Policy Test et Packet Capture. Les rekeys, disconnects et erreurs de connexion récurrents doivent être vérifiés dans les logs IPsec, et non déduits de l’état actuel des SAs.

3. Packet Capture et Advanced Shell

Si Log Viewer ne suffit pas, utiliser Packet Capture avec un filtre étroit :

Diagnostics > Packet capture

Exemple de filtre :

host 172.16.10.25 and host 10.20.30.15

Lors d’un troubleshooting VPN, il est important de vérifier les deux directions. Des paquets sortants sans réponse indiquent généralement un problème de chemin retour, de NAT ou du pair.

Advanced Shell

Pour un troubleshooting plus approfondi via SSH, ouvrir 5. Device Management > 3. Advanced Shell et vérifier l’état actuel des SAs :

ipsec statusall

Les éléments pertinents comprennent :

• IKE SA established
• Child SA installed
• Traffic Selectors locaux et distants
• compteurs d’octets dans les deux directions

Si SSH n’est pas encore préparé, consultez Se connecter à Sophos Firewall via SSH.

Logs IPsec actuels

La vue actuelle des logs SFOS 22 sépare les fonctions :

• strongswan.log : service IPsec et connexions.
• charon.log : service IPsec et NAT dans les connexions IPsec.
• ipsec_monitor.log : monitoring du service IPsec.
• /log/ipsec_conn/ipsec_<connectionname>.log : activation, désactivation et connexion via WebAdmin.
• xfrmi.log : interfaces XFRM pour le route-based IPsec.
• dgd.log : uniquement en complément pour le failover VPN, le SD-WAN, DGD ou Link Load Balancing, et non comme log IPsec général.

Pour un diagnostic complet des logs et de XFRM, consultez Sophos Firewall IPsec VPN Troubleshooting.

Erreurs typiques

• Le tunnel ne monte pas : la version IKE, le profil, le PSK, le certificat, le Local ID ou le Remote ID ne correspond probablement pas. Vérifier strongswan.log, le profil IPsec et le pair.
• Phase 1 est établie, Phase 2 ne l’est pas : les réseaux locaux ou distants, ou la Phase 2 proposal, ne correspondent probablement pas. Vérifier les Traffic Selectors, les sous-réseaux et PFS.
• Le tunnel est vert, mais aucun accès n’est possible : une règle de pare-feu, NAT, le routage ou le chemin retour manque probablement. Vérifier Log Viewer, Packet Capture et le routage.
• Une seule direction fonctionne : le pair ne connaît pas la route retour ou NAT est incorrect. Vérifier le pair, les règles NAT et les compteurs d’octets.
• Les petits pings fonctionnent, mais les applications se bloquent : MTU/MSS, la fragmentation ou une Security Feature est probablement en cause. Vérifier MTU/MSS et Packet Capture.
• Le route-based Any-to-Any ne fonctionne pas : l’IP XFRM, la gateway, la route ou la règle de pare-feu ne correspond probablement pas. Vérifier Network > Interfaces, le routage et les règles de la zone VPN.
• Le route-based avec Traffic Selectors ne fonctionne pas : vérifiez si le build réel affiche l’interface XFRM sous la Listening interface. Si elle apparaît, utilisez-la dans Packet Capture, mais ne lui attribuez ni IP ni route. Vérifiez aussi la route automatique, les Selectors, les règles de la zone VPN et une éventuelle règle MASQ.
• Plusieurs tunnels s’influencent : des réseaux qui se chevauchent ou des configurations de Selectors similaires sont probables. Vérifier les objets tunnel, le failover group et les routes.

Retour arrière après un échec de recette

Revenez en arrière de manière contrôlée plutôt que de supprimer des objets au hasard :

1. Sous Current activities > IPsec connections, interrompez la SA avec Disconnect, puis désactivez la nouvelle connexion IPsec.
2. Désactivez uniquement les routes statiques ou SD-WAN, règles NAT et règles de pare-feu créées pour ce changement, y compris les règles VPN automatiques. Ne supprimez pas séparément une interface XFRM générée si le build l’affiche ; la désactivation de la connexion gère cette interface.
3. Lors d’une migration, réaffectez le profil précédent à l’ancienne connexion, puis réactivez la connexion et l’ancien chemin de routage.
4. Retestez le flux initial et le trafic Internet local ou intersite avec Log Viewer et Packet Capture.
5. Ne supprimez les nouveaux objets qu’après avoir vérifié dans Object Usage qu’aucune dépendance ne subsiste et que l’ancien chemin fonctionne à nouveau.

Checklist

Avant le changement :

• Les réseaux locaux et distants sont sans ambiguïté.
• Le choix entre policy-based et route-based a été fait consciemment.
• Le profil IPsec est aligné avec le pair.
• La Preshared Key, les certificats ou les clés RSA sont documentés de manière sûre.
• Les règles de pare-feu sont planifiées, y compris la direction, la position, le logging et les services.
• Avec Create firewall rule, les règles créées automatiquement à retravailler sont connues.
• Pour un route-based Any-to-Any, l’IP XFRM, la gateway, les règles de pare-feu manuelles et les routes sont planifiées.
• Pour un route-based avec Traffic Selectors, la visibilité XFRM réelle est consignée ; aucune IP XFRM ni route manuelle n’est prévue, que le build affiche ou non l’interface.
• NAT est soit exclu, soit documenté consciemment.
• Device Access pour les connexions IPsec entrantes a été vérifié.
• La fenêtre de maintenance, le pair et la procédure de retour sont connus.

Après le changement :

• Le statut du tunnel est established.
• La matrice de recette, avec au moins un test pour chaque direction requise, a été exécutée avec succès.
• Log Viewer montre la règle de pare-feu attendue.
• Packet Capture montre le trafic aller et retour.
• Les accès DNS internes et applicatifs ont été testés.
• Les compteurs d’octets augmentent dans les deux directions.
• NAT et le chemin retour sont alignés avec le pair.
• Le changement est reporté dans la documentation réseau.

Questions fréquentes