Zyxel Firewall [Routage VPN] - Acheminement du trafic du tunnel VPN vers un autre site VPN [Routage VPN].

Cet article explique comment acheminer le trafic d'un tunnel site à site vers un autre tunnel afin d'atteindre les périphériques situés derrière une connexion site à site. Il explique comment router le trafic du site A vers le site B à travers le pare-feu / la passerelle du QG (route site-à-site à travers le tunnel site-à-site), comment résoudre les problèmes, les règles de routage si vous voulez que vos VPNs clients atteignent un serveur qui est situé sur un autre site (client-à-site à travers site-à-site), la configuration IPSec de SecuExtender.

Alternative 1 : Routage du trafic du tunnel VPN distant vers un autre VPN site à site

1) Configuration des tunnels VPN

Conditions préalables : Une connexion site à site entre les deux sites doit déjà être établie.

Une fois le tunnel établi, nous le connecterons en utilisant L2TP sur IPSec.

Pour obtenir des instructions sur la mise en place d'un VPN, veuillez vous référer à :

VPN - Configurer un VPN IPSec de site à site

Vous trouverez des informations sur L2TP over IPSec :

VPN - Configurer L2TP sur IPSec VPN utilisant PSK [Mode autonome]

Pour simplifier le processus, vous pouvez utiliser l'assistant de création d'un tunnel VPN et L2TP over IPSec.

2) Configuration des politiques de routage

Pour permettre le trafic entre le siège principal (HQ) et le site B, vous devez configurer des politiques et des routes pour le tunnel VPN.

Sur le pare-feu du QG :

1. Créez une route de stratégie qui achemine les demandes entrantes du tunnel L2TP vers le tunnel du site B. Il s'agit de l'acheminement des requêtes entrantes du tunnel L2TP vers le tunnel du site B via le pare-feu du QG.

   • Source : Sous-réseau du client L2TP
   • Destination : Sous-réseau du site B
   • Saut suivant : tunnel VPN "tunnel du site B".

Notez que l'adresse de destination est l'adresse de notre client.

2. Créez une politique qui autorise les réponses du site B et les achemine dans le tunnel vers le site B. Ceci est crucial pour le trafic revenant du site B vers le QG.

• • Source : N'importe laquelle
  • Destination : Tunnel L2TP
  • Saut suivant : Tunnel VPN "Tunnel L2TP"

Sur le site B :

1. Créez également une route de stratégie qui autorise les requêtes entrantes du siège et les achemine dans le tunnel vers le site B. Créez également une route de stratégie qui autorise les réponses du siège et les achemine dans le tunnel vers le site B :

Assurez-vous que le routage asymétrique est activé pour une connectivité transparente. Vous trouverez cette option ici :

Configuration > Politique de sécurité > Contrôle des politiques

L'activation de cette fonctionnalité active la route "triangulaire", ce qui permet au pare-feu d'utiliser une topologie de route asymétrique dans le réseau et d'empêcher les réinitialisations de connexion lorsque les réponses reviennent.

En suivant ces étapes, vous pouvez acheminer efficacement le trafic entre vos tunnels VPN et maintenir une connexion fluide et sécurisée entre le siège et le site B.

Alternative 2 : Routage d'un tunnel VPN vers un autre site VPN

1) Acheminer le trafic du site A vers le site B via le site HQ

Pour que le site A puisse atteindre le site B et vice versa, vous devez créer des routes stratégiques sur chaque pare-feu afin que le pare-feu du siège sache où envoyer les requêtes entrantes et où envoyer les réponses.

1.1 Routes stratégiques - Pare-feu du siège

Sur le pare-feu du QG, vous devez d'abord configurer une règle qui autorise les requêtes provenant du site A et destinées au site B. Ces requêtes doivent être acheminées dans le tunnel vers le site B, ce qui est important à la fois pour les requêtes ICMP (provenant du site A) et pour les réponses ICMP (provenant du site B et retournant maintenant vers le site B).

Incoming : any - Source : "Site A subnet" -> Destination : "Site B subnet" - Next-hop Tunnel - "Site B VPN tunnel"

Deuxièmement, vous devez configurer une règle qui autorise les réponses provenant du site B et destinées au site A (lorsque vous avez envoyé une requête depuis le site A) et qui doivent être acheminées dans le tunnel du site A. Ceci est important à la fois pour les requêtes ICMP (venant du site B), mais aussi pour les réponses ICMP (venant du site B et retournant maintenant vers le site A).

Incoming : any - Source : "Site B subnet" -> Destination : "Site A subnet" - Next-hop Tunnel - "Site A VPN tunnel"

1.2 Routes de politique - Pare-feu du site A

Ensuite, vous devez configurer une règle qui autorise les requêtes provenant du site B et destinées au site A (lorsque vous avez envoyé une requête depuis le site B). Celles-ci doivent être routées"en arrière" dans le tunnel du Site A, et ceci est important à la fois pour les requêtes ICMP (venant du Site B), mais aussi pour les réponses ICMP (venant du Site B et qui retournent maintenant vers le Site B).

Incoming : any - Source : "Site B subnet" -> Destination : "Site A subnet" - Next-hop "Site A VPN tunnel"

1.3 Routes de politique - Pare-feu du site B

Ensuite, vous devez configurer une règle qui autorise les requêtes provenant du site A et destinées au site B (lorsque vous avez envoyé une requête depuis le site A). Celles-ci doivent être routées"en arrière" dans le tunnel du Site B, et ceci est important à la fois pour les requêtes ICMP (venant du Site A), mais aussi pour les réponses ICMP (venant du Site A et qui retournent maintenant vers le Site A).

Incoming : any - Source : "Site A subnet" -> Destination : "Site B subnet" - Next-hop "Site B VPN tunnel"

2) Vérification / Dépannage

Lorsque vous avez configuré toutes les routes de la politique, il est important de vérifier que le routage fonctionne réellement. Il se peut que vous ayez des routes conflictuelles dans vos règles de pare-feu (chevauchements de sous-réseaux, routes stratégiques/statiques existantes, etc.

Notez que cela peut être très déroutant car il y a de nombreuses routes dont vous devez vous occuper. La façon la plus simple de procéder consiste à tracer manuellement tous les flux de paquets sur une feuille de papier (PC -> passerelle A - la passerelle doit être acheminée vers le siège, le siège doit être acheminé vers le site B - le site B doit acheminer la réponse vers le siège à nouveau ... etc.

Vous trouverez ci-dessous deux scénarios dans lesquels vous devrez peut-être modifier des configurations pour que le routage fonctionne.

2.1 Test par ping du pare-feu

Le premier scénario consiste à tester un serveur ou un PC sur le site B à partir d'un PC sur le site A :

Flèche rouge - Requête ICMP [ping].

Flècheverte - Réponse ICMP [ping].

2.2mRoutes de politique - Pare-feu du site A

Si vous envoyez un ping à la passerelle du site B depuis la passerelle du site A (outil ICMP intégré), la politique de routage du site A ne s'appliquera pas aux réponses du site B, si le site B essaie d'envoyer un ping à la passerelle du site A.

Par conséquent, nous avons besoin d'une route de politique qui ressemble à ceci :

Entrant : ZyWall- Source : "Site B subnet" -> Destination : "Site A subnet" - Next-hop "Site A VPN tunnel"

2.3 Routes de politique - Pare-feu du site B

Le premier test que vous pouvez faire est d'envoyer un ping au pare-feu, cependant, comme le routage que vous venez de créer est UNIQUEMENT pour les appels entrants (à l'exclusion de Zywall), cela signifie que le routage ne s'appliquera pas si le ping vient du site A, atteint le pare-feu du site B et que le pare-feu est responsable de la réponse à cette requête. La réponse ICMP ressemblera alors à ceci :

Demande ICMP

PC (demande ICMP) -> passerelle du site A -> tunnel VPN vers le QG -> la passerelle du QG envoie du trafic à la passerelle du site B

Réponse ICMP

Passerelle du site B (Réponse ICMP) -> Passerelle du site B -> Tunnel VPN vers le QG -> La passerelle du QG envoie le trafic à la passerelle du site A -> La passerelle du site A renvoie les paquets au PC

Par conséquent, cette route de politique est nécessaire :

Entrant : ZyWall- Source : "Site A subnet" -> Destination : "Site B subnet" - Next-hop "Site B VPN tunnel"

2.4 Test par ping sur un serveur / PC

Le PC étant situé sur le réseau 192.168.20.0/24 et le serveur sur le réseau 192.168.30.0/24, le serveur ne reconnaît pas le réseau 192.168.20.0/24 et il est donc très probable qu'il bloque les paquets ICMP provenant de sous-réseaux inconnus. Par conséquent, lorsque vous effectuez des tests, vous devez toujours :

• désactiver tout pare-feu intégré (par exemple Windows Defender / Firewall)
• Désactiver les autres logiciels antivirus et de sécurité des points finaux installés sur le serveur / PC.

Acheminer le trafic client à site via un tunnel site à site

Attention : Cela ne fonctionne pas avec Dynamic VPN ! Veuillez sélectionner uniquement Site2Site VPN !

1) Configurer le VPN IPSec de SecuExtender

Afin de router les clients VPN IPSec dans un autre tunnel, ils doivent utiliser des adresses IP fixes.

S'il est nécessaire d'acheminer de nombreux clients différents, il est recommandé d'utiliser des adresses IP proches les unes des autres afin de créer une plage d'adresses. Cela permet de réduire le nombre d'itinéraires nécessaires.

Le sous-réseau dans lequel se trouvent les adresses IP ne doit pas nécessairement être présent sur le pare-feu.

Saisissez l'adresse IP fixe sur le client VPN IPSec

2) Configurer le routage du pare-feu

Sur le pare-feu, naviguez vers

et cliquez sur

pour créer la plage d'adresses IP du client VPN IPSec.

Nous pouvons maintenant ajouter les routes nécessaires sous

Configuration > Network > Routing

en cliquant sur l'icône

2.1 Sur le site A Firewall

Nous devons créer deux routes :

• Une pour le trafic sortant, donc du tunnel dynamique VPN-client vers le sous-réseau distant via le tunnel site-à-site.

• Un pour le trafic entrant, c'est-à-dire du sous-réseau distant vers le tunnel VPN-client via le tunnel site-to-site.

Les nouvelles routes devraient ressembler à ceci :

Une autre façon de faire passer le trafic entrant du sous-réseau distant par le tunnel VPN distant est d'activer la "route asymétrique" :

L'activation de la route "triangle" permet au pare-feu d'autoriser l'utilisation d'une topologie de route asymétrique dans le réseau et de ne pas réinitialiser la connexion lorsque la réponse est renvoyée.

2.2 Pare-feu du site B

Sur le site distant, il peut être nécessaire de créer des routes similaires afin que le dispositif du site principal sache comment gérer le trafic des clients VPN provenant du site de la succursale.

Sur le site du siège, nous créons la plage d'adresses IP pour les clients VPN distants afin de pouvoir l'utiliser pour acheminer le trafic.

Nous créons maintenant les routes correspondantes sur le site du siège social également.

Une route sortante, donc du sous-réseau du QG vers les clients VPN distants via le tunnel site à site.

Et une route entrante, donc de la gamme de clients VPN distants par le tunnel site à site vers le LAN local du QG. Si le trafic est acheminé vers un sous-réseau local, nous sélectionnons "Auto" comme next-hop, l'USG gère cela automatiquement.

Les itinéraires devraient ressembler à ceci :

+++ Vous pouvez acheter des licences pour vos clients Zyxel VPN (SSL VPN, IPsec) avec livraison immédiate en 1 clic : Zyxel Webstore +++