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. Les tunnels Policy-based et les tunnels Route-based avec des Traffic Selectors précis utilisent à la place un IPsec Failover Group.

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 gateway supervisée 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.

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.

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.

Sélectionner l’interface XFRM correspondante comme Interface. Si l’ensemble du chemin en aval doit être évalué, le Monitoring Target doit être un endpoint stable et autorisé derrière le pair. Un ping vers la seule adresse XFRM du pair prouve uniquement le segment immédiat du tunnel.

Le choix de la cible est une décision d’exploitation : elle doit répondre de manière stable, ne pas disparaître lors d’une maintenance normale et disposer de l’autorisation appropriée. 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.

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.

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.

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é. Un tunnel actif ne garantit pas que les sessions TCP existantes ou les états de routage se poursuivent sans interruption.

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. strongswan.log et xfrmi.log aident à analyser les couches IKE et XFRM ; Dépannage d’un VPN IPsec explique le diagnostic sûr.

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