Configurer et tester le basculement WAN sur Sophos Firewall

Une seconde liaison Internet ne devient pas automatiquement une liaison de secours sur Sophos Firewall. Une passerelle WAN nouvellement créée est Active par défaut et participe donc au load balancing. Pour une architecture classique Primary/Backup, il faut passer la seconde passerelle sur Backup dans WAN link manager.

La procédure rapide pour une liaison principale et une liaison de secours est la suivante :

Configurer entièrement les deux interfaces WAN sous Network > Interfaces et les tester séparément.
Sous Network > WAN link manager, définir la passerelle principale comme Active et la passerelle de secours comme Backup.
Pour la passerelle de secours, sélectionner Activate this gateway: If active gateway fails: ANY.
Configurer des Failover rules fiables pour les deux passerelles.
Tester le failover et le failback, c’est-à-dire le retour à la liaison principale, avec du trafic DNS, HTTPS et applicatif réel.

Ce basculement Internet simple par défaut ne nécessite pas de route SD-WAN dédiée. SD-WAN devient nécessaire lorsque certains flux doivent emprunter des chemins précis ou lorsque la sélection du chemin doit dépendre de la latence, du jitter et de la perte de paquets.

Bien distinguer Active, Backup et load balancing

Le type de passerelle détermine si une liaison participe normalement au trafic Internet :

Active : Si plusieurs passerelles actives sont disponibles, le pare-feu répartit les nouvelles sessions selon les poids configurés.
Backup : La passerelle ne prend le relais que lorsque sa condition d’activation est remplie.

Au moins une passerelle WAN doit rester Active. Si toutes les passerelles sont uniquement définies comme Backup, le chemin WAN par défaut n’existe plus ; le trafic généré par le pare-feu lui-même, en particulier, ne peut alors plus être transféré.

Le Weight ne décrit pas la bande passante. En mode weighted round-robin, un rapport de 2 à 1 signifie que le pare-feu attribue deux nouvelles sessions à la première passerelle, puis la suivante à la seconde. Un téléchargement unique n’est donc pas réparti sur les deux liaisons et le volume de données transmis peut s’écarter nettement de ce rapport.

Sophos Firewall utilise Session Persistence par défaut. Cela ne maintient pas seulement une connexion existante sur la même liaison WAN : selon le facteur de persistance, d’autres sessions provenant de la même adresse IP source peuvent également être réaffectées à cette liaison. Après s’être connecté à Option 4: Device Console, la commande en lecture seule suivante indique la méthode actuelle :

show routing wan-load-balancing

Cette commande ne modifie rien. Elle indique si Session Persistence ou weighted round-robin est actif et aide ainsi à comprendre une répartition inattendue des chemins. Pour une architecture exclusivement Active/Backup, la méthode est généralement secondaire, puisqu’un seul chemin prévu est disponible aussi bien en fonctionnement normal qu’en cas de panne.

Le basculement WAN n’est pas identique à un basculement HA. WAN link manager change le chemin Internet sur le même pare-feu. Un cluster HA Sophos Firewall prend en revanche le relais lorsqu’un appareil ou un port surveillé tombe en panne.

Préparer le basculement WAN

Les deux accès opérateur doivent d’abord fonctionner indépendamment. Les principes concernant la zone WAN, l’attribution IP et la passerelle sont expliqués dans Planifier les zones et interfaces Sophos Firewall.

Une configuration simple peut se présenter ainsi :

WAN1 Fiber : liaison principale, passerelle gw-fiber, Type: Active, Weight: 1
WAN2 DSL : liaison de secours, passerelle gw-dsl, Type: Backup
Activation de la liaison de secours : If active gateway fails: ANY
Action lors de l’activation : Inherit weight of the failed active gateway
Action lors du retour : Serve new connections through restored gateway

Les noms sont libres et doivent décrire clairement chaque accès. Le type de passerelle et les actions sont en revanche des paramètres fonctionnels. Avant le basculement, la passerelle de secours doit déjà afficher un état vert et le trafic réel d’un client doit avoir été testé avec succès sur cette liaison.

Il faut également prévoir un chemin de retour sûr pour l’administration. Si le pare-feu est modifié à distance, WebAdmin ne doit pas être accessible uniquement par la liaison qui sera déconnectée pendant le test. Une sauvegarde de configuration récente, une fenêtre de maintenance et une personne sur place ou un chemin d’administration indépendant évitent qu’un simple test de failover ne se transforme en panne prolongée.

Il faut aussi recenser au préalable tous les services liés à une adresse IP publique. Cela inclut les publications DNAT, les pairs IPsec, Remote Access, les listes d’autorisation des fournisseurs, les serveurs de messagerie et les systèmes de supervision externes. L’accès Internet sortant peut déjà fonctionner alors que ces services ne sont pas encore joignables ou autorisés via la nouvelle adresse publique.

Configurer Primary/Backup

Vérifier les interfaces WAN et l’état des passerelles

Sous Network > Interfaces, configurer les deux ports WAN avec les paramètres statiques, DHCP ou PPPoE fournis par l’opérateur. Lors de l’enregistrement, la passerelle WAN physique correspondante est automatiquement créée dans WAN link manager.

Une nouvelle passerelle est d’abord Active. Après l’ajout d’une liaison destinée exclusivement au secours, il faut donc modifier immédiatement son type afin d’éviter que du trafic de production ne soit involontairement réparti entre les deux opérateurs.

Les Custom Gateways créées sous Routing > Gateways, par exemple pour XFRM, RED ou MPLS, n’apparaissent pas dans WAN link manager. Elles relèvent d’une autre architecture de routage et ne sont pas traitées comme des passerelles ISP physiques dans ce scénario simple.

Configurer la passerelle de secours

Sous Network > WAN link manager, modifier la passerelle de la liaison de secours et définir les valeurs suivantes :

Type: Backup
Activate this gateway: If active gateway fails
Avec une seule liaison principale : ANY
Action on activation: Inherit weight of the failed active gateway
Action on failback: Serve new connections through restored gateway
Enregistrer, puis vérifier l’état de la passerelle.

Avec une seule passerelle active, ANY et ALL ont pratiquement le même effet. La différence devient importante avec plusieurs liaisons actives :

ANY : La passerelle de secours est activée dès qu’une passerelle active tombe en panne. Ce choix convient lorsqu’il faut remplacer immédiatement la capacité perdue.
ALL : La passerelle de secours n’est activée que lorsque toutes les passerelles actives sont défaillantes. Ce choix convient davantage à une liaison d’urgence lente ou coûteuse.

Action on activation détermine le poids de la passerelle de secours lorsqu’elle devient active en parallèle d’autres passerelles disponibles. Inherit weight of the failed active gateway est un choix logique pour un remplacement simple. Use configured weight convient lorsque la liaison de secours a volontairement une capacité inférieure ou supérieure et fonctionne avec les autres liaisons actives restantes.

Pour le failback, Serve new connections through restored gateway constitue le choix opérationnel le moins perturbateur. Les nouvelles sessions utilisent de nouveau la liaison principale, tandis que les sessions existantes restent sur le chemin de secours jusqu’à leur timeout ou leur interruption. Serve all connections through restored gateway rétablit les connexions existantes et peut les interrompre. Pour les routes SD-WAN, cette action ne s’applique que si WAN link load balance est sélectionné comme Primary Gateway. Lorsqu’une seule liaison WAN active est définie comme Primary, seules les nouvelles connexions passent par la passerelle restaurée.

Choisir des règles de failover adaptées

Les Failover rules déterminent à quel moment une passerelle est considérée comme injoignable. Les options disponibles sont :

Testing method: Ping ou TCP
IP address
pour TCP, le Port en plus
la combinaison de plusieurs conditions d’échec avec AND ou OR

Une déconnexion physique du câble est déjà détectée au niveau de l’interface. Le contrôle Ping créé par défaut vers l’adresse IP de la passerelle vérifie en plus si l’équipement opérateur directement connecté ou le premier hop de l’opérateur est joignable. Il peut toutefois rester vert alors que l’accès Internet au-delà du routeur opérateur ne fonctionne plus. Sophos recommande donc une adresse IP publique connue comme cible pour les passerelles WAN/ISP, par exemple 8.8.8.8 ou 8.8.4.4.

Pour IPv6, Sophos cite 2001:4860:4860::8888 comme exemple public. Pour contrôler l’équipement en amont, utiliser l’adresse IPv6 de la passerelle et non son adresse link-local.

Une seule cible ne constitue pas non plus un contrôle d’état complet. Pour une configuration initiale plus robuste, on peut utiliser deux adresses IP publiques durablement accessibles et autorisées par l’organisation :

AND : Le failover n’est déclenché que si tous les contrôles associés échouent. Cela réduit les basculements intempestifs dus à une seule cible injoignable.
OR : Un seul contrôle en échec peut déclencher le failover. Cette option réagit plus rapidement, mais augmente le risque de basculements inutiles.

8.8.8.8 et 8.8.4.4 sont des exemples concrets de Sophos, mais appartiennent au même opérateur et ne représentent donc pas des domaines de panne totalement indépendants. Dans un environnement critique, il vaut mieux utiliser deux cibles autorisées appartenant à des opérateurs différents. Une cible Ping doit répondre de manière fiable à ICMP ; pour TCP, il faut un service stable dont le port peut être contrôlé.

ANY/ALL sur la passerelle de secours et AND/OR dans les règles de contrôle répondent à des questions différentes. ANY/ALL détermine combien de passerelles actives doivent tomber en panne. AND/OR détermine comment plusieurs contrôles évaluent la panne d’une seule passerelle.

La valeur globale Gateway failover timeout dans WAN link manager détermine quand le pare-feu considère qu’une liaison qui ne répond pas est défaillante. Il n’existe pas de valeur universelle. Un timeout trop court réagit plus vite, mais peut provoquer un basculement inutile en cas de perte de paquets ou de brève indisponibilité de la cible de contrôle. Cette valeur sert notamment aussi d’intervalle de Health Check pour les groupes de failover IPsec et ne doit donc pas être modifiée isolément pour une seule liaison WAN. Documenter la valeur initiale, effectuer un test contrôlé, puis l’ajuster uniquement selon le temps de basculement mesuré.

Tester le failover et le failback de manière contrôlée

Un test de câble vérifie uniquement une panne de lien locale. Une panne chez l’opérateur au-delà d’un routeur toujours joignable ne devient visible que lorsque les cibles publiques configurées ne répondent plus non plus. Dans l’idéal, il faut donc tester séparément les deux scénarios.

Confirmer la fenêtre de maintenance, le plan de retour arrière et l’accès d’administration alternatif.
Sous Network > WAN link manager, documenter l’état des passerelles principale et de secours.
Depuis un client de test, vérifier DNS, HTTPS et une application importante. Noter également l’adresse IP publique de sortie actuellement utilisée.
Pour le test du lien, débrancher de manière contrôlée le câble WAN principal. Pour le véritable test de supervision, maintenir le lien vers le pare-feu actif et interrompre la connexion en amont de l’équipement opérateur, si cela peut être fait sans risque.
Attendre plus longtemps que la valeur Gateway failover timeout configurée.
Vérifier que la passerelle principale est indiquée comme défaillante et que la passerelle de secours est active.
Démarrer de nouvelles sessions DNS, HTTPS, VPN et applicatives. Contrôler la règle de pare-feu, le NAT, l’accessibilité de la destination et la nouvelle adresse IP publique de sortie.
Vérifier les événements de montée et de descente des passerelles dans Log viewer. Pour une analyse plus approfondie, dgd.log contient les événements relatifs à la gestion des passerelles WAN et au failover des liaisons.
Rétablir la liaison principale et contrôler séparément les sessions existantes et les nouvelles. Cela permet de vérifier si le comportement de failback configuré se produit réellement.
Documenter l’état final, les applications et l’accessibilité externe.

Un ping réussi prouve uniquement que la cible de contrôle répond. Il ne confirme ni DNS, ni NAT, ni VPN, ni les services publiés, ni une application métier. Packet Capture dans WebAdmin de Sophos Firewall aide à vérifier le chemin réel des paquets ; Journaux de service Sophos Firewall explique dgd.log et les autres fichiers.

Erreurs fréquentes et limites

La liaison de secours répartit déjà du trafic de production : La nouvelle passerelle est encore définie comme Active. Pour une liaison exclusivement de secours, la passer sur Backup.
La passerelle de secours ne devient pas active lors d’une panne : Vérifier l’état de la passerelle, son type, ANY/ALL, les Failover rules et Gateway failover timeout. Avec plusieurs passerelles actives, ALL peut volontairement empêcher l’activation tant qu’un chemin actif reste disponible.
La passerelle est verte, mais Internet ne fonctionne pas : La cible de contrôle est joignable alors que DNS, le routage, la règle de pare-feu, le NAT ou l’application échoue. Vérifier du trafic réel, Log Viewer et Packet Capture.
Le pare-feu bascule sans véritable panne de l’opérateur : Une cible de contrôle unique ne répond pas, OR est trop sensible ou le timeout est trop court pour la qualité de la liaison. Vérifier les cibles et la perte de paquets mesurée.
Les sessions existantes sont interrompues lors du basculement : L’adresse IP source publique ou l’état NAT change. Les pairs distants peuvent alors rejeter la connexion. Le basculement WAN ne garantit pas automatiquement une disponibilité sans interruption.
Le trafic sortant fonctionne, mais pas les services entrants : Le second opérateur doit offrir l’accessibilité publique nécessaire, DNS ou Dynamic DNS, DNAT, les règles de pare-feu et, le cas échéant, les certificats. DNAT pour publier des serveurs et Principes du NAT aident à cerner le problème.
Le VPN fonctionne uniquement via la liaison principale : Le Remote Gateway, l’adresse d’écoute locale, le FQDN, les identités, la configuration du tunnel et la route de retour doivent également correspondre au chemin de secours. Un simple basculement WAN ne crée pas de seconde connexion VPN.

Si des applications, des groupes d’utilisateurs ou des réseaux de destination doivent utiliser des liaisons différentes, ou si la latence, le jitter et la perte de paquets doivent guider la sélection du chemin, la décision doit être définie dans les routes et profils SD-WAN Sophos Firewall. Une liaison mobile de secours ajoute aussi les questions de SIM, d’APN, de volume de données, de CGNAT et de qualité du signal ; ces points sont expliqués dans WAN cellulaire et basculement 4G/5G.

Exploitation

Configurer, si nécessaire, des notifications par e-mail pour les changements d’état des passerelles. Sous Administration > Notification settings, commencer par configurer le serveur de messagerie, l’expéditeur et le destinataire. Sous System services > Notification list, activer ensuite le commutateur global Email notifications, puis sélectionner l’événement Gateway status sous System. La sélection d’une ligne d’événement ne suffit pas, à elle seule, à envoyer un e-mail.
Vérifier l’état des passerelles et dgd.log après tout basculement non planifié.
Tester le failover et le failback au moins une fois par trimestre, ainsi qu’après toute modification de l’opérateur, des interfaces, du NAT, du routage ou du firmware.
Documenter les dépendances aux adresses IP publiques, les pairs VPN, les listes d’autorisation et les services entrants.
Désigner les responsables des pannes opérateur, de l’escalade et du retour au fonctionnement normal.
Vérifier régulièrement les cibles de contrôle ; une cible durablement modifiée ou devenue injoignable ne doit pas déterminer la logique de basculement à l’insu de l’équipe.
Avec plusieurs liaisons actives, vérifier les poids et Session Persistence à partir de l’utilisation réelle, et pas uniquement de la bande passante nominale.