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 IPsec policy-based. Pour une nouvelle architecture ou un réseau en croissance, route-based Any-to-Any avec XFRM et un routage explicite est souvent plus flexible. 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é.

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 ;
un chemin de retour documenté et une fenêtre de maintenance.

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. Sans chemin de retour et NAT corrects, le tunnel peut être vert alors que les connexions Internet ne reçoivent aucune réponse.

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
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.

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.

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.
Packet Capture montre 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.

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.

Pour le rollback, désactiver d’abord Branch_LAN_to_WAN_drop et rétablir de manière contrôlée le chemin Internet local précédemment autorisé. Supprimer ensuite les règles VPN-to-WAN et MASQ uniquement si aucun autre flux ne les utilise. Rétablir exactement Route Precedence et l’option du trafic système à leurs valeurs documentées, puis tester de nouveau 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.