Transférer une IP virtuelle via IPsec vers plusieurs serveurs
Une IP virtuelle peut pointer vers plusieurs serveurs internes via un tunnel IPsec basé sur des routes existant. Le site distant utilise une seule adresse de destination stable. Sophos Firewall route le trafic par l’interface XFRM, puis traduit l’adresse virtuelle vers une liste de serveurs au moyen d’une règle DNAT.
Il ne s’agit pas d’un DNAT Internet ordinaire : le tunnel, les adresses XFRM, les routes SD-WAN, les règles VPN et le NAT doivent fonctionner comme un seul chemin sur les deux pare-feu.
Procédure rapide
- Valider un tunnel basé sur des routes Any-to-Any avec des interfaces XFRM adressées sur les deux pare-feu.
- Créer une gateway pour chaque adresse XFRM du pair.
- Configurer des routes SD-WAN symétriques pour le réseau distant, les réseaux locaux et l’IP virtuelle.
- Créer des règles de pare-feu restrictives pour la source distante, l’IP virtuelle et le service nécessaire.
- Côté serveurs, créer une règle DNAT de l’IP virtuelle vers une liste de serveurs avec Round-robin.
- Vérifier plusieurs nouvelles connexions avec Log Viewer, les Rule IDs, la NAT Rule ID et Packet Capture.
⚠️ Une connexion IPsec verte ou une gateway XFRM active ne prouve pas encore le fonctionnement du DNAT et du chemin de retour. Avant le changement en production, le flux applicatif réel doit pouvoir être suivi dans les deux sens.
Quand ce design convient
Cette procédure convient lorsque des hôtes d’un site distant doivent atteindre un service interne via une adresse virtuelle fixe, tandis que les adresses réelles des serveurs restent masquées. Une liste de serveurs peut par exemple répartir les nouvelles connexions entre deux serveurs applicatifs équivalents.
Pour une connexion directe unique vers un serveur connu, une route normale et une règle de pare-feu suffisent généralement. Si un service doit être publié sur Internet, il faut plutôt utiliser la procédure DNAT ou WAF classique. La planification générale du tunnel est présentée dans Configurer un VPN IPsec site à site.
Ce design ne convient pas à un tunnel IPsec basé sur des politiques ni à un tunnel basé sur des routes avec des Traffic Selectors précis. Le chemin décrit ici nécessite un tunnel basé sur des routes avec Any comme réseaux local et distant, des interfaces XFRM adressées et un routage explicite.
Exemple de topologie
Dans cet exemple, les clients de 192.168.3.0/24 accèdent à l’adresse virtuelle 10.10.10.1. Les serveurs 172.16.16.2 et 172.16.16.3 se trouvent derrière Firewall 1. Les adresses de transfert XFRM sont 10.255.255.1/30 et 10.255.255.2/30.
Remote clients Route-based IPsec Server site
192.168.3.0/24 → xfrm2 10.255.255.2 ⇄ 10.255.255.1 xfrm1 → VIP 10.10.10.1
│ DNAT
┌───────────────┴───────────────┐
172.16.16.2 172.16.16.3
Toutes les adresses sont des exemples et doivent être remplacées par les réseaux réels. Les adresses XFRM doivent constituer un réseau de transfert dédié qui n’est utilisé nulle part ailleurs. L’IP virtuelle ne doit entrer en conflit avec aucun hôte réel, aucune interface, aucun réseau VPN ni aucune autre publication NAT.
Préparer le tunnel et XFRM
Tunnel Any-to-Any et adresses de transfert
Sur Firewall 1, créer le tunnel en mode Route-based (Tunnel interface) avec Respond only ; sur Firewall 2, utiliser Initiate the connection. Des deux côtés, définir Local subnet et Remote subnet sur Any.
Attribuer ensuite les adresses de transfert aux interfaces XFRM sous Network > Interfaces :
- Firewall 1,
xfrm1:10.255.255.1/30 - Firewall 2,
xfrm2:10.255.255.2/30
Les paramètres de Phase 1 et Phase 2, les IDs et l’authentification doivent déjà avoir été validés. Ne pas modifier les adresses XFRM d’un tunnel de production non testé.
Créer les gateways XFRM
Chaque pare-feu a besoin d’une gateway vers l’adresse XFRM du pair pour les routes SD-WAN :
- Firewall 1 : Gateway IP
10.255.255.2viaxfrm1 - Firewall 2 : Gateway IP
10.255.255.1viaxfrm2
L’état de la gateway vérifie uniquement le Monitoring Target sélectionné. Créer et valider une Custom Gateway explique en détail l’objet, le Health Check et le test fonctionnel.
Construire les règles et les routes SD-WAN
Firewall 1 sur le site des serveurs
La règle de pare-feu entrante autorise uniquement le flux prévu :
- Source zone :
VPN - Source networks and devices :
192.168.3.0/24 - Destination zone :
Any, comme dans l’exemple Sophos pour l’adresse virtuelle - Destination networks :
10.10.10.1et d’autres réseaux locaux uniquement si nécessaire - Services : uniquement le service applicatif, par exemple
HTTPS - Log firewall traffic : activé
Any dans Destination zone ne justifie pas des sources, destinations ou services larges. L’IP virtuelle n’est pas attribuée à une interface normale. Il faut donc confirmer la Rule ID avec du trafic réel.
La route SD-WAN de Firewall 1 envoie le trafic de retour vers le réseau distant via la gateway XFRM. Dans Source networks, saisir les réseaux locaux réellement nécessaires ainsi que 10.10.10.1 ; dans Destination networks, saisir 192.168.3.0/24.
Firewall 2 sur le site distant
La règle sortante utilise LAN comme Source zone et VPN comme Destination zone. La source est 192.168.3.0/24, la destination comprend au minimum 10.10.10.1, le service correspond à l’application et la journalisation reste activée pendant la mise en service.
La route SD-WAN de Firewall 2 envoie le trafic de 192.168.3.0/24 vers 10.10.10.1 via la gateway XFRM. Route only through specified gateways évite un chemin de remplacement par une autre route lorsque le service doit uniquement être accessible via ce tunnel.
Le choix de cette option fait partie du plan de panne. Sans elle, une autre route peut prendre le relais ; avec elle, SFOS abandonne le trafic si la gateway indiquée n’est pas disponible. Créer et tester une route SD-WAN décrit la configuration complète.
Traduire l’IP virtuelle vers la liste de serveurs avec DNAT
Sur Firewall 1, créer une règle ciblée sous Rules and policies > NAT rules > Add NAT rule > New NAT rule :
- Original source :
192.168.3.0/24 - Translated source :
Original - Original destination :
10.10.10.1 - Original service : le service applicatif réel, par exemple
HTTPS - Translated destination : l’objet de liste de serveurs contenant
172.16.16.2et172.16.16.3 - Translated service :
Original - Load balancing method :
Round-robin
Le DNAT n’autorise aucun trafic à lui seul. La règle de pare-feu, la route SD-WAN et le chemin de retour restent des conditions distinctes. Comprendre le NAT sur Sophos Firewall explique les valeurs originales et traduites ainsi que l’ordre des règles.
Round-robin répartit les nouvelles connexions correspondantes entre les membres de la liste de serveurs. Un canal de navigateur ou d’application réutilisé ne constitue donc pas un test de répartition valable. La méthode de sélection ne prouve pas non plus automatiquement le bon fonctionnement de l’application sur chaque backend. Tester les deux serveurs séparément avec de nouvelles sessions.
Valider le chemin complet
Avant le test, documenter l’état du tunnel, les adresses XFRM, l’état des gateways, la position des routes SD-WAN et les Rule IDs. Créer ensuite plusieurs nouvelles connexions applicatives du réseau distant vers l’IP virtuelle.
Dans Log Viewer, la source 192.168.3.0/24, la destination 10.10.10.1, la Firewall Rule ID attendue et la NAT Rule ID doivent être visibles. Le Traffic Count de la route SD-WAN doit augmenter. Un Packet Capture restrictif montre si les paquets arrivent sur l’interface XFRM, sont transmis au serveur sélectionné après le DNAT et reviennent par le même tunnel.
Répéter le test avec les deux backends. Sur les serveurs, vérifier l’adresse client attendue, le service et le chemin de retour. Un ping vers l’IP virtuelle ne remplace pas un véritable test HTTPS, SAP ou d’une autre application.
Tester une règle de pare-feu avec Log Viewer et Packet Capture facilite la vérification combinée de la règle, du NAT et du chemin des paquets.
Délimiter les erreurs systématiquement
Le tunnel est vert, mais l’IP virtuelle ne répond pas
Vérifier d’abord la route SD-WAN sur Firewall 2 : la source, la destination, le service et la gateway XFRM correspondent-ils ? Contrôler ensuite la Rule ID et la NAT Rule ID sur Firewall 1. Si la NAT Rule ID manque, Original source, Original destination, le service ou la position de la règle ne correspondent pas.
Le DNAT correspond, mais le serveur ne répond pas
Vérifier l’objet de liste de serveurs, le service local et la gateway du serveur. Le chemin de retour doit passer par Firewall 1 afin que la session NAT existante retraduise la réponse vers 10.10.10.1. Ne pas ajouter une règle MASQ large comme raccourci, car elle peut fausser le diagnostic.
Un seul serveur reçoit des connexions
Utiliser plusieurs sessions réellement nouvelles et fermer les connexions Keep-alive existantes. Comparer ensuite la liste de serveurs, Load balancing method et la NAT Rule ID. Si un backend ne fonctionne pas directement, réparer d’abord son service ou son chemin local.
Le trafic emprunte une autre route
Vérifier la position et le Traffic Count des routes SD-WAN ainsi que les gateways XFRM sélectionnées. Policy Tester ne tient pas entièrement compte des routes SD-WAN ; utiliser ensemble Log Viewer, Route lookup et Packet Capture.
Effectuer un rollback sûr
Avant la modification, documenter le backup de configuration, l’état du tunnel, les adresses XFRM, les objets de gateway, les règles et les routes. Si le nouveau chemin ne fonctionne pas :
- Désactiver la nouvelle règle DNAT.
- Désactiver les deux nouvelles routes SD-WAN.
- Rétablir les règles de pare-feu spécifiques dans leur état antérieur.
- Supprimer les gateways XFRM et les adresses de transfert uniquement si aucune autre route ne les utilise.
- Tester à nouveau le tunnel et le flux applicatif d’origine.
Ne pas supprimer une gateway ou une interface XFRM tant que Object usage indique encore des dépendances. Backup et restauration de Sophos Firewall explique le processus sûr de sauvegarde et de récupération.