Aller au contenu
Avanet

Créer une route IPsec sur Sophos Firewall

Sophos Firewall

Une route ipsec_route manuelle s’utilise avec un IPsec basé sur des politiques. Elle associe un hôte ou un réseau de destination à un tunnel de ce type existant. Elle n’étend toutefois pas les sélecteurs de trafic et ne remplace ni les règles de pare-feu et de NAT, ni le chemin de retour sur le pair distant.

Cette commande ne convient pas à un IPsec basé sur des routes. Dans un tunnel Any-to-any, l’interface XFRM reçoit une adresse IP, puis les routes statiques, SD-WAN ou dynamiques déterminent le chemin. Dans un tunnel basé sur des routes avec sélecteurs de trafic, SFOS crée automatiquement la route. Vous ne pouvez attribuer ni adresse IP ni routes personnalisées à l’interface XFRM associée.

⚠️ Une route trop large ou associée au mauvais tunnel peut détourner le trafic de production. Consignez l’état initial avant toute modification et gardez à portée de main la commande de suppression exacte.

Quand utiliser une route IPsec manuelle

Le cas courant est celui d’un trafic transféré dont l’adresse est modifiée par DNAT ou SNAT. Le NAT modifie l’adresse, mais pas la décision de routage. Une route supplémentaire vers le réseau distant peut donc être nécessaire.

Avant d’exécuter la commande, vérifiez les points suivants :

  • La connexion sous Site-to-site VPN > IPsec > IPsec connections est basée sur des politiques.
  • Les sélecteurs de trafic locaux et distants incluent les adresses effectivement présentées au traitement IPsec après le NAT.
  • Les règles de pare-feu et de NAT correspondent au trafic de test défini. Pour un SNAT avec un IPsec basé sur des politiques, Outbound interface est défini sur Any.
  • Le pair distant attend l’adresse source visible et dispose d’une route de retour par le même tunnel.
  • Aucune route statique ou SD-WAN existante, ni la priorité globale des routes, n’oriente la destination vers un autre chemin.

Une route manuelle ne corrige ni un masque réseau erroné, ni un sélecteur incompatible, ni une règle bloquante. Configurer un VPN IPsec site à site sur Sophos Firewall présente les différents types de tunnels.

Consigner l’état initial dans la Device Console

Dans WebAdmin, ouvrez admin > Console, puis sélectionnez 4. Device console. Pour un accès SSH, Se connecter à Sophos Firewall via SSH mène au même menu.

Affichez d’abord les routes IPsec manuelles existantes et l’ordre global :

system ipsec_route show
system route_precedence show

Enregistrez la sortie avec le nom du tunnel, les sélecteurs de trafic, l’ID de règle de pare-feu, l’ID de règle NAT et le flux de test prévu. Sous SFOS 22, les routes VPN basées sur des politiques générées automatiquement et les entrées ipsec_route manuelles appartiennent à la catégorie vpn. Ces routes ne sont pas visibles dans la table de routage WebAdmin ; ip route show table 220 ne constitue donc pas une preuve fiable du contraire.

Ne modifiez pas la priorité des routes en marge de cette opération. Elle est globale et affecte d’autres connexions. Si elle doit réellement être modifiée, Modifier en toute sécurité la priorité des routes de Sophos Firewall décrit une procédure distincte avec restauration fondée sur les valeurs.

Créer la route à l’aide d’un exemple NAT contrôlé

Sophos documente le cas d’usage bien délimité suivant :

  • Un tunnel basé sur des politiques HO_to_Branch relie le réseau local 192.168.2.0/24 au réseau distant 192.168.3.0/24.
  • Le serveur local réel 172.16.16.10 se trouve hors du sélecteur local.
  • Le pair distant le contacte à l’adresse 192.168.2.1. Cette adresse de substitution appartient au sélecteur local et correspond, dans l’exemple, à l’adresse de l’interface LAN du pare-feu.
Remote 192.168.3.0/24 → 192.168.2.1 → DNAT → Server 172.16.16.10
Server 172.16.16.10 → reflexive SNAT → 192.168.2.1 → IPsec → Remote

Remplacez le réseau, les adresses et le nom du tunnel par vos propres valeurs. L’adresse de substitution doit correspondre à la sélection locale de phase 2 ; le réseau de destination distant doit être couvert par le tunnel existant.

1. Associer le réseau distant au tunnel

Exécutez cette commande dans la Device Console :

system ipsec_route add net 192.168.3.0/255.255.255.0 tunnelname HO_to_Branch

Pour net, SFOS attend le masque complet en notation décimale pointée. Utilisez la plage de destination la plus restreinte dont l’application a besoin. La commande de restauration correspondante est :

system ipsec_route del net 192.168.3.0/255.255.255.0

La commande de suppression ne contient pas de nom de tunnel. Avant de supprimer la route, utilisez system ipsec_route show pour vérifier que la destination est sans ambiguïté. Ne supprimez jamais une entrée ambiguë sur la base d’une simple supposition.

Pour un seul hôte de destination, la console accepte la forme suivante :

system ipsec_route add host 10.33.46.69 tunnelname Azure_CH
system ipsec_route del host 10.33.46.69

Une route d’hôte est plus restrictive, mais elle n’est correcte que si cet hôte précis est la destination et si les sélecteurs de trafic correspondent.

2. Configurer le DNAT et le SNAT réflexif

  1. Sous Rules and policies > NAT rules > Add NAT rule > New NAT rule, créez une règle DNAT. Original source vaut 192.168.3.0/24, Translated source reste défini sur Original, Original destination vaut 192.168.2.1 et Translated destination vaut 172.16.16.10.
  2. Activez Create reflexive rule.
  3. Ouvrez la règle générée Reflexive_NAT#_<DNAT_rule_name>. Pour Translated source, sélectionnez un objet hôte IP contenant 192.168.2.1. Créez cet objet sous Hosts and services > IP host > Add. Dans cette règle réflexive, Sophos ne peut pas effectuer directement la traduction vers une interface.
  4. Vérifiez l’ordre, l’état et la journalisation des deux règles NAT ainsi que de la règle de pare-feu associée.

N’ajoutez pas de règle MASQ générale et n’autorisez pas en plus le serveur réel à traverser le tunnel avec son adresse non traduite. Comprendre le NAT sur Sophos Firewall explique la correspondance et l’ordre des règles.

Valider le chemin des données

Un tunnel vert et un ping ne prouvent ni la traduction NAT ni le bon fonctionnement du chemin de retour. Pour la validation, définissez un flux applicatif réel, par exemple une connexion TCP du client distant au service publié du serveur.

  1. Exécutez à nouveau system ipsec_route show. Le réseau de destination doit être associé une seule fois au tunnel prévu.
  2. Générez une connexion contrôlée de 192.168.3.0/24 vers 192.168.2.1 sur le service autorisé.
  3. Filtrez Log viewer par source, destination et ID de règle de pare-feu. Dans la vue détaillée, src_trans_ip indique l’adresse source réellement traduite avec davantage de fiabilité que la vue récapitulative.
  4. Ouvrez Monitor & analyze > Diagnostics > Packet capture et filtrez sur le client, l’adresse de substitution et le serveur réel. L’ID de règle et l’ID NAT doivent correspondre aux règles documentées ; les interfaces d’entrée et de sortie doivent indiquer le chemin prévu.
  5. Sur le pair distant, vérifiez que les réponses provenant de 192.168.2.1 sont attendues et renvoyées par le même tunnel.
  6. Testez un hôte ou un service voisin non autorisé. Ce test négatif doit toujours échouer et confirme que la route et les règles ne sont pas trop larges.

Une SA active ou des compteurs d’octets en hausse ne suffisent pas. Pour une analyse complète, consultez Dépanner un VPN IPsec sur Sophos Firewall ; pour analyser les règles et les captures, consultez Tester une règle de pare-feu avec Log Viewer, Policy Test et Packet Capture.

Annuler entièrement la modification

Commencez par mettre fin aux nouvelles sessions de test. Rétablissez séparément le DNAT et le SNAT réflexif dans leur état antérieur documenté ; une modification ultérieure de la règle DNAT ne supprime pas automatiquement la règle réflexive.

Supprimez ensuite uniquement la route nouvellement créée :

system ipsec_route del net 192.168.3.0/255.255.255.0
system ipsec_route show

Ne supprimez le nouvel objet hôte IP que lorsque Object usage n’indique plus aucune référence. Répétez ensuite le flux de contrôle initial et le test négatif. La priorité des routes consignée précédemment doit rester inchangée.

Si seule la route a été supprimée par erreur, la commande d’ajout enregistrée rétablit exactement l’entrée :

system ipsec_route add net 192.168.3.0/255.255.255.0 tunnelname HO_to_Branch

Isoler méthodiquement les erreurs courantes

La route existe, mais le trafic part vers le WAN

Vérifiez system ipsec_route show, la priorité des routes et les routes SD-WAN concurrentes. Sous SFOS 22, l’absence d’une entrée dans la table de routage WebAdmin ou dans la table 220 ne prouve pas que la route IPsec est absente. Dans la priorité des routes, vpn ne précède static que pour le trafic destiné à la zone WAN ; vérifiez donc également les zones et le chemin réel vers la destination.

Le tunnel est actif, mais le NAT ne s’applique pas

Comparez les adresses d’origine et traduites aux sélecteurs de trafic. Pour un SNAT basé sur des politiques, Outbound interface doit être défini sur Any. Vérifiez ensuite l’ID de règle de pare-feu, l’ID NAT et src_trans_ip, au lieu de vous fier uniquement à l’état du tunnel.

Avec Any, le pare-feu utilise la Translated source de la règle SNAT correspondante, même lorsque Override source translation (SNAT) est activé pour des interfaces de sortie spécifiques. Une règle qui ne mentionne que certains ports WAN dans Outbound interface, notamment la règle SNAT par défaut habituelle, ne correspond pas à ce trafic IPsec basé sur des politiques. L’explication du NAT dans l’article sur l’IPsec site à site précise cette interaction ; elle ne justifie pas une modification généralisée des options de substitution. Après une correction ciblée de la règle, générez un nouveau flux applicatif contrôlé et vérifiez à nouveau l’ID NAT, src_trans_ip, les sélecteurs et le chemin de retour, comme indiqué dans la validation du chemin des données ci-dessus.

Le chemin aller fonctionne, mais la réponse n’arrive pas

Le pair distant doit connaître l’adresse traduite et renvoyer le trafic par le même tunnel. Vérifiez son sélecteur, sa règle de pare-feu et sa route de retour. Une route locale ipsec_route plus large ne peut pas corriger un chemin de retour différent.

Le trafic généré par le système ou DHCP est affecté

Les requêtes d’authentification, DNS et DHCP générées par le pare-feu suivent un traitement distinct. Sous SFOS 22, elles ne nécessitent normalement pas de route IPsec manuelle. Utilisez Routage SD-WAN des paquets de réponse et du trafic système ou le guide distinct consacré au relais DHCP au lieu d’appliquer cette procédure de transfert.

Une annonce dynamique manque après la mise à niveau vers SFOS 22

Sous SFOS 22, les routes VPN basées sur des politiques ne sont pas des routes ordinaires du noyau. Si OSPF ou BGP les annonçait auparavant via redistribute kernel, Pourquoi redistribute kernel n’annonce plus les routes IPsec après une mise à niveau vers SFOS 22 explique ce problème de migration distinct.