Aller au contenu
Avanet

Configurer et tester une route SD-WAN Sophos Firewall

Sophos Firewall

Une route SD-WAN permet de définir par quel gateway passe un flux précis sur Sophos Firewall. Elle est utile avec plusieurs accès Internet, MPLS, des VPN IPsec route-based, la VoIP ou des services cloud. La route doit être ciblée et testée avec du trafic réel, sinon elle risque d’inclure des réseaux internes ou d’utiliser la mauvaise IP publique lors du failover.

Réponse courte

Une route SD-WAN se crée ici :

Routing > SD-WAN routes > IPv4 / IPv6 > Add

Quatre points doivent être définis au préalable :

  • quel trafic doit correspondre selon incoming interface, source, destination et service
  • quel primary/backup gateway ou SD-WAN profile doit être utilisé
  • si seuls ces gateways sont autorisés et quel NAT leur correspond
  • comment vérifier la route, le gateway et le chemin retour avec Log Viewer et Packet Capture

Pour les destinations IPv4 publiques, il vaut mieux éviter un Any global et utiliser si possible Internet IPv4 group ou des destinations précises. Si SD-WAN précède Static dans la route precedence, une route Any trop large peut également envoyer du trafic interne vers le gateway WAN.

La vidéo complète le guide de planification, de configuration et de validation des routes SD-WAN sur Sophos Firewall.

Utilisation et planification

Quand préférer SD-WAN à une route statique

Une route statique suffit lorsqu’un réseau de destination est toujours joignable par un next hop fixe. Les routes SD-WAN ajoutent des critères comme la source, le service, l’utilisateur ou l’application et peuvent choisir les gateways selon leur disponibilité ou leur qualité.

Cas courants :

  • envoyer certains clients ou services via WAN2 et basculer sur WAN1 en cas de panne
  • envoyer la VoIP ou les applications cloud par un chemin à faible latence et faible perte de paquets
  • utiliser MPLS, LTE/5G ou un tunnel IPsec route-based comme chemin principal ou de secours
  • lier le trafic à un fournisseur dont l’IP publique est autorisée par un système distant

Exemple de planification et prérequis

Avant de créer la route, il faut décrire un flux concret. Pour le trafic Microsoft 365, la planification peut être la suivante :

  • Incoming interface : interface LAN interne
  • Source network : Client_Net_10.20.0.0_24
  • Destination : groupe de destinations Microsoft 365 géré en interne ou Internet IPv4 group
  • Services : HTTPS et, si nécessaire, un groupe de services pour UDP 3478-3481
  • Primary gateway : WAN2
  • Backup gateway : WAN1
  • Fallback : autoriser la default route ou activer Route only through specified gateways
  • NAT : MASQ ou IP SNAT fixe correspondant au gateway choisi
  • Test : IP client, destination, gateway attendu et entrée de log attendue

Il faut aussi des règles firewall appropriées, des règles NAT pour le trafic à traduire, le logging firewall activé et un accès à Log viewer et Diagnostics > Packet capture. Les gateways WAN se trouvent sous Network > WAN link manager ; les custom gateways pour MPLS, RED ou XFRM se créent sous Routing > Gateways. Les bases sont expliquées dans Configurer les zones et interfaces Sophos Firewall.

Avec IPsec route-based, le sens est important : Une interface XFRM sélectionnée comme Incoming interface correspond au trafic entrant depuis le tunnel. Pour le trafic LAN vers VPN, il faut plutôt choisir le gateway de l’interface XFRM comme primary gateway ou l’ajouter à un SD-WAN profile. Les bases sont décrites dans Créer une route IPsec sur Sophos Firewall.

Configurer la route SD-WAN

Définir les critères de correspondance

  1. Ouvrir Routing > SD-WAN routes.
  2. Choisir IPv4 ou IPv6, puis cliquer sur Add.
  3. Saisir un nom explicite comme Clients_M365_WAN2.
  4. Choisir l’Incoming interface par laquelle entre le trafic à piloter.
  5. Choisir éventuellement une valeur DSCP si les paquets entrants sont marqués de manière fiable.
  6. Définir les Source networks et ajouter des Users or groups si nécessaire.
  7. Limiter autant que possible les Destination networks.
  8. Limiter les Services aux protocoles et ports requis.
  9. Sélectionner éventuellement des Application objects.
  10. Sous Link selection settings, choisir un SD-WAN profile ou des primary/backup gateways.
  11. Activer ou désactiver consciemment Route only through specified gateways.
  12. Enregistrer la route et la placer dans le bon ordre ; la première route SD-WAN correspondante gagne.
  13. Tester avec un client et une destination définis.

Les Application Objects nécessitent une Web Protection License active. La première connexion est routée selon l’IP de destination, le port, le protocole et l’incoming interface via une autre route SD-WAN correspondante ou, à défaut, via la default route. L’Application Object ne s’applique aux connexions suivantes qu’après la détection de l’application. Les données de classification ont une TTL de 3600 secondes à partir du début de la session. Pour les Micro Apps, seul le DPI Engine Mode prend en charge toutes les applications ; le Web Proxy Mode ne prend en charge que les Pattern Applications et les Synchronized Security Applications.

Choisir un gateway ou un SD-WAN profile

Les primary/backup gateways suffisent pour un chemin préféré et un fallback. Pour utiliser un SD-WAN profile, il faut créer au moins deux gateways, puis le profile sous Routing > SD-WAN profiles et enfin le sélectionner dans la route. Un profile est utile avec plusieurs chemins, du load balancing ou des critères SLA :

  • First available gateway utilise le premier gateway disponible dans l’ordre défini.
  • Load balancing répartit les connexions ; Session Persistence et Gateway Weights contrôlent l’affinité et la répartition.
  • Best quality compare un seul critère : latence, jitter ou perte de paquets.
  • Custom SLA exige des seuils pour les trois critères et utilise la stratégie de routing choisie s’ils ne sont pas respectés.

Les Health Checks testent par ping ou TCP jusqu’à deux Probe Targets. Ces cibles doivent représenter le chemin concerné, mais ne prouvent pas qu’une application complète fonctionne. Avec Best Quality, le failback ne se produit que si le gateway d’origine est meilleur de 10 ms en latence ou de 5 ms en jitter ; aucune marge de ce type n’existe pour la perte de paquets.

Si Route only through specified gateways est activé, le firewall rejette le trafic lorsque les chemins indiqués ne sont pas disponibles. Sans cette option, il vérifie les autres routes SD-WAN puis la default route. Si un backup gateway est supprimé, Sophos Firewall le remplace par None ; la suppression du primary gateway ou du SD-WAN profile supprime la route et la default route peut prendre le relais.

Aligner route precedence et NAT

La route precedence définit l’ordre entre Static, SD-WAN et VPN. Les réseaux directement connectés et SSL VPN appartiennent à la catégorie Static. L’ordre actuel est visible sous Routing > SD-WAN routes ou dans la Device Console ; les modifications et le rollback sont expliqués dans Modifier prudemment la route precedence Sophos Firewall.

Le routing choisit le chemin, tandis que le NAT modifie les adresses. Le trafic Internet via WAN2 peut donc nécessiter MASQ ou une IP SNAT fixe sur ce chemin. En revanche, le NAT est souvent indésirable pour les réseaux internes et les VPN. Les relations sont expliquées dans Comprendre NAT sur Sophos Firewall : SNAT, DNAT, MASQ, PAT.

Tester et valider la route

Test standard avec du trafic réel

  1. Choisir un client de test avec une IP connue et une destination non ambiguë.
  2. Activer le logging dans la règle firewall correspondante.
  3. Démarrer une connexion réelle.
  4. Dans Log viewer, vérifier source, destination, service, rule ID, NAT ID et gateway.
  5. Contrôler le traffic count de la route SD-WAN : OUT compte les requests et IN les replies uniquement si source et destination correspondent dans le sens concerné.
  6. Sous System services > Log settings, activer le type SD-WAN et vérifier le module SD-WAN dans Log Viewer pour les événements de profile, SLA et route.
  7. En cas de doute, définir sous Diagnostics > Packet capture un filtre précis sur le client, la destination et le port.

Le Policy tester ne prend pas en compte les routes SD-WAN. Il peut vérifier les correspondances de policy, mais ne confirme ni la route SD-WAN choisie ni le gateway réel. Pour une analyse complète, voir Tester une règle Sophos Firewall avec Log Viewer, Policy Test et Packet Capture.

Tester le failover et le failback en sécurité

Un test de panne contrôlé s’effectue dans une fenêtre de maintenance, avec un rollback documenté et un chemin de gestion indépendant vers le firewall. Vérifier d’abord dans la Device Console les valeurs actuelles en lecture seule :

system route_precedence show
show routing reroute-connection
show routing reroute-snat-connection

Ensuite, démarrer du trafic applicatif réel, provoquer de manière contrôlée l’indisponibilité du primary gateway et vérifier le chemin, les sessions, la public source IP et le chemin retour. Ne pas supprimer le primary gateway ou le SD-WAN profile pour ce test, car cela supprime la route et ne teste que le fallback vers la default route. Avec une sélection directe primary/backup, les nouvelles connexions repassent par le primary lorsqu’il revient ; les connexions existantes restent généralement sur le backup gateway.

reroute-connection est activé par défaut et concerne les connexions sans SNAT. Les connexions SNAT ne sont pas reroutées par défaut ; même avec reroute-snat-connection activé séparément, cela ne fonctionne que si les deux chemins utilisent la même source IP traduite. Avec MASQ ou des adresses Override Source Translation différentes, la connexion SNAT n’est pas reroutée et la session existante est interrompue lorsque le chemin tombe.

Dépanner méthodiquement

La route ne correspond pas

  • Comparer incoming interface, source network, destination et service avec le flux réel.
  • Vérifier l’ordre des routes ; la première route SD-WAN correspondante gagne.
  • Pour les Application Objects, vérifier la licence, la détection DPI et une deuxième connexion après classification.
  • Ne pas utiliser le traffic count comme seule preuve, car les requests et replies ne sont comptés que si les critères de source et destination correspondent.
  • Avec le Direct Web Proxy, une correspondance HTTP/HTTPS comme service ne suffit pas : utiliser Any ou un service pour le port configuré sous Web > General settings > Web proxy listening port. Dans ce cas particulier, source network et incoming interface ne correspondent pas pour les reply packets ; le chemin retour du proxy nécessite aussi un WAN default gateway ou une route statique appropriée.

Des switches et des règles de correspondance distincts s’appliquent aux reply packets et au system-generated traffic. Ces cas sont expliqués dans Vérifier le routage SD-WAN Sophos Firewall pour reply packets et system traffic.

Le trafic emprunte le mauvais chemin

  • Pour les destinations IPv4 publiques, remplacer Any par Internet IPv4 group ou des destinations précises.
  • Vérifier la route precedence, surtout si des réseaux internes, SSL VPN ou IPsec policy-based sont concernés.
  • Vérifier l’état des gateways et du SLA ainsi que les Health Check Targets.
  • Comparer la règle NAT et la source IP traduite avec le gateway réellement utilisé.
  • Vérifier si un primary gateway ou un SD-WAN profile a été supprimé, entraînant la suppression de la route.

L’application ou la réponse échoue après le failover

Vérifier d’abord avec Packet Capture si le paquet sort par le gateway attendu et si la réponse revient. Contrôler ensuite le NAT, les listes d’IP publiques autorisées, Session Persistence, MTU/MSS et l’état du chemin VPN ou MPLS. SIP/RTP, les portails bancaires et les API à source IP fixe doivent tout particulièrement être testés avec du trafic applicatif réel.

Si le problème a commencé après une mise à jour du firmware, consulter les notes de version actuelles de SFOS 22.0 avant de modifier largement les règles. SFOS 22.0 MR1 corrige notamment des interruptions SD-WAN aléatoires et l’audio unidirectionnel via un VPN route-based avec SD-WAN routing.

Exploitation et documentation

Pour chaque route SD-WAN en production, documenter son objectif, incoming interface, source/destination, services, gateway ou profile, fallback, comportement NAT attendu, client de test, destination de test, owner et date de révision. Après toute modification d’un fournisseur, VPN, interface ou service cloud, vérifier de nouveau la correspondance, les logs et le failover.

Une route n’est validée que lorsque :

  • les critères de correspondance n’incluent que le trafic prévu
  • la règle firewall, le NAT et la route precedence correspondent à la conception
  • Log Viewer et Packet Capture confirment le chemin attendu
  • le failover, le failback et la public source IP réagissent comme documenté
  • un responsable et la prochaine date de révision sont enregistrés