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 à une adresse statique, 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.

Pour les IDs de l’exemple, définissez Local ID type = DNS et Remote ID type = DNS sur les deux pare-feu. Au siège, renseignez Local ID vpn-hq.example.invalid et Remote ID vpn-branch.example.invalid ; dans la filiale, inversez exactement ces valeurs. Ces valeurs identifient les pairs ; elles ne servent pas à la résolution DNS de leurs adresses de gateway. Si vous utilisez un autre type d’ID, le type et le format doivent également correspondre de manière croisée.

Pour chacun des objets réseau IPv4, sélectionnez Add, IP version = IPv4, Type = Network, puis renseignez l’adresse réseau et le masque de sous-réseau /24 avant d’enregistrer. Des noms explicites sont HQ_LAN pour 10.10.10.0/24 et Branch_LAN pour 10.20.20.0/24 ; les deux objets sont nécessaires sur les deux pare-feu. Un objet hôte est, en revanche, destiné à une adresse individuelle de test ou de monitoring.

Le choix de la filiale comme initiateur répartit les tentatives de reconnexion entre les filiales et convient lorsque l’adresse IP WAN de la filiale change. Si un initiateur doit joindre un pair dont l’adresse IP WAN est dynamique, la Gateway address de ce pair doit contenir un nom d’hôte DNS qui se résout effectivement vers son adresse publique actuelle. Configurer et vérifier Dynamic DNS sur Sophos Firewall décrit l’enregistrement et le test de résolution. Une simple ID de type DNS n’est pas une adresse de gateway joignable. Configurer DDNS uniquement au siège ne permet pas de retrouver l’adresse dynamique de la filiale.

⚠️ 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. Dans l’exemple utilisé tout au long de cette procédure, l’adresse WAN du routeur du siège peut être 198.51.100.10, tandis que l’interface WAN du pare-feu utilise 172.31.255.2. Le siège sélectionne alors son interface WAN privée comme Listening interface ; la filiale continue à se connecter à 198.51.100.10, et non à 172.31.255.2. Le routeur traduit l’adresse de destination, de son adresse publique vers 172.31.255.2. Les Selectors LAN restent, au siège, Local 10.10.10.0/24 et Remote 10.20.20.0/24, et sont exactement inversés dans la filiale.

Pour NAT-T, UDP 500 et UDP 4500 doivent être autorisés. Les procédures SFOS 22 et SFOS 23 relatives à un pare-feu derrière un routeur mentionnent également IP protocol 50, et non le port TCP/UDP 50. Lorsque NAT-T est négocié, ESP est encapsulé dans UDP 4500 ; ESP natif utilise le protocole 50. La liste des autorisations sur le routeur et l’explication de NAT-T ne doivent donc pas être considérées comme décrivant des chemins de paquets identiques. Avant le changement, documentez les fonctions du routeur et les redirections existantes, puis vérifiez à l’aide des logs IKE et de Packet Capture quel chemin est réellement utilisé. Ne supprimez pas une autorisation ESP existante sans l’avoir vérifiée ; limitez les autorisations supplémentaires aux adresses des pairs prévus. Si la négociation n’aboutit pas, restaurez la configuration documentée du routeur. Ce point est distinct du SNAT/DNAT pour des LAN qui se chevauchent ou pour du 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. Local certificate appartient au pare-feu local, Remote certificate au pair, et Remote CA certificate constitue la base de confiance pour le certificat de ce pair. N’utilisez pas de CA publique comme Remote CA certificate : un attaquant disposant d’un certificat valide émis par cette CA pourrait sinon obtenir un accès non autorisé. Avec le type d’ID DER.ASN1 DN (X.509), le Distinguished Name du certificat concerné est utilisé ; renseignez le DN du certificat du pair comme Remote ID.

RSA key est un Authentication type distinct, et non une option de sélection d’un certificat RSA. Le pare-feu génère automatiquement la paire de clés et affiche uniquement la clé publique sous Local RSA key. Copiez celle-ci dans Remote RSA key sur le pair, puis insérez la clé publique du pair dans le champ Remote RSA key du pare-feu local. Les deux côtés doivent utiliser le même format PKCS1 ou DNS. Les clés privées ne sont pas transférées entre les pare-feu.

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

Pour cet exemple policy-based, sélectionnez des réseaux spécifiques des deux côtés. La documentation SFOS 22 et SFOS 23 n’est pas formulée de manière uniforme concernant Any : la présentation de Policy-based indique que Any ne peut pas être sélectionné pour les sous-réseaux locaux et distants ; la procédure Add an IPsec connection autorise Any d’un seul côté au maximum. N’en déduisez pas qu’une configuration policy-based Any-to-Any est possible. Si Any est nécessaire d’un seul côté, vérifiez avant la mise en œuvre l’option proposée par le build installé, les Selectors du pair et le routage prévu dans une configuration de test isolée. En cas de SA ou d’affectation du trafic inattendue, désactivez la nouvelle connexion et restaurez les Selectors spécifiques documentés. Avec plusieurs réseaux locaux et distants spécifiques, une Phase 2 SA est créée par combinaison : deux réseaux locaux et deux réseaux distants produisent quatre SAs. Toutes les connexions policy-based partagent une même interface IPsec ; une capture sur cette interface ne suffit donc pas, à elle seule, à identifier le tunnel.

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.

Avec Authentication type = Preshared key, saisissez le PSK convenu, puis répétez-le dans le champ de confirmation. Sur le pair, saisissez exactement le même PSK et confirmez-le également ; la configuration en miroir des IDs ne modifie pas la clé partagée. Échangez le PSK uniquement par le canal sécurisé prévu, et ne l’incluez ni dans des captures d’écran ni dans des tickets publics.

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.

Sans Activate on save, la connexion enregistrée est activée à l’aide de son bouton Status sous Site-to-site VPN > IPsec. Il faut distinguer cette action du réglage Gateway type = Disable : avec ce réglage, la connexion reste inactive jusqu’à son initiation par l’utilisateur. Respond only attend les requêtes ; Initiate the connection démarre la négociation également après un redémarrage du service VPN ou du pare-feu. Après un simple Disconnect, un initiateur peut se reconnecter ; pour un retour arrière, il faut donc aussi désactiver la connexion.

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.

API XML : distinguer configuration et actions de contrôle

Pour automatiser cette procédure, ne traduisez pas simplement les champs de la GUI en requête XML. La référence API de SFOS 22 et SFOS 23 présente les paramètres sous VPNIPSecConnection/Configuration, puis les branches de contrôle distinctes Active, DeActive, Connection et DisConnection, chacune avec Name. Le commentaire de l’exemple précise que ces quatre branches ne fonctionnent qu’après la création de la connexion. L’exemple de configuration contient séparément Status avec Active/Deactive ; la ligne de ActivateOnSave indique y/n. L’enregistrement, l’activation, le comportement après un redémarrage et un tunnel réellement établi ne sont donc ni des paramètres interchangeables ni la preuve d’une requête API exécutable.

Cette ancienne représentation comporte aussi des contradictions entre l’exemple et les lignes de paramètres :

• Dans l’exemple, AliasLocalWANPort suit un commentaire concernant un port WAN alias, mais la table le présente comme un ARRAY obligatoire. Name et RemoteHost sont également des ARRAY ; cela ne définit ni une sérialisation sûre de plusieurs valeurs ni leur association par paires.
• L’exemple de UserAuthenticationMode montre AsServer/AsClient, alors que la ligne indique EnableAsServer/EnableAsClient. Pour DisconnectOnIdleInterval, la valeur par défaut 0 est hors de la plage indiquée 120..21600 ; 600 n’est que la valeur de l’exemple. Ne réconciliez pas silencieusement ces différences et n’en faites pas des valeurs par défaut d’IKEv2.
• L’ancien champ AllowNATTraversal avec Enable/Disable ne prouve pas l’existence d’un commutateur NAT-T actuel. La ligne de RemoteHost interdit * avec RSAKey ; il s’agit d’une restriction de cette référence, pas d’une règle générale de fonctionnement de la GUI confirmée ici.

Tant que la représentation API du build installé n’est pas clarifiée, utilisez la procédure WebAdmin ci-dessus et levez les ambiguïtés avant de l’automatiser. Cette note n’est pas un modèle XML testé ; la détection automatique de NAT-T et les indications relatives à IKEv2, RSA et aux IDs restent inchangées pour la procédure GUI décrite.

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. Les procédures SFOS 22 et SFOS 23 décrivent également la création d’une interface XFRM avec des Traffic Selectors spécifiques ; contrairement à Any-to-Any, elle ne doit recevoir ni adresse IP ni route attribuée manuellement. Avant une migration, documentez la version SFOS installée, l’association de l’interface et la route réellement créée.

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éterminent 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 certaines architectures de failover, une Custom Gateway avec l’adresse IP XFRM du pair est créée en complément et utilisée dans une SD-WAN Route.

Pour l’alternative SD-WAN, sélectionnez IPv4, puis Add sous Routing > SD-WAN routes. Au siège, définissez Source networks = HQ_LAN, Destination networks = Branch_LAN, puis Primary and backup gateways sous Link selection settings. Sous Primary gateway > Add, renseignez 10.255.0.2 comme Gateway IP et choisissez comme Interface l’interface XFRM locale portant 10.255.0.1/30. Dans la filiale, inversez Source/Destination, utilisez la Gateway IP 10.255.0.1 et l’interface XFRM locale portant 10.255.0.2/30. Pour Health check, choisissez sous Monitoring condition un hôte interne du pair qui répond effectivement, par exemple 10.20.20.15 dans la filiale ou 10.10.10.25 au siège. La sonde doit elle-même être autorisée et emprunter le tunnel prévu. Pour une sélection fondée sur les SLA, sélectionnez un profil SD-WAN avec les gateways des tunnels. La route statique et la route SD-WAN sont ici des alternatives ; ne les créez pas toutes deux comme chemins concurrents sans vérification. Documentez la Route Precedence et les règles existantes avant la modification et, en cas de retour arrière, restaurez la sélection précédente de route et de gateway.

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

Pour des sous-réseaux spécifiques, les procédures SFOS 22 et SFOS 23 consultées décrivent une interface XFRM par configuration IPsec. Sous Network > Interfaces, développez la Listening interface à l’aide du repère bleu. N’attribuez ni adresse IP ni route manuelle à l’interface créée : la route statique est créée automatiquement dès que le tunnel est established. Au siège, sélectionnez Local HQ_LAN et Remote Branch_LAN ; dans la filiale, Local Branch_LAN et Remote HQ_LAN. La gateway, le profil, l’authentification et les IDs sont configurés en miroir, comme pour les autres variantes. Avec route-based, Any d’un seul côté et un Selector spécifique de l’autre ne sont pas pris en charge. Si l’interface documentée est absente du build installé, commencez par vérifier la configuration, la version et les logs ; n’essayez pas de forcer la création d’une interface XFRM de remplacement ou un adressage Any-to-Any.

Cette variante convient aux petits réseaux clairement définis ; Sophos la recommande de préférence à policy-based, y compris pour les connexions avec des équipements tiers compatibles. Utilisez l’interface XFRM sous Diagnostics > Packet capture pour identifier le trafic sortant ; vérifiez également la route automatique, chaque Child SA attendue, les logs et le trafic dans les deux sens. WAF via IPsec route-based avec Traffic Selectors n’est pas pris en charge ; une configuration route-based Any-to-Any adaptée peut être envisagée à cette fin. Si la migration échoue, désactivez la nouvelle connexion et uniquement ses nouvelles règles, puis réactivez la connexion précédente documentée.

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 générées se trouvent dans le groupe Automatic VPN rules. Dans l’exemple, le siège autorise en sortie Source zone LAN, Source network HQ_LAN, Destination zone VPN, Destination network Branch_LAN ; en entrée, les zones et les réseaux sont inversés. Dans la filiale, appliquez la même configuration en miroir, avec Branch_LAN comme réseau local. Limitez chaque champ Services aux ports applicatifs autorisés et activez Log firewall traffic. Il est possible d’ajouter les réseaux Source/Destination appropriés à des règles existantes adaptées, plutôt que de créer de nouvelles règles pour chaque tunnel. Vérifiez au préalable l’incidence sur toutes les autres connexions couvertes par la règle concernée. SFOS évalue les règles de haut en bas et s’arrête à la première correspondance ; une nouvelle règle en tête de liste peut donc prendre le pas sur des restrictions existantes.

⚠️ 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.

Pour le NAT au sein de la connexion IPsec, activez Network Address Translation (NAT). Translated subnet affiche le réseau local traduit sélectionné dans la connexion ; sous Original subnet, sélectionnez le réseau local réel qui se chevauche. Pour les réseaux sans traduction, conservez Not translated. Avant l’enregistrement, comparez dans un tableau le réseau original, le réseau traduit, le Remote Selector du pair et l’adresse de destination DNS. Ne déduisez pas le sens de la traduction des seuls noms des champs ; la procédure NAT liée contient l’exemple complet. Pour Any-to-Any, n’utilisez pas ces champs à la place de règles SNAT/DNAT distinctes.

⚠️ Avec IPsec route-based et Traffic Selectors, utilisez le NAT de la connexion IPsec et n’attribuez ni adresse IP ni route manuelle à l’interface XFRM créée. 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 pas une étape standard, mais peut être pertinente pour certains scénarios de trafic transféré. Pour les requêtes d’authentification générées par le système, les textes d’aide Sophos relatifs à SFOS 22 et SFOS 23 se contredisent : la présentation du routage et du NAT indique que ce trafic ne nécessite pas cette commande ; la procédure d’authentification décrit en revanche une exception policy-based lorsque la Route Precedence choisie n’envoie pas le trafic dans le tunnel. Cela ne justifie ni l’ajout d’une route pour tout trafic système ni une modification systématique de la Route Precedence globale.

Avant toute modification, l’adresse source, sys-traffic-nat, les Traffic Selectors et le chemin de retour doivent correspondre au flux de paquets réellement observé. La procédure existante relative aux routes IPsec et celle consacrée aux requêtes d’authentification générées par le système expliquent les vérifications ciblées à effectuer avec une requête réelle et Packet Capture, ainsi que les retours arrière distincts pour le NAT et la route. Si le comportement reste incertain sur le build installé, il doit être clarifié avec Sophos Support avant toute modification en production. Confirmer le fonctionnement de cette exception sur la version SFOS utilisée. 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.

Si un pair doit envoyer un ping au pare-feu lui-même à travers le tunnel, autorisez la zone VPN sous Ping/Ping6, puis sélectionnez Apply. Ce n’est pas une étape globale nécessaire pour envoyer un ping à un hôte LAN : dans ce cas, ce sont les règles de transit appropriées et le pare-feu de l’hôte qui comptent. N’activez que l’autorisation de service local nécessaire au test, documentez son réglage initial et restaurez-le après le test si cette autorisation n’est pas requise en permanence. Un ping depuis le shell du pare-feu utilise par ailleurs une adresse source différente de celle d’un client LAN ; ne considérez pas ces deux tests comme des vérifications équivalentes de la règle applicable au client.

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, seules les connexions réellement établies sont affichées. Les filtres disponibles sont Connection name, Local server name, Local subnet, Username, Remote server/host et Remote subnet ; Refresh actualise la vue. Disconnect interrompt une SA existante de manière contrôlée, par exemple lorsque les deux côtés sont prêts pour une modification de configuration ; cette action ne remplace pas la désactivation de la connexion 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.

Pour l’exemple utilisé tout au long de cette procédure, testez depuis le client LAN 10.10.10.25 un hôte réellement présent dans la filiale, 10.20.20.15, et non l’adresse réseau 10.20.20.0. Sous Windows, ping 10.20.20.15 -t lance un test continu ; arrêtez-le avec Ctrl+C. Sous Diagnostics > Packet capture > Configure, définissez BPF string sur host 10.10.10.25 and host 10.20.20.15 and proto ICMP, enregistrez et activez la capture. Avec route-based, vérifiez la sortie sur l’interface XFRM associée ainsi que les paquets de retour. Dans Log viewer, recherchez l’adresse réelle du client ; utilisez la Firewall rule ID et Filter firewall rule pour ouvrir la règle correspondante. Testez ensuite également un port applicatif prévu et le sens inverse. Désactivez la capture et retirez les filtres et autorisations temporaires ; une capture permanente ne constitue pas un monitoring d’exploitation. Si un routeur se trouve en amont, vérifiez également dans les logs des deux pairs que le NAT a été détecté et que NAT-T a été négocié.

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 l’interface XFRM documentée sous la Listening interface, la route automatique, chaque Child SA attendue, les Selectors, les règles de la zone VPN et une éventuelle règle MASQ. Utilisez l’interface XFRM pour Packet Capture, mais ne lui attribuez ni adresse IP ni route manuelle. Si elle est absente, vérifiez le build et la configuration au lieu de créer une interface de remplacement.
• 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 l’interface XFRM générée ; 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.

Supprimer une connexion enregistrée précise

Supprimer une connexion IPsec enregistrée est différent de Disconnect, de sa désactivation ou de la suppression d’un groupe de failover. Avant une suppression autorisée séparément, relevez le Name existant exact, Object Usage, les appartenances aux groupes et un accès d’administration indépendant du tunnel. Ne supprimez pas une connexion tant qu’elle appartient à un groupe de failover ; la procédure de failover liée explique le retrait contrôlé de cette affectation.

La référence de suppression de l’API XML pour SFOS 22 et SFOS 23 définit Name comme un ARRAY obligatoire de type STRING : premier caractère A-Za-z, suivants A-Za-z0-9_, au maximum 100 caractères, plusieurs valeurs autorisées. Elle ne contient toutefois aucun exemple de requête. N’en déduisez ni un sérialiseur pour plusieurs noms ni un nom cible à partir de l’exemple GUI branch-zurich ; ne réécrivez pas un nom enregistré pour le rendre apparemment conforme.

La référence associe le statut d’opération XML 200 à Message.IPSecDeleteSuccess, 201 à Message.IPSecConnInUse et 500 à Message.IPSecDeleteFail. Les textes des messages sont insérés par JavaScript et ne sont pas résolus ici : il ne s’agit ni de codes HTTP ni de textes de réponse affichés confirmés. Ne comptez pas 201 comme une suppression réussie au seul motif que le nombre commence par 2 ; pour Edit, le même nombre correspond à Message.IPSecUpdated. Après une suppression autorisée, relisez exactement cette cible et vérifiez les chemins de production restants. Si le résultat est incertain, clarifiez l’état de la cible et les dépendances avant toute nouvelle tentative, sans répéter aveuglément.

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é réelle de l’interface XFRM est documentée ; indépendamment de son affichage, aucune adresse IP XFRM ni route manuelle n’est prévue.
• 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