Rendre l'IPsec Route-based redondant avec deux accès Internet

Un deuxième accès Internet ne rend pas automatiquement un tunnel IPsec redondant. Un failover fiable exige une connexion Route-based distincte pour chaque accès, une interface XFRM dotée de sa propre adresse et un chemin de routage supervisé. Sophos Firewall peut alors basculer délibérément le trafic d’ISP1 vers ISP2 et revenir au chemin préféré après son rétablissement.

Cette procédure traite l’IPsec Route-based Any-to-Any entre deux Sophos Firewall sous SFOS 22.0. Elle suit le design à deux accès Internet décrit par Sophos. Les tunnels Policy-based et les tunnels Route-based avec des Traffic Selectors précis utilisent à la place un IPsec Failover Group.

⚠️ L’aide Sophos actuelle se contredit sur deux connexions Any-to-Any. Le guide dédié aux deux ISP crée deux tunnels de ce type sans Failover Group. Les instructions générales de dépannage IPsec indiquent au contraire que plusieurs connexions ayant les mêmes Local et Remote Subnets, y compris Any-Any, ne fonctionnent que dans le même Failover Group. Comme ce groupe modifie DPD et le Failback, cette procédure n’invente pas cette étape : valider le design sur le Maintenance Release SFOS 22 installé et soumettre tout comportement différent à Sophos Support avant la production.

Procédure rapide

1. Valider séparément sur les deux firewalls un tunnel Any-to-Any via ISP1 et un autre via ISP2.
2. Attribuer une adresse de transfert unique à chacune des quatre interfaces XFRM.
3. Créer sur chaque firewall une Custom Gateway avec un Health Check choisi consciemment pour les deux adresses XFRM du pair.
4. Ajouter deux routes statiques vers le même LAN distant : Primary avec une Administrative Distance plus faible et Backup avec une valeur plus élevée.
5. Consigner la Route Precedence globale et ne la définir sur static vpn sdwan_policyroute que si elle convient au design complet.
6. Vérifier les règles de pare-feu et les chemins de retour pour les deux chemins XFRM.
7. Interrompre ISP1 de manière contrôlée, tester du trafic applicatif réel via ISP2, puis valider le Failback vers ISP1.

⚠️ Route Precedence s’applique à l’ensemble du firewall. Une modification peut également affecter les chemins Static, VPN et SD-WAN existants. Consigner d’abord la valeur actuelle et toutes les routes qui se chevauchent, créer un backup de configuration et vérifier un accès d’administration indépendant.

Conception et prérequis

Comprendre le modèle de failover

Les deux connexions IPsec restent des tunnels indépendants. La route dont l’Administrative Distance est la plus faible constitue le chemin de données préféré. Si sa gateway XFRM supervisée est considérée comme inaccessible, la route via le second tunnel peut prendre le relais.

Il s’agit de deux états distincts :

• Le tunnel est actif : IKE et la Child SA sont établis.
• Le chemin est utilisable : la gateway, la route, la règle de pare-feu, le comportement NAT attendu, le pair et le chemin de retour fonctionnent pour le trafic réel.

Un tunnel vert ne prouve donc pas à lui seul le failover. Un simple failover WAN ne suffit pas non plus : WAN link manager ne crée ni une seconde connexion IPsec ni une route correspondante sur le pair.

Any-to-Any n’utilise pas de VPN Failover Group supplémentaire. Les interfaces XFRM adressées, les gateways et les routes sélectionnent le chemin. Configurer un VPN IPsec Site-to-Site explique la configuration de base complète d’un tel tunnel.

SFOS 22 autorise des routes statiques, SD-WAN ou dynamiques pour les interfaces XFRM Any-to-Any. La procédure dédiée aux deux ISP utilise expressément deux routes statiques. Cette procédure suit ce design ; ne pas ajouter de route SD-WAN vers la même destination sans concevoir et tester séparément son interaction et sa priorité.

Planifier la topologie d’exemple

L’exemple relie un siège à une filiale :

• Siège : 172.16.16.0/24
• Filiale : 192.168.10.0/24
• Primary : ISP1
• Backup : ISP2
• Réseau XFRM ISP1 : 10.255.1.0/30
• Réseau XFRM ISP2 : 10.255.2.0/30

Head office 172.16.16.0/24                 Branch office 192.168.10.0/24

       xfrm-ISP1 10.255.1.1  ⇄  10.255.1.2 xfrm-ISP1     AD 1
Firewall HQ                                                   Firewall BO
       xfrm-ISP2 10.255.2.1  ⇄  10.255.2.2 xfrm-ISP2     AD 2

Ces adresses sont des valeurs de documentation à remplacer par des réseaux de transfert dédiés et sans chevauchement. Chaque paire XFRM a besoin d’un réseau distinct. Pour chaque tunnel, les adresses publiques des ISP, les Local et Remote IDs, les Profiles et les Listening Interfaces doivent correspondre à la configuration du pair.

Configurer les tunnels, les gateways et les routes

Préparer deux tunnels

Créer deux connexions sous Site-to-site VPN > IPsec sur chaque firewall. Toutes deux utilisent Route-based (Tunnel interface) et Any pour Local subnet et Remote subnet. Dans un design classique entre siège et filiale, le siège utilise Respond only et la filiale Initiate the connection.

Le premier tunnel utilise l’interface WAN d’ISP1 et le second celle d’ISP2. Tester les deux connexions séparément avant de configurer le failover. À chaque test, n’activer que le tunnel prévu et vérifier un flux de données défini dans les deux directions.

Sur les deux firewalls, sous Network > Interfaces, développer l’interface WAN utilisée pour la connexion IPsec concernée. Les interfaces XFRM créées automatiquement apparaissent en dessous comme interfaces enfants. Cela permet d’associer chaque interface XFRM au tunnel via ISP1 ou ISP2 avant de lui attribuer son adresse de transfert.

Sous Network > Interfaces, attribuer les adresses d’exemple suivantes aux interfaces XFRM créées automatiquement :

• Siège : 10.255.1.1/30 pour ISP1 et 10.255.2.1/30 pour ISP2
• Filiale : 10.255.1.2/30 pour ISP1 et 10.255.2.2/30 pour ISP2

Ne pas modifier l’adressage d’une interface XFRM tant que d’autres routes ou services en dépendent. Vérifier Object usage, l’état du tunnel et les objets de routage existants avant chaque modification.

Superviser les gateways XFRM

Sous Routing > Gateways, créer de chaque côté une gateway par tunnel vers l’adresse XFRM du pair. Au siège, il s’agit de 10.255.1.2 et 10.255.2.2 ; dans la filiale, de 10.255.1.1 et 10.255.2.1.

Pour chaque gateway, renseigner au minimum Name, Gateway IP et Interface. Gateway IP est l’adresse XFRM du pair et Interface la XFRM correspondante. Health check est désactivé par défaut et doit être activé pour superviser le chemin. SFOS 22 affiche alors Interval (60 secondes par défaut), Time-out (2 secondes), Retries (3) et au moins une Monitoring condition avec Protocol, Port pour TCP et IP address.

L’IP de test doit être un hôte derrière la gateway. Pour évaluer tout le chemin en aval, choisir un endpoint stable et autorisé derrière le pair. Un ping vers la seule adresse XFRM du pair ne prouve que le segment immédiat. Plusieurs conditions peuvent être liées par AND ou OR : AND exige toutes les réponses, tandis que OR teste de haut en bas jusqu’à la première réponse.

Le choix du protocole, de la cible et des intervalles est une décision d’exploitation : la cible doit répondre de manière stable, rester disponible pendant la maintenance normale et disposer de l’autorisation requise. Les valeurs par défaut sont un point de départ, pas un délai de bascule garanti. N’accepter la modification qu’après avoir mesuré les temps de détection, de Failover et de Failback. Créer et vérifier une Custom Gateway explique en détail le Health Check, l’état et les conditions d’arrêt.

Ajouter les routes statiques Primary et Backup

Au siège, ajouter sous Routing > Static routes deux routes IPv4 Unicast vers le réseau de la filiale 192.168.10.0/24 :

• via 10.255.1.2 et le XFRM ISP1 avec une Administrative distance de 1
• via 10.255.2.2 et le XFRM ISP2 avec une Administrative distance de 2

Dans la filiale, créer en miroir deux routes vers le réseau du siège 172.16.16.0/24 :

• via 10.255.1.1 et le XFRM ISP1 avec une Administrative distance de 1
• via 10.255.2.1 et le XFRM ISP2 avec une Administrative distance de 2

L’Administrative Distance la plus faible l’emporte tant que sa gateway est disponible. Des réseaux de destination identiques et des distances différentes forment donc les chemins Primary et Backup. Ce comportement diffère de l’ECMP avec des priorités identiques. Configurer et tester une route statique explique la logique générale de route et de retour.

Le guide Sophos dédié attribue à ce design le Failover et le Failback automatiques. La référence générale des routes statiques confirme la priorité par Administrative Distance, sans décrire séparément comment l’échec du Health Check d’une Custom Gateway retire la route de la sélection. Le test de validation doit donc observer la route active, et pas seulement l’état de la gateway.

Définir Route Precedence avec précaution

Sophos documente ce design avec Static avant VPN et SD-WAN. Consigner d’abord l’état existant dans la Device Console :

system route_precedence show

Uniquement si cet ordre convient à l’ensemble du design de routage, le définir sur les deux firewalls :

system route_precedence set static vpn sdwan_policyroute

Vérifier ensuite à nouveau la valeur avec system route_precedence show. Cette modification n’est pas une correction générale d’IPsec. Elle affecte aussi les autres routes Static, VPN et SD-WAN qui se chevauchent. Modifier Route Precedence en toute sécurité explique l’effet global et le rollback.

L’aide SFOS 22 donne comme valeur par défaut générale static, sdwan_policyroute, vpn, tandis que le guide dédié exige static vpn sdwan_policyroute pour ce design. Le rollback doit donc rétablir exactement l’ordre consigné auparavant avec show, et non appliquer aveuglément le défaut.

Aligner les règles, le NAT et le chemin de retour

Les deux firewalls ont besoin de règles appropriées entre LAN et VPN. Limiter les sources, destinations et services aux réseaux et applications réels des sites ; laisser Log firewall traffic activé pendant la mise en service.

Le trafic intersite normalement routé ne nécessite généralement pas de SNAT. S’il existe déjà des exemptions NAT ou des traductions ciblées, elles doivent se comporter de la même façon sur les deux chemins. Ne pas ajouter une règle MASQ large comme raccourci de failover.

Cette situation diffère de NAT Traversal. Sophos Firewall active automatiquement NAT-T et utilise UDP 4500 lorsqu’un NAT est détecté ; sans NAT, IKE utilise UDP 500 et ESP le protocole IP 50. Si une firewall se trouve derrière un routeur amont, le DNAT et les autorisations de ce routeur doivent atteindre la Listening Interface correspondante sur les deux chemins ISP. Des réseaux de sites qui se chevauchent exigent en revanche des règles SNAT et DNAT adaptées au trafic utile.

La route sur le pair est aussi importante que le chemin aller. Un tunnel peut être actif alors que la réponse revient par le mauvais ISP ou par une route plus générale. Évaluer ensemble Route Lookup, la route active, Firewall Rule ID, NAT Rule ID et Packet Capture.

Valider et exploiter le failover

Valider le Failover et le Failback

Avant le test de panne, valider séparément les deux tunnels avec le même flux applicatif. Garder visible une connexion de test continue et établir également de nouvelles sessions pendant le test.

Pendant la fenêtre de maintenance, interrompre uniquement le chemin ISP1 de manière contrôlée. Ne pas désactiver simultanément les deux ports WAN ou les deux tunnels. La validation répond à quatre questions :

1. La gateway ISP1 est-elle détectée comme indisponible ?
2. La route avec une Administrative Distance de 2 via le XFRM ISP2 devient-elle active ?
3. Les nouvelles connexions atteignent-elles le pair et les réponses reviennent-elles via ISP2 ?
4. Après le rétablissement d’ISP1, la route avec une Administrative Distance de 1 est-elle à nouveau utilisée ?

Dans Log Viewer et un Packet Capture ciblé, la Firewall Rule ID attendue, l’interface XFRM active et le flux bidirectionnel doivent correspondre. Un ping seul ne suffit pas. HTTPS, RDP, VoIP ou une autre application réelle montrent également si l’établissement de session, le MTU et le chemin de retour fonctionnent. Tester une règle de pare-feu avec Log Viewer et Packet Capture explique la procédure combinée.

Dans un cluster HA, tester une nouvelle connexion via les deux chemins ISP après un Failover planifié. SFOS 22 restaure les tunnels IPsec Route-based de manière transparente, mais limite la reprise des sessions du trafic dans le tunnel aux protocoles sans état comme UDP et ICMP ; TCP n’est pas pris en charge. Évaluer séparément une connexion TCP existante et une nouvelle. Les logs et rapports HA restent sur le seul nœud qui a traité le trafic : contrôler les deux appareils.

Délimiter les erreurs systématiquement

Les deux tunnels sont verts, mais ISP2 ne prend pas le relais

Vérifier l’état des gateways, le Monitoring Target et les deux routes statiques. Le réseau de destination et le préfixe doivent être identiques, tandis que les Next Hops et les interfaces XFRM doivent différer. Comparer ensuite l’Administrative Distance et la Route Precedence actuelle.

ISP2 prend le relais, mais les applications ne répondent pas

Vérifier les règles de pare-feu, les exemptions NAT et la route de retour des deux côtés. Packet Capture doit montrer la requête et la réponse sur le XFRM ISP2. Si seule la réponse manque, le défaut se trouve généralement derrière le pair ou dans un chemin de retour asymétrique.

Le Failback intervient trop tôt ou pas du tout

Observer le Health Check et le Monitoring Target. La cible ne doit pas signaler par intermittence un tunnel sain alors que le chemin applicatif reste perturbé. Vérifier ensemble l’Administrative Distance, la route active et une session réellement nouvelle ; les connexions existantes peuvent rester liées à leur état précédent.

Une seule direction fonctionne

Comparer la configuration en miroir : adresse XFRM, gateway, route statique, règle et chemin de retour doivent exister sur les deux firewalls. Le dépannage Sophos actuel cite /log/strongswan.log, /log/charon.log, /log/strongswan-monitor.log et /log/dgd.log ; le dernier contient les événements Dead Gateway Detection et VPN Failover. Dans l’Advanced Shell, la commande en lecture seule ip xfrm state indique si des Transform States existent. Dépannage d’un VPN IPsec explique le diagnostic sûr.

Les états du tunnel et de la gateway se contredisent

DPD et le Gateway Health Check ne mesurent pas la même chose. Dead Peer Detection se configure sous Profiles > IPsec profiles et détecte un pair IKE muet après l’inactivité du tunnel Phase 2 ; Sophos recommande d’activer DPD. Le Health Check de la Custom Gateway teste l’hôte choisi derrière le chemin XFRM. Ne pas désactiver DPD pour masquer une cible de test défaillante. Si Sophos Support exige un Failover Group en raison du conflit documentaire ci-dessus, noter que son ajout désactive DPD dans le profil associé, définit Key negotiation tries sur 3 et introduit un Automatic failback distinct avec cinq tentatives au maximum. Il s’agit d’un autre modèle d’exploitation, à ne pas mélanger à cette procédure sans validation séparée.

Effectuer un rollback sûr

Avant la modification, documenter le backup, la Route Precedence d’origine, l’état des tunnels, les adresses XFRM, les gateways, les règles et les routes. Si le chemin redondant n’est pas fiable :

1. Désactiver les nouvelles routes Backup.
2. Désactiver les gateways ISP2 et le second tunnel au lieu de les supprimer immédiatement.
3. Rétablir la Route Precedence d’origine sur les deux firewalls.
4. Rétablir les règles et le NAT dans l’état antérieur documenté.
5. Tester à nouveau le chemin ISP1 d’origine avec une nouvelle session applicative.

Ne supprimer les adresses XFRM, gateways ou tunnels que lorsque Object usage n’indique plus aucune dépendance. Backup et restauration de Sophos Firewall explique le processus de sauvegarde et de récupération.

FAQ