Créer une route IPsec sur Sophos Firewall

Normalement, le Sophos Firewall détecte lui-même par quel tunnel IPsec un réseau cible est accessible. Dans un tunnel IPsec basé sur des politiques classique, les réseaux locaux et distants font partie de la configuration du tunnel. En revanche, avec IPsec basé sur des routes, le trafic est dirigé vers le tunnel via des interfaces XFRM, des routes statiques, des routes SD-WAN ou un routage dynamique.

Une route IPsec manuelle n’est donc pas standard pour chaque tunnel. Il s’agit d’un outil pour certains scénarios basés sur des politiques, notamment lorsque le trafic transféré doit fonctionner avec le NAT ou une attribution particulière au tunnel. Si une telle route est mal configurée, le trafic peut emprunter le mauvais tunnel ou rendre une connexion existante plus difficile à suivre.

Pour les nouveaux tunnels de site à site, commencez par Configurer un VPN IPsec de site à site sur Sophos Firewall. Pour le dépannage général d’IPsec, consultez Dépannage VPN IPsec sur Sophos Firewall. Pour les VPN basés sur des routes, XFRM et la planification des interfaces, consultez Configurer les zones et interfaces sur Sophos Firewall.

Quand une route IPsec est-elle pertinente ?

Une route IPsec est particulièrement pertinente lorsqu’un tunnel IPsec basé sur des politiques existe, mais que le trafic attendu n’est pas correctement attribué au tunnel.

Cas typiques :

Un hôte ou un réseau doit passer spécifiquement par un tunnel basé sur des politiques.
Il existe plusieurs tunnels, des réseaux cibles qui se chevauchent ou des configurations VPN historiques.
Le trafic est traduit par DNAT ou SNAT et doit ensuite être attribué à un tunnel IPsec existant.
Après une mise à niveau vers SFOS 22, il convient de vérifier si les cas particuliers basés sur des politiques fonctionnent toujours comme prévu.
La recherche de route, le Log Viewer ou le Packet Capture montrent que le trafic se dirige vers le WAN ou un chemin incorrect.

Tous ces cas ne sont pas résolus par ipsec_route. Il faut d’abord vérifier les règles de pare-feu, les règles NAT, la priorité des routes, les passerelles locales et les routes de retour.

Basé sur des politiques, basé sur des routes et SFOS 22

La différence principale :

IPsec basé sur des politiques: Sophos Firewall effectue les recherches IPsec en arrière-plan. Le tunnel est principalement piloté par les réseaux locaux et distants dans la connexion IPsec, les règles de pare-feu et, si nécessaire, ipsec_route.
IPsec basé sur des routes: Le trafic est routé vers l’interface du tunnel. Le pilotage se fait via l’interface XFRM, une route statique, une route SD-WAN ou un routage dynamique.

Pour les nouvelles connexions de site à site ou plus importantes, l’IPsec basé sur des routes est souvent plus clair, car les modifications de routage ne changent pas les sélecteurs de tunnel à chaque fois. Pour les connexions simples de site à site ou les environnements existants, l’IPsec basé sur des politiques reste pertinent.

SFOS 22 a apporté plusieurs modifications au comportement IPsec. Les notes de version de SFOS-22.0-MR1 documentent plusieurs problèmes résolus concernant l’IPsec basé sur des politiques, ipsec_route, SD-WAN, SNAT et la recherche de route. Pour les administrateurs, cela signifie qu’après une mise à niveau, les cas particuliers basés sur des politiques doivent être testés spécifiquement, surtout si le NAT, MPLS, SD-WAN ou des routes IPsec manuelles sont impliqués.

Prérequis

Avant de procéder à une modification, ces points doivent être clairs :

Accès à la Device Console, par exemple via SSH.
Nom du tunnel IPsec.
Hôte cible ou réseau cible à atteindre via le tunnel.
Connexion IPsec active ou correctement configurée.
Règles de pare-feu appropriées pour la direction attendue.
Clarté sur l’implication du NAT.
L’état actuel des routes IPsec existantes est documenté.

Si l’accès à la console n’est pas encore configuré, Connecter Sophos Firewall via SSH explique comment établir une connexion SSH au pare-feu et ouvrir la Device Console.

⚠️ Une route IPsec incorrecte peut perturber le trafic productif. Avant la modification, le nom du tunnel, le réseau cible, le NAT, le chemin de retour et les routes existantes doivent être documentés.

Vérifications avant la modification

Il ne faut pas définir une route IPsec comme première étape. Cette séquence est recommandée :

Vérifier le statut du tunnel : La connexion IPsec est active et les réseaux attendus sont négociés.
Vérifier les règles de pare-feu : La zone source, la zone de destination, la source, la destination, le service et la journalisation sont corrects.
Vérifier le NAT : Il est clair si les adresses IP d’origine ou traduites doivent passer par le tunnel.
Vérifier la priorité des routes : Les routes statiques, SD-WAN et VPN sont évaluées dans l’ordre attendu. Si plusieurs types de routage sont en concurrence, Modifier en toute sécurité la priorité des routes sur Sophos Firewall peut aider.
Vérifier le point de terminaison : Le point de terminaison connaît le chemin de retour et l’adresse source attendue.
Utiliser Packet Capture : Vérifiez si le trafic arrive, où il est redirigé et si les réponses reviennent.

Pour la vérification générale des règles, Tester une règle de pare-feu avec Log Viewer, Policy Test et Packet Capture est approprié. Pour les bases du NAT, Comprendre le NAT sur Sophos Firewall est utile.

Afficher les routes IPsec existantes

Les commandes sont exécutées dans la Device Console, pas dans l’Advanced Shell.

system ipsec_route show

La sortie doit être documentée avant chaque modification. Cela permet de voir plus tard si une route a été ajoutée et si elle doit être supprimée.

De plus, la table de routage IPsec peut être pertinente pour l’analyse :

ip route show table 220

Cette vérification est effectuée dans l’Advanced Shell et est plutôt destinée au dépannage. Pour les modifications normales de ipsec_route, la Device Console reste le bon endroit.

Créer une route IPsec pour un hôte

Si un seul hôte doit être accessible via un tunnel spécifique, utilisez host.

Syntaxe :

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

Exemple :

system ipsec_route add host 10.33.46.69 tunnelname Azure_CH

Ensuite, il ne faut pas seulement tester le ping, mais vérifier le trafic applicatif réel. Un test ICMP peut fonctionner, tandis que TCP, NAT ou le chemin de retour peuvent encore être incorrects.

Créer une route IPsec pour un réseau

Si un réseau complet doit être accessible via le tunnel, utilisez net.

Syntaxe :

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

Exemple :

system ipsec_route add net 10.33.46.0/255.255.255.0 tunnelname Azure_CH

Pour les routes de réseau, une prudence particulière est nécessaire. Un réseau trop grand peut entraîner plus de trafic dans le tunnel que prévu. En cas de réseaux qui se chevauchent, il doit être clair à l’avance quelle partie voit quelles adresses et si le NAT est utilisé.

Supprimer une route IPsec

Si la route n’est plus nécessaire ou a été mal configurée, elle peut être supprimée.

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>

Ensuite, vérifiez à nouveau la liste :

system ipsec_route show

Si la route a influencé le trafic productif, la connexion concernée doit être testée à nouveau après la suppression et les entrées du Log Viewer doivent être comparées.

NAT et IPsec basé sur des politiques

Le NAT n’est pas fondamentalement incorrect avec IPsec. Il doit cependant être soigneusement planifié, car le NAT modifie l’adresse vue par le point de terminaison.

Sophos distingue notamment ces cas avec IPsec :

NAT directement dans la configuration IPsec, par exemple pour des réseaux qui se chevauchent.
Règles NAT autonomes sous Rules and policies > NAT rules.
ipsec_route pour le trafic transféré, lorsque le trafic traduit doit être attribué à un tunnel basé sur des politiques.
sys-traffic-nat pour le trafic généré par le système de la propre firewall.

Une règle NAT ne modifie pas automatiquement la décision de routage du firewall. Si un tunnel policy-based existant est utilisé avec DNAT/SNAT pour des hôtes supplémentaires, une IPsec Route adaptée vers le réseau distant reste nécessaire. Pour les règles SNAT réflexives, l’adresse source traduite doit exister comme objet IP host ; on ne peut pas simplement traduire directement vers une interface.

L’important est la direction : Si le trafic IPsec basé sur des politiques doit être traduit par SNAT, la règle SNAT appropriée doit fonctionner avec Outbound interface sur Any. Si la règle pointe plutôt vers des interfaces WAN spécifiques, elle ne s’appliquera pas au trafic IPsec basé sur des politiques. Ce sont précisément ces détails qui, en pratique, conduisent à des tunnels qui sont verts mais ne transportent pas le trafic utilisateur attendu.

Le trafic généré par le système est un cas particulier

ipsec_route ne résout pas seul tous les problèmes de trafic. Pour le trafic client ou serveur transféré, la commande peut être directement pertinente. Le trafic généré par le firewall lui-même, par exemple les requêtes d’authentification ou les cas liés au DHCP, nécessite aussi une logique correcte de source NAT et de routage.

Sans configuration ciblée, le trafic généré par le système utilise généralement une passerelle de Network > WAN link manager. Un tunnel IPsec vert ne suffit donc pas à envoyer automatiquement les requêtes propres au firewall dans le tunnel. DHCP Relay doit aussi être évalué séparément : pour l’IPsec basé sur des politiques, le DHCP Relay doit activer spécifiquement l’option Relay through IPsec. Pour les VPN route-based, cette option n’est pas nécessaire ; le trafic DHCP y est alors acheminé comme un trafic normal via des routes statiques, SD-WAN ou dynamiques vers l’autre extrémité, à condition que les sous-réseaux locaux et distants soient réglés sur Any et que des routes correspondantes existent des deux côtés.

Concrètement, cela signifie :

Le trafic client ou serveur à travers le firewall peut être un sujet ipsec_route.
Avec IPsec basé sur des politiques, les requêtes propres au firewall peuvent nécessiter une combinaison de ipsec_route, sys-traffic-nat et de sous-réseaux locaux ou distants adaptés.
Avec IPsec basé sur des routes, ces cas passent plutôt par des routes SD-WAN vers l’interface XFRM et sys-traffic-nat.
Il ne faut pas essayer de résoudre chaque problème de trafic système de manière générale avec ipsec_route.

Pour le trafic généré par le système et le contexte SD-WAN, consultez Routage SD-WAN pour les paquets de réponse et le trafic système.

Tester la modification

Après avoir créé ou supprimé une route IPsec, le trafic concerné doit être testé spécifiquement.

Procédure pratique :

Définir le cas de test : Source, Destination, Service, direction et tunnel attendu.
Activer la journalisation des règles de pare-feu pour la règle concernée.
Documenter system ipsec_route show.
Générer le trafic de test une seule fois.
Filtrer Log Viewer sur la source, la destination et la règle de pare-feu.
Exécuter Packet Capture avec un filtre strict.
Vérifier si les octets dans ipsec statusall augmentent dans les deux sens.
Vérifier le point de terminaison pour le chemin de retour, le NAT et le pare-feu local.

Si de grandes transmissions restent bloquées, bien que le routage et le NAT semblent corrects, il convient également de vérifier MTU et MSS en cas de problèmes VPN.

Erreurs typiques

Tunnel vert, pas de trafic : une règle, le NAT, le chemin de retour ou l’attribution IPsec manque souvent. Vérifier Log Viewer, Packet Capture et ipsec statusall.
Le trafic se dirige vers le WAN : la priorité des routes ou l’attribution IPsec ne correspond pas. Vérifier Route Lookup, les routes SD-WAN et ipsec_route show.
SNAT ne s’applique pas à IPsec basé sur des politiques : la règle SNAT a probablement une mauvaise interface de sortie. Vérifier la règle SNAT avec Any.
Un hôte fonctionne, un réseau non : le masque de réseau, l’objet ou le sélecteur de trafic ne correspond pas. Comparer les réseaux locaux et distants.
Comportement différent après la mise à niveau SFOS 22 : un ancien cas particulier avec IPsec basé sur des politiques, NAT ou SD-WAN peut être impliqué. Vérifier les release notes, le cas de test et le peer.
Le trafic propre au firewall ne passe pas par le tunnel : le trafic système est routé différemment. Vérifier SD-WAN, la priorité des routes et sys-traffic-nat.

Liste de contrôle

Avant la modification :

Nom du tunnel et point de terminaison documentés.
Hôte cible ou réseau cible clairement défini.
Règles de pare-feu et règles NAT vérifiées.
Priorité des routes et contexte SD-WAN vérifiés.
Routes IPsec existantes sauvegardées.
Fenêtre de maintenance ou moment de test contrôlé planifié.

Après la modification :

system ipsec_route show vérifié à nouveau.
Log Viewer montre la règle attendue.
Packet Capture montre le chemin attendu.
Le point de terminaison voit l’adresse source attendue.
Le chemin de retour fonctionne.
Modification et justification documentées.

FAQ

Chaque connexion IPsec basée sur des politiques a-t-elle besoin d'une route IPsec ?

Non. Dans les connexions de site à site basées sur des politiques normales, la configuration IPsec avec des réseaux locaux et distants appropriés suffit. Une route IPsec manuelle est un outil pour les cas particuliers.

Devrait-on utiliser des VPN basés sur des routes plutôt que basés sur des politiques pour les nouveaux VPN ?

Pour les connexions de site à site plus grandes, en croissance ou dynamiquement routées, l’IPsec basé sur des routes est souvent plus clair. Les tunnels basés sur des politiques simples existants peuvent cependant rester pertinents s’ils sont stables et bien documentés.

Pourquoi l'interface de sortie Any est-elle importante pour SNAT ?

Dans l’IPsec basé sur des politiques, le trafic ne passe pas comme le trafic Internet normal par une interface WAN spécifique. Si une règle SNAT est limitée à une interface WAN spécifique, elle ne s’appliquera pas au trafic IPsec basé sur des politiques.

L'ipsec_route aide-t-il pour le trafic propre au firewall ?

Pas seul. Pour le trafic transféré, ipsec_route peut être directement pertinent. Pour le trafic propre au firewall, il faut aussi vérifier sys-traffic-nat, SD-WAN ou les sous-réseaux IPsec basés sur des politiques.

Faut-il réinitialiser toutes les routes IPsec après SFOS 22 ?

Non. Mais les cas particuliers IPsec basés sur des politiques avec NAT, SD-WAN, MPLS ou des routes IPsec manuelles doivent être testés spécifiquement après une mise à niveau.