Acheminer Internet d'une agence via le siège par IPsec

Lorsque le trafic Internet d’une agence doit être inspecté de manière centralisée et sortir par la connexion WAN du siège, Sophos Firewall peut utiliser un tunnel IPsec Site-to-Site policy-based. Les clients de l’agence envoient alors leur trafic par le tunnel plutôt que directement vers le WAN local. Les règles centrales de pare-feu, NAT et sécurité s’appliquent au siège.

LAN agence → Pare-feu agence → IPsec policy-based → Siège → MASQ → Internet

Cette architecture exige davantage qu’un tunnel VPN vert. Route Precedence, Traffic Selectors, l’ordre des règles et le chemin de retour doivent fonctionner ensemble. Si le tunnel ou le siège tombe en panne, l’agence ne dispose normalement d’aucune sortie Internet locale automatique dans cette architecture.

⚠️ Cette procédure concerne uniquement IPsec policy-based. Le peer ne doit pas être route-based. Pour une nouvelle architecture ou un réseau en croissance, utiliser route-based Any-to-Any : les deux peers utilisent des sélecteurs Any, chacun reçoit une interface XFRM et des routes Static, SD-WAN ou dynamiques explicites sont nécessaires. Ne pas mélanger ces étapes avec la procédure policy-based ci-dessous. Le choix est expliqué dans Configurer un VPN IPsec Site-to-Site.

Exemple et prérequis

L’exemple utilise le réseau d’agence 10.20.0.0/24. Le siège dispose d’une connexion WAN fonctionnelle et d’un tunnel policy-based déjà planifié. 10.20.0.0/24 est une valeur de documentation à remplacer par le véritable réseau d’agence.

Paramètre	Siège	Agence
Local subnet	`Any`	`10.20.0.0/24`
Remote subnet	`10.20.0.0/24`	`Any`
Gateway type	`Respond only`	`Initiate the connection`

Pour cette architecture, la Route Precedence globale doit être VPN, Static, SD-WAN. Avant de la modifier, enregistrer la valeur actuelle et identifier tous les autres chemins Static, VPN et SD-WAN concernés. La procédure contrôlée est décrite dans Modifier Route Precedence en toute sécurité.

La valeur par défaut de SFOS 22 est Static, SD-WAN, VPN. Cette architecture diffère parce que Remote subnet: Any crée dans l’agence une route VPN policy-based automatique pour toutes les destinations. Ne pas supprimer la route par défaut Static 0.0.0.0/0 vers le WAN local : elle reste disponible pour le trafic généré par le pare-feu lorsque l’usage du VPN est désactivé et pour un rollback contrôlé. Lire la valeur actuelle dans Device Console avec system route_precedence show ; l’article dédié fournit la commande de modification, l’analyse d’impact et le retour arrière.

Les éléments suivants doivent également être prêts avant le changement :

un tunnel IPsec policy-based fonctionnel entre les deux pare-feu ;
un accès administratif testé aux deux sites ;
une capacité Internet et pare-feu suffisante au siège ;
DNS, Web Policies, IPS, Application Control et les exceptions voulues ;
une sauvegarde actuelle de la configuration et un relevé du changement contenant les sélecteurs d’origine, Route Precedence, l’option de trafic système ainsi que les ID de pare-feu et de NAT ;
un chemin de retour documenté et une fenêtre de maintenance.

En HA, relever avant le changement le nœud actif, le bon état du cluster et l’accès d’administration au peer sur chaque site. HA ne remplace ni un second WAN du siège ni un second site. Le failover est un test distinct et ne se déduit pas d’un tunnel vert.

Définir les sélecteurs IPsec

Au siège, définir Local subnet sur Any et Remote subnet sur le LAN de l’agence. Dans l’agence, utiliser les valeurs inverses : le réseau local de l’agence et Any comme réseau distant.

Tester ensuite le tunnel avec une destination interne du siège. N’activer le chemin Internet qu’une fois le trafic intersite fonctionnel dans les deux sens. Un problème IPsec reste ainsi distinct d’un défaut NAT ou de règle.

Créer les règles de pare-feu et NAT

Créer les règles sous Rules and policies > Firewall rules. Les règles VPN générées automatiquement ne constituent pas une architecture complète pour ce chemin Internet.

Siège : VPN vers WAN

Une règle Branch_VPN_to_WAN autorise le trafic de l’agence vers Internet :

Action : Accept
Source zones : VPN
Source networks : 10.20.0.0/24
Destination zones : WAN
Destination networks : Any
Services : uniquement les services réellement nécessaires
Log firewall traffic : activé
Create linked NAT rule > Translated source (SNAT) : MASQ

Sélectionner consciemment Web Policy, IPS, Application Control et TLS Inspection. La règle MASQ associée traduit les clients de l’agence vers l’adresse publique du siège. Pour le trafic sortant, SFOS évalue la règle de pare-feu avant SNAT ; vérifier donc aussi l’ordre NAT, car une règle NAT antérieure correspondante prévaut. NAT ne crée pas non plus de route et une modification NAT ne concerne que les nouvelles connexions.

Le chemin de retour comporte deux parties : MASQ ramène les réponses Internet à l’adresse WAN du siège ; le siège utilise ensuite sa route VPN policy-based automatique vers la destination retraduite 10.20.0.0/24. Si le LAN de l’agence se trouve derrière un autre routeur, documenter et tester également ses chemins aller et retour.

Agence : autoriser LAN vers VPN

La règle Branch_LAN_to_VPN se place au-dessus de toute règle locale autorisant LAN vers WAN :

Action : Accept
Source zones : LAN
Source networks : 10.20.0.0/24
Destination zones : VPN
Destination networks : Any
Services : uniquement les services réellement nécessaires
Log firewall traffic : activé

Ajouter ensuite une règle ciblée Branch_LAN_to_WAN_drop pour le même réseau d’agence, de LAN vers WAN. Elle empêche une règle Internet locale trop large de contourner le tunnel planifié. Ne pas inclure accidentellement d’autres réseaux ou services locaux explicitement nécessaires.

L’ordre participe à la sécurité : exceptions spécifiques, Branch_LAN_to_VPN, puis Branch_LAN_to_WAN_drop, et enfin les règles plus larges. Après une modification, valider avec de nouvelles connexions client, pas uniquement avec des sessions existantes.

Créer des règles de pare-feu en toute sécurité explique comment vérifier ensemble position, Rule ID et règle NAT associée.

Décider séparément du trafic généré par le système

Les règles précédentes contrôlent le trafic client transféré. DNS, NTP, mises à jour, Central et les autres connexions générées par le pare-feu de l’agence sont du trafic généré par le système.

DNS doit aussi être séparé selon son origine. Un client utilisant un résolveur public suit le chemin client dans le tunnel. Un résolveur interne au siège exige un sélecteur, une règle et un chemin de retour adaptés. Seules les requêtes DNS générées par le pare-feu suivent l’option de trafic système ci-dessous. C’est pourquoi une IP publique et un FQDN sont testés séparément.

La valeur par défaut est enable. Comme un système existant peut utiliser une autre valeur, commencer par afficher l’état actuel avec cette commande en lecture seule de Device Console :

show routing policy-based-ipsec-vpn system-generate-traffic

Si seul le trafic client doit passer par le siège, le trafic généré par le pare-feu peut sortir directement par le WAN de l’agence :

set routing policy-based-ipsec-vpn system-generate-traffic disable

⚠️ Cette modification redémarre tous les tunnels IPsec du pare-feu. Documenter auparavant l’état, la fenêtre de maintenance et le chemin de récupération. Ne pas exécuter la commande pour un simple test ou sur la base d’un soupçon.

Lors du rollback, rétablir l’état précédent documenté. Si l’option était auparavant activée, utiliser :

set routing policy-based-ipsec-vpn system-generate-traffic enable

Après chaque modification, tester à nouveau toutes les connexions IPsec et les services nécessaires du pare-feu.

Valider le chemin de données

Un client de 10.20.0.0/24 ouvre d’abord une adresse IP publique, puis un FQDN via HTTPS. La validation couvre plusieurs couches :

Branch_LAN_to_VPN correspond dans l’agence ; la règle locale de rejet LAN-to-WAN ne correspond pas à ce flux réussi.
Branch_VPN_to_WAN et la règle MASQ associée correspondent au siège.
L’adresse IP source visible publiquement appartient au siège.
DNS, HTTPS et une destination volontairement bloquée se comportent conformément à la policy centrale.
Sous Diagnostics > Packet capture, In interface, Out interface, Rule ID, NAT ID, Status et Reason montrent les paquets aller et retour par le tunnel et le WAN du siège.
Le trafic généré par le système utilise le chemin local ou central défini auparavant.
Current activities > IPsec connections reste établi durant le test et le Log viewer ne montre aucun rejet inattendu.
En HA, effectuer séparément un failover de nœud approuvé et répéter tout le test. Sans ce test, ne pas affirmer la redondance HA.

Un Speedtest seul ne suffit pas. Tester également des applications réelles, DNS, les journaux de sécurité et un téléchargement prolongé. Pour les problèmes de performances, utiliser les procédures distinctes de test de débit Internet et de MTU et MSS dans le VPN.

Erreurs typiques et rollback

Le client de l’agence utilise encore le WAN local : vérifier l’ordre des règles, le réseau source, la règle LAN-to-VPN et la règle de rejet. Ne pas ajouter une exception large comme solution rapide.
Le tunnel est vert, mais Internet ne fonctionne pas : au siège, vérifier la règle VPN-to-WAN, Rule ID, MASQ, la passerelle WAN, DNS et le chemin de retour.
Seul le pare-feu utilise le mauvais chemin : vérifier policy-based-ipsec-vpn system-generate-traffic. Ne pas confondre trafic client et trafic généré par le système.
D’autres tunnels tombent après la modification CLI : le redémarrage de tous les tunnels IPsec est un comportement documenté. Rétablir l’état précédent et valider chaque tunnel séparément.
Le tunnel ou le siège tombe en panne : l’architecture standard ne fournit pas de sortie Internet locale. Un tel fallback nécessite un chemin de sécurité et de routage séparé, planifié consciemment.
Une IP publique fonctionne, mais pas un FQDN : vérifier l’adresse DNS du client, la règle DNS, le chemin du résolveur central et les réponses. L’option de trafic système ne compte que si le pare-feu génère la requête.

Pour le rollback, préparer d’abord, au-dessus de Branch_LAN_to_WAN_drop, une règle LAN-to-WAN temporaire limitée à un seul client de test. Rétablir ensuite Route Precedence à la valeur enregistrée et vérifier le chemin WAN local avec une nouvelle session de ce client. Si le test échoue, rétablir immédiatement la précédence et l’état des règles du full tunnel via un accès d’administration indépendant. Ce n’est qu’après un test concluant qu’il faut activer l’ancienne règle LAN-to-WAN normale, désactiver Branch_LAN_to_WAN_drop et supprimer la règle temporaire.

Rétablir ensuite l’option de trafic système à sa valeur précédente et, puisque cette opération redémarre les tunnels, vérifier toutes les connexions IPsec. Ne désactiver ou supprimer Branch_LAN_to_VPN, VPN-to-WAN et MASQ que lorsque Rule ID, NAT ID et l’usage confirment qu’aucun autre flux n’en dépend. Enfin, rétablir les sélecteurs IPsec d’origine ou supprimer le tunnel créé uniquement pour ce chemin. Conserver la sauvegarde de configuration et l’accès d’administration indépendant jusqu’à la réussite de nouvelles sessions DNS, HTTPS et applicatives sur les deux sites.

FAQ

Le trafic généré par le pare-feu de l'agence doit-il aussi passer par le siège ?

Non. Il s’agit d’une décision distincte. L’option CLI peut désactiver les routes VPN policy-based pour ce trafic, mais redémarre alors tous les tunnels IPsec.

Cette architecture assure-t-elle automatiquement un failover Internet local dans l'agence ?

Non. La règle de rejet LAN-to-WAN bloque volontairement le chemin local. Un fallback nécessite des critères, règles, policies de sécurité et tests contrôlés distincts.