Créer une route IPsec sur Sophos Firewall

Une route IPsec manuelle n’est pas nécessaire pour chaque tunnel. Elle concerne surtout les tunnels IPsec basés sur des politiques lorsque du trafic transféré et traduit doit être associé à un tunnel précis.

IPsec basé sur des routes : ne pas créer d’ipsec_route. Le trafic passe par des interfaces XFRM et des routes statiques, SD-WAN ou dynamiques. IPsec basé sur des politiques sans cas NAT particulier : vérifier d’abord le tunnel, les règles de pare-feu, le NAT et le chemin de retour. IPsec basé sur des politiques avec du trafic DNAT ou SNAT transféré : les étapes suivantes permettent de vérifier et de configurer le chemin.

⚠️ Une route IPsec incorrecte peut diriger le trafic de production vers le mauvais tunnel. Avant toute modification, documenter l’état initial et préparer un retour arrière précis.

Vérifier, créer et supprimer une route IPsec

Les commandes d’affichage, de création et de suppression s’exécutent dans la Device Console. Si l’accès n’est pas encore configuré, Se connecter à Sophos Firewall via SSH explique comment ouvrir la Device Console.

Documenter l’état initial

Le chemin concret du trafic doit être établi avant toute commande d’ajout :

• Il s’agit d’un tunnel basé sur des politiques actif, et non d’un tunnel IPsec basé sur des routes.
• L’hôte ou le réseau de destination correspond aux sélecteurs du tunnel et à la traduction prévue.
• Les règles de pare-feu et de NAT correspondent au trafic de test défini ; pour le SNAT, Outbound interface est réglé sur Any.
• Route Precedence et les routes concurrentes ont été vérifiées.
• Le pair distant attend l’adresse source visible et dispose d’une route de retour.

Commencer par documenter toutes les routes IPsec manuelles :

system ipsec_route show

En cas de problème de routage ou de NAT, documenter également Route Precedence et le NAT du trafic système :

system route_precedence show
show advanced-firewall

Cette ancienne vue de dépannage peut également être utile dans l’Advanced Shell :

ip route show table 220

Selon Sophos, les routes IPsec basées sur des politiques et les entrées ipsec_route n’y sont pas visibles sous SFOS 22. L’absence d’une entrée ne prouve donc pas qu’aucune route IPsec n’existe. system ipsec_route show, la configuration et un test de trafic restent déterminants.

Créer une route pour un hôte

Syntaxe :

system ipsec_route add host <host-ip> tunnelname <tunnelname>

Exemple pour l’hôte 10.33.46.69 via le tunnel Azure_CH :

system ipsec_route add host 10.33.46.69 tunnelname Azure_CH

Créer une route pour un réseau

Syntaxe :

system ipsec_route add net <network>/<netmask> tunnelname <tunnelname>

Exemple pour le réseau 10.33.46.0/24 :

system ipsec_route add net 10.33.46.0/255.255.255.0 tunnelname Azure_CH

Le masque doit correspondre exactement à la destination voulue. Une route trop large peut envoyer involontairement du trafic supplémentaire dans le tunnel.

Supprimer une route en toute sécurité

⚠️ Les commandes de suppression ne contiennent aucun nom de tunnel. Avant la suppression, utiliser system ipsec_route show pour vérifier que l’hôte ou le réseau est sans ambiguïté et conserver la commande d’ajout complète pour le retour arrière. Ne pas supprimer une entrée ambiguë sur une simple supposition.

Supprimer une route d’hôte :

system ipsec_route del host <host-ip>

Supprimer une route de réseau :

system ipsec_route del net <network>/<netmask>

Vérifier ensuite de nouveau la liste :

system ipsec_route show

Si le résultat du test se dégrade, restaurer la route avec la commande d’ajout documentée auparavant.

Quand utiliser ipsec_route

IPsec basé sur des politiques et IPsec basé sur des routes

Avec un tunnel IPsec basé sur des politiques, les réseaux locaux et distants définissent les sélecteurs du tunnel. Une ipsec_route manuelle peut associer des hôtes ou réseaux supplémentaires à un tunnel existant, mais elle ne remplace ni des sélecteurs adaptés, ni les règles de pare-feu, ni une route de retour.

Avec un tunnel IPsec basé sur des routes, le trafic est dirigé vers l’interface XFRM. Selon la conception, utiliser une route statique, une route SD-WAN ou un routage dynamique. Une ipsec_route n’est pas l’outil adapté. Configurer un VPN IPsec site à site sur Sophos Firewall et Configurer les zones et interfaces sur Sophos Firewall expliquent les bases des deux variantes.

Différence entre SFOS 21.5 et 22

Le classement dans Route Precedence a changé :

• Sous SFOS 21.5, les routes IPsec basées sur des politiques créées automatiquement appartiennent à la catégorie vpn, tandis que les entrées ipsec_route manuelles appartiennent à static.
• Sous SFOS 22, les routes IPsec basées sur des politiques automatiques et manuelles appartiennent à la catégorie vpn. Elles n’apparaissent pas comme des routes ordinaires du noyau et sont traitées en interne à l’aide de marques, de zones et d’indicateurs.

Après une mise à niveau depuis SFOS 21.5, tester de nouveau Route Precedence et les cas particuliers existants. Le contrôle avant mise à niveau vers SFOS 22 couvre les vérifications générales. Modifier Route Precedence sur Sophos Firewall en toute sécurité explique l’ordre global.

Une route manuelle n’est pertinente que si le tunnel, les sélecteurs de trafic, la règle de pare-feu, la règle NAT et le chemin de retour sont corrects. Elle ne corrige ni un masque incorrect, ni une route absente sur le pair distant, ni une règle bloquante.

NAT pour le trafic transféré

Le NAT modifie les adresses, mais pas automatiquement la décision de routage. Si un tunnel basé sur des politiques transporte du trafic supplémentaire traduit par DNAT ou SNAT, une route IPsec correspondante vers l’hôte ou le réseau distant peut donc être nécessaire.

Pour le SNAT avec un tunnel IPsec basé sur des politiques, la règle NAT correspondante doit utiliser Any pour Outbound interface. Si elle est limitée à une interface WAN précise, elle ne correspond pas au trafic IPsec. Comprendre le NAT sur Sophos Firewall explique plus en détail l’ordre de traitement, la correspondance et le chemin de retour.

Effectuer la modification pendant une fenêtre de maintenance ou avec un cas de test contrôlé. Les valeurs suivantes doivent être connues au préalable :

• adresses source et destination d’origine et traduites,
• réseaux local et distant de la connexion IPsec,
• nom du tunnel et règle de pare-feu attendue,
• route de retour et adresses autorisées sur le pair distant.

Traiter séparément le trafic généré par le système

Les requêtes DNS, d’authentification ou autres générées par le pare-feu ne suivent pas automatiquement la même logique que le trafic client transféré. Sous SFOS 22, une ipsec_route n’est normalement pas nécessaire pour ce trafic. Seule la procédure Sophos spécifique aux requêtes d’authentification la mentionne comme solution de repli conditionnelle lorsque la requête n’entre manifestement pas dans le tunnel basé sur des politiques en raison de la Route Precedence concrète.

Si nécessaire, sys-traffic-nat permet de définir l’adresse source de ce trafic. Exemple : le pare-feu doit atteindre le serveur 10.10.2.15 avec l’adresse SNAT/interface définie 10.10.1.1. Cette adresse doit correspondre aux sous-réseaux IPsec et disposer d’une route de retour sur le pair distant.

Les commandes suivantes s’exécutent dans la Device Console :

set advanced-firewall sys-traffic-nat add destination 10.10.2.15 snatip 10.10.1.1
show advanced-firewall

Retour arrière :

set advanced-firewall sys-traffic-nat delete destination 10.10.2.15 snatip 10.10.1.1

Si interface ou netmask a également été utilisé lors de l’ajout, les mêmes sélecteurs doivent être indiqués lors de la suppression. Vérifier le routage SD-WAN pour les Reply Packets et le System Traffic contient d’autres exemples.

Le DHCP nécessite une analyse distincte :

• Avec un tunnel IPsec basé sur des politiques, le relais nécessite l’option Relay through IPsec, des sous-réseaux IPsec locaux et distants adaptés, sys-traffic-nat, ainsi que les règles et routes de retour nécessaires sur le pair distant. Si les requêtes n’entrent toujours pas dans le tunnel en raison de la configuration de routage concrète, une ipsec_route peut être nécessaire comme solution de repli vérifiée.
• Avec un tunnel IPsec basé sur des routes, ne pas activer Relay through IPsec. Un relais vers le côté serveur DHCP est pris en charge via une interface XFRM avec des sous-réseaux Any-to-any, des routes statiques, SD-WAN ou dynamiques, et des règles adaptées sur les deux pare-feu. Une ipsec_route n’a pas sa place dans ce chemin.
• Si le pare-feu du site principal sert lui-même de serveur DHCP pour des réseaux distants dans une configuration IPsec basée sur des politiques, Lease over IPsec doit être activé. Selon Sophos, les interfaces de pare-feu utilisées comme serveurs DHCP ne sont pas prises en charge dans cette configuration basée sur des routes.

Cette commande s’exécute également dans la Device Console :

system dhcp lease-over-IPSec enable

Les anciennes procédures SFOS 21.5 mentionnaient plus souvent ipsec_route pour l’authentification et le DHCP. Examiner ces configurations lors d’une mise à niveau et ne pas les reproduire sans vérification.

Tester et valider la modification

Un tunnel vert ou un ping réussi ne constitue pas une preuve suffisante. Un test ICMP peut réussir alors que TCP, le NAT ou le chemin de retour reste incorrect.

1. Définir la source, la destination, le service, la direction et le tunnel attendu.
2. Activer la journalisation de la règle de pare-feu concernée.
3. Documenter system ipsec_route show avant le test.
4. Générer une seule fois le trafic applicatif réel de manière contrôlée.
5. Filtrer Log Viewer par source, destination et règle.
6. Exécuter Packet Capture avec un filtre précis des deux côtés du chemin.
7. Vérifier l’adresse source, la route de retour et le pare-feu local sur le pair distant.
8. Documenter le résultat, la modification et la commande de retour arrière.

Dans l’Advanced Shell, ces commandes affichent les SA négociées, les compteurs d’octets et les politiques XFRM :

ipsec statusall
ip xfrm policy

Elles ne prouvent toutefois pas à elles seules que le NAT, la règle de pare-feu et le chemin de retour sont corrects. Tester une règle de pare-feu avec Log Viewer, Policy Test et Packet Capture aide à mener une analyse systématique. Si seules les transmissions volumineuses se bloquent, vérifier également MTU et MSS en cas de problèmes VPN.

Circonscrire les erreurs et revenir en arrière

Le tunnel est actif, mais aucun trafic ne circule

Vérifier la règle de pare-feu, le NAT, les sélecteurs de trafic et la route de retour. Comparer ensuite Log Viewer, Packet Capture et les compteurs de ipsec statusall. Dépannage VPN IPsec sur Sophos Firewall présente le déroulement complet.

Le trafic part vers le WAN

Vérifier Route Precedence, les routes SD-WAN et system ipsec_route show. Sous SFOS 22, l’absence d’une entrée dans la table 220 ne doit pas servir de preuve qu’aucune route IPsec n’existe.

Le SNAT ne s’applique pas

Pour un tunnel IPsec basé sur des politiques, vérifier que Outbound interface est réglé sur Any et que les adresses d’origine et traduites correspondent au tunnel et au pair distant.

Un hôte fonctionne, mais pas un réseau

Comparer le masque, l’objet hôte/réseau et les sélecteurs de trafic des deux côtés. Ne pas créer de route plus large avant d’avoir compris l’écart.

Le chemin change après la mise à niveau vers SFOS 22

Vérifier de nouveau Route Precedence et tous les cas particuliers basés sur des politiques impliquant NAT, SD-WAN ou MPLS. Ne pas supprimer ou recréer automatiquement les anciennes routes.

Le trafic généré par le pare-feu n’atteint pas la destination

Déterminer d’abord s’il s’agit d’authentification, de DNS, de DHCP ou d’un autre service. Vérifier ensuite Route Precedence, SD-WAN, sys-traffic-nat et le workflow SFOS 22 correspondant.

Si une erreur apparaît immédiatement après la modification, supprimer la nouvelle route, vérifier avec system ipsec_route show et répéter le test précédent. Si le problème persiste, restaurer complètement l’état initial documenté.

FAQ