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 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. Les versions SFOS actuelles séparent ces termes plus clairement que les anciens guides, qui parlent encore parfois de Site-to-Site ou de Tunnel Interface.

• IPsec policy-based : convient aux liaisons de sites simples avec des réseaux locaux et distants clairement définis. Il est contrôlé principalement par les sous-réseaux locaux et distants de la connexion IPsec et par les règles de pare-feu. Sophos crée des tunnels Phase 2 distincts pour les combinaisons de sous-réseaux locaux et distants.
• IPsec route-based avec Traffic Selectors : utilise également des sous-réseaux locaux et distants, mais crée une interface XFRM dédiée. Sophos crée la route automatiquement ; aucune adresse IP ni route propre ne doit être attribuée à l’interface XFRM. WAF n’est pas pris en charge avec cette variante.
• IPsec route-based Any-to-Any : est l’option la plus flexible pour les réseaux en croissance, le SD-WAN, le routage dynamique et les designs dual-stack. Les routes et les règles de pare-feu, et non les sous-réseaux de la connexion IPsec, décident alors quels paquets entrent dans le tunnel.

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.

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.

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

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.

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 la CA révoque des certificats avant leur expiration, la liste de révocation actuelle doit aussi faire partie du plan d’exploitation. La procédure distincte décrit l’importation de la CRL, 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 IPsec_IKEv2_AES256_G14. 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.

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.

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 et le chemin des données grâce à une interface XFRM dédiée. L’adressage et le routage manuel de cette interface dépendent de la variante choisie.

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

Sophos affiche l’interface XFRM générée sous l’interface physique utilisée dans :

Network > Interfaces

L’interface XFRM reste toujours affectée à la zone VPN. Les deux variantes se configurent différemment.

Any-to-Any et Dual

Lorsque les deux sous-réseaux sont définis sur Any, ou lorsque Dual est utilisé, l’interface XFRM reçoit une adresse IP de transfert. Elle nécessite ensuite une route statique, une SD-WAN Route ou une route dynamique via BGP ou OSPF. Avec Dual, des règles de pare-feu IPv4 et IPv6 distinctes sont requises.

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érifier trois points :

1. L’interface XFRM est visible sous Network > Interfaces et possède l’adresse IP de transfert prévue.
2. La route vers le réseau distant pointe directement vers l’interface XFRM ou, dans un design Gateway/SD-WAN, vers la XFRM Gateway appropriée.
3. Les règles de pare-feu autorisent uniquement les directions et les services prévus.

Traffic Selectors

Avec des Local et Remote subnets spécifiques, Sophos crée également une interface XFRM, mais aucune adresse IP ni route propre ne doit lui être attribuée. La route statique est créée automatiquement dès que le tunnel est 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 et simplifie le diagnostic XFRM. Cependant, WAF sur un 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.

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

NAT n’est pas interdit avec IPsec, mais il doit avoir une raison claire. Les cas typiques sont les réseaux qui se chevauchent, les exigences cloud ou les tiers qui n’acceptent que certaines adresses source.

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 un IPsec route-based utilisant des Traffic Selectors, l’interface XFRM ne possède pas d’adresse IP. Si ce trafic correspond à une règle MASQ SNAT, le pare-feu rejette les paquets. Pour les réseaux qui se chevauchent, utiliser le paramètre NAT de la connexion IPsec et vérifier qu’aucune règle MASQ SNAT ne correspond à ce trafic.

Depuis SFOS 22, le policy-based IPsec crée la route VPN dans le backend. Une ipsec_route manuelle n’est pertinente que pour certains trafics traduits et transférés et ne constitue pas une étape standard ; le trafic généré par le système n’en a pas besoin. Les principes de base du NAT sont décrits dans Comprendre les règles NAT 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.

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 : ne pas configurer d’adresse IP ni de route manuelle sur l’interface XFRM. Vérifier 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.

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, aucune adresse IP ni route manuelle n’est prévue sur l’interface XFRM.
• 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.
• Une matrice de recette avec au moins un test par direction requise est définie.
• 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