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 choisies, les règles VPN et le NAT doivent fonctionner comme un seul chemin sur les deux pare-feu.

Procédure rapide

1. Valider un tunnel basé sur des routes Any-to-Any avec des interfaces XFRM adressées sur les deux pare-feu.
2. Si SD-WAN est utilisé, créer sur chaque pare-feu une gateway vers l’adresse XFRM du pair.
3. Router VIP-App (198.51.100.10/32) et le réseau client vers XFRM par des routes statiques, dynamiques ou SD-WAN selon l’architecture existante.
4. Créer des règles de pare-feu restrictives pour la source distante, l’IP virtuelle et le service nécessaire.
5. Côté serveurs, créer une règle DNAT de l’IP virtuelle vers une liste de serveurs avec Round-robin.
6. 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. Créer d’abord un backup de configuration et consigner l’état initial. 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.

Cette procédure précise 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. Un tunnel basé sur des routes avec des Traffic Selectors peut atteindre le même objectif, mais SFOS crée alors les routes à partir des sélecteurs ; les étapes de gateway XFRM ne s’appliquent donc pas sans adaptation. Cette procédure ne s’applique pas à IPsec basé sur des politiques.

Exemple de topologie

Dans cet exemple, les clients de 192.0.2.0/24 accèdent à l’adresse virtuelle 198.51.100.10. Les serveurs 10.0.20.21 et 10.0.20.22 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.0.2.0/24  →  xfrm2 10.255.255.2  ⇄  10.255.255.1 xfrm1  →  VIP 198.51.100.10
                                                                        │ DNAT
                                                        ┌───────────────┴───────────────┐
                                                        10.0.20.21           10.0.20.22

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.

L’exemple conserve les adresses client avec Translated source (SNAT): Original. Les deux backends doivent donc disposer d’un chemin de retour vers 192.0.2.0/24 via le pare-feu des serveurs. Si cela est impossible, un SNAT planifié peut être nécessaire ; il masque l’adresse client et ne constitue pas une correction générale d’un routage erroné.

192.0.2.0/24 et 198.51.100.0/24 sont des réseaux de documentation ; 10.0.20.0/24 est le réseau de serveurs de l’exemple.

Conserver l’état initial

Avant toute modification, créer un backup de configuration et consigner l’état IPsec, les adresses XFRM, l’ordre du routage et de SD-WAN, les Rule IDs du pare-feu et du NAT, les compteurs existants et les gateways par défaut des backends. Ne pas utiliser les sessions déjà établies comme test.

Créer les objets IP

Sur le pare-feu des serveurs, ouvrir Hosts and services > IP host > Add. Créer VIP-App avec IP version IPv4, Type IP et l’adresse virtuelle, puis Remote-Clients avec Type Network. Créer enfin App-Backends avec Type IP list et les adresses des serveurs séparées par des virgules. SFOS 22 accepte jusqu’à 800 adresses dans une IP list, qui ne peut pas appartenir à un IP host group. La liste est utilisée directement comme Translated destination (DNAT).

Les valeurs concrètes des objets de l’exemple sont :

• VIP-App: IP version IPv4, Type IP, IP address 198.51.100.10.
• Remote-Clients: Type Network, IP address 192.0.2.0, Subnet /24.
• App-Backends: IP version IPv4, Type IP list, IP addresses 10.0.20.21,10.0.20.22.

Définir les routes du tunnel

Les routes SD-WAN suivantes ne sont nécessaires que si SD-WAN est déjà la méthode de routage choisie. Un tunnel Any-to-Any peut aussi utiliser des routes statiques ou dynamiques : côté clients, router VIP-App (198.51.100.10/32) vers XFRM ; côté serveurs, router Remote-Clients vers XFRM. Ne pas déduire ni dupliquer des routes sans vérifier la route precedence existante.

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

Si SD-WAN est déjà le standard de routage

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.2 via xfrm1
• Firewall 2 : Gateway IP 10.255.255.1 via xfrm2

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.

La route SD-WAN de Firewall 2 envoie le trafic de 192.0.2.0/24 vers 198.51.100.10 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.

Firewall 1 doit disposer d’une route effective vers 192.0.2.0/24 via XFRM. Ne pas supposer qu’une route SD-WAN symétrique traite les réponses : les routes SD-WAN ne s’appliquent aux reply packets que si set routing sd-wan-policy-route reply-packet enable est activé. Vérifier ce réglage global ou utiliser le routage statique ou dynamique existant.

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 :

• Rule name: DNAT-VPN-VIP-App
• Rule position: au-dessus des règles NAT plus larges susceptibles de correspondre
• Original source : 192.0.2.0/24
• Translated source : Original
• Original destination : 198.51.100.10
• Original service : le service applicatif réel, par exemple HTTPS
• Translated destination : l’objet de liste de serveurs contenant 10.0.20.21 et 10.0.20.22
• Translated service : Original
• Inbound interface / Outbound interface : Any (obligatoire pour le trafic VPN dans les champs NAT)
• Load balancing method : Round robin
• Health check : activé, Probe method TCP, Port 443

Le DNAT n’autorise aucun trafic à lui seul. La règle de pare-feu, la route de tunnel choisie 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.

Round robin envoie les nouvelles requêtes séquentiellement. Sans Health check, SFOS considère tous les membres disponibles et peut choisir un serveur en panne. Définir Probe interval, Response time-out et Deactivate host after ; un probe TCP ne remplace pas un contrôle applicatif. Le NAT ne s’applique qu’au premier paquet : une modification ne déplace pas les sessions établies et doit être testée avec de nouvelles connexions.

Créer la règle de pare-feu correspondante

La règle sortante utilise LAN comme Source zone et VPN comme Destination zone. La source est 192.0.2.0/24, la destination est 198.51.100.10, le service correspond à l’application et la journalisation reste activée pendant la mise en service.

La règle de pare-feu entrante autorise uniquement le flux prévu :

• Rule name: Allow-VPN-VIP-App
• Rule position: au-dessus des règles qui se chevauchent
• Action: Accept
• Source zone : VPN
• Source networks and devices : 192.0.2.0/24
• Destination zone : zone des backends traduits, LAN dans cet exemple
• Destination networks : uniquement 198.51.100.10
• Services : uniquement le service applicatif, par exemple HTTPS
• Log firewall traffic : activé

SFOS recherche d’abord le DNAT, puis utilise la zone de la destination traduite pour la règle de pare-feu. Destination networks reste la VIP originale. Contrôler la position et la Rule ID avec du trafic réel.

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, confirmer la source, la Firewall Rule ID attendue et la NAT Rule ID. Comparer la VIP avant NAT et le backend traduit avec un Packet Capture restrictif ; ne pas déduire la traduction d’un champ de destination ambigu. La capture montre aussi l’entrée sur XFRM et le retour via le même pare-feu.

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

Aucune NAT Rule ID

Vérifier Original source, VIP-App, HTTPS et la position de la règle NAT. Vérifier aussi qu’aucune règle NAT antérieure ne correspond en premier. Créer une nouvelle connexion après une correction, car les sessions établies ne sont pas réévaluées par le NAT.

Le DNAT correspond, mais pas la règle de pare-feu

Les Destination zones doivent correspondre à la zone des adresses backend traduites, et non à la VIP ni, de manière générique, à VPN. Destination networks reste VIP-App. Vérifier ensuite à nouveau la Rule ID et l’événement de rejet dans Log Viewer.

Un backend reste inaccessible

Comparer l’état du Health Check, la méthode de probe et le port au service réel. Sans Health Check, SFOS peut sélectionner un membre en panne. Même un probe TCP réussi ne valide pas l’application, TLS ou l’autorisation ; tester le backend directement sur le réseau des serveurs, puis via une nouvelle session VIP.

La réponse emprunte le mauvais chemin

Vérifier la gateway par défaut ou la route spécifique du backend, la route vers Remote-Clients et Packet Capture sur le pare-feu des serveurs. Ne pas ajouter une règle MASQ large comme raccourci de diagnostic. Avec SD-WAN, vérifier aussi la position, la route precedence, le monitoring et Route only through specified gateways.

Effectuer un rollback sûr

Commencer par désactiver le DNAT pour bloquer les nouvelles sessions, puis laisser expirer ou terminer les sessions existantes pendant la fenêtre de maintenance. Les changements NAT ne sont pas réévalués pour une connexion établie. Désactiver ensuite uniquement les règles et routes créées pour ce chemin et rétablir leur ordre documenté.

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 :

1. Désactiver la nouvelle règle DNAT.
2. Désactiver uniquement les routes statiques ou SD-WAN créées pour ce chemin.
3. Rétablir les règles de pare-feu spécifiques dans leur état antérieur.
4. Supprimer uniquement les nouvelles gateways et retirer uniquement les adresses XFRM nouvellement attribuées lorsqu’il n’existe aucune dépendance.
5. Tester à nouveau le tunnel et le flux applicatif d’origine.

Ne pas supprimer une gateway tant que Object usage indique encore des dépendances. L’interface XFRM est créée par le tunnel ; ne pas supprimer un tunnel existant qui transporte d’autres réseaux. Backup et restauration de Sophos Firewall explique le processus sûr de sauvegarde et de récupération.

FAQ