howto : vpn ipsec entre 2 sites ayant la même...

Version 1.0 - © NETASQ 2006

Appliances UTM NETASQ v6.1 HOWTO : VPN IPsec entre 2 sites ayant la même plage d’adresses IP

VPN & Plages IP recouvrantes

Version 1.0 - © NETASQ 2006 sur 12 Référence: na_tn_vpnequal_0106_fr

Introduction

Par défaut, les fonctionnalités VPN IPsec des appliances UTM NETASQ ne permettent pas la mise en place de tunnel VPN IPsec entre deux ou plusieurs réseaux dont les plages d’adresses IP se recouvrent complètement ou partiellement. Ainsi dans le cas où les deux réseaux souhaitant communiquer avait été défini avec les mêmes plages d’adresses (ex : 192.168.0.0 / 255.255.255.0), la mise en place d’un tunnel pouvait s’avérer problématique. Grâce à l’option « NAT avant le VPN » disponible sur les appliances UTM NETASQ à partir de la version 6.1, il est désormais possible d’envisager une telle architecture.

Architectures abordées dans ce document

Dans ce document deux architectures sont distinguées.

Dans un premier temps on abordera la configuration de tunnels VPN IPsec dans le cadre d’une architecture de type Client-Serveur. Dans cette architecture le site dit « client » est toujours à l’initiative de la négociation du tunnel VPN IPsec. Mais il peut exister plusieurs sites « client ». Dans ce cas nous verrons que la configuration est relativement asymétrique entre les sites « client » et le site serveur. Dans un deuxième temps le document évoque la configuration de tunnels VPN IPsec dans le cadre d’une architecture de type « N vers N ». Dans cette architecture chacun des deux correspondants VPN peut être à l’initiative de la négociation du tunnel VPN IPsec. Ainsi on verra une configuration symétrique sur les deux sites.

Architecture Client-Serveur

Dans l’architecture Client-Serveur présentée, les réseaux des A et B possédent la même plage d’adresses IP et chacun des sites veut pouvoir contacter le site C (la configuration serait la même si les plages d’adresses des réseaux A et B ne se recouvraient que partiellement). Ici les sites A et B sont toujours à l’initiative de la négociation du tunnel VPN IPsec.

Configuration à effectuer pour les sites « Client » On effectue d’abord la configuration du site A. 1- Définition d’un réseau « virtuel » pour le réseau du site A



Le réseau virtuel A n’aura aucune réalité physique. Il permettra uniquement la translation complète du réseau du site A. Il est préférable de définir ce réseau virtuel A dans une plage d’adresses IP privée, bien que cela ne soit pas obligatoire. Ici on choisit Net_Virtuel_A : 172.16.0.0 / 255.255.255.0. Notez que la plage d’adresses originale et la plage d’adresses virtuelle doivent comporter exactement le même nombre d’adresses IP.

2- Définition de la politique de translation pour le site A La politique de translation de l’appliance UTM du site A doit être modifiée de manière à ce que les trafics à destination du site distant (site C) soient translatés vers la plage d’adresses virtuelle du site A. Ainsi vous devez ajouter les règles suivantes à votre politique :

Action Interface Original Destination Translaté

map ipsec Net_A Net_C Net_virtuel_A

map ifx Net_A Net_C Net_virtuel_A

Dans l’exemple « ifx » = interface out, mais cela n’est pas toujours le cas. Reportez-vous à la section « Comment déterminer l’interface ifx » pour comprendre comment définir cette interface.



3- Activation de l’option « NAT avant le VPN » pour le site A Sur chacun des sites qui ont leur plage d’adresses IP se recouvrent, il est nécessaire d’activer l’option « NAT avant le VPN » ce qui a pour effet d’effectuer les étapes de translation du trafic avant son passage dans le module VPN de l’appliance UTM NETASQ.

4- Définition de la politique VPN pour le site A Dernière étape de configuration pour le site A, la politique VPN tient compte des adaptations qui ont été faite à la politique de translation. En effet dès lors que la politique de translation est modifiée et que l’option « NAT avant le VPN » est cochée, le trafic du réseau Net_A est complètement translaté vers Net_virtuel_A avant d’entrer dans le module VPN. Ainsi l’extrémité locale du trafic devient ce réseau virtuel.

Extrémité locale du trafic

Extrémité locale du tunnel

Extrémité distante du tunnel

Extrémité distante du trafic

Net_virtuel_A Fw_pub_A Fw_pub_C Net_C

La configuration du site A est terminée. On poursuit la configuration des sites clients par la configuration du site B. Cette configuration est sensiblement la même que pour le site A. 5- Définition d’un réseau « virtuel » pour le réseau du site B Le réseau virtuel B n’aura aucune réalité physique. Il permettra uniquement la translation complète du réseau du site B. Il est préférable de définir ce réseau virtuel B dans une plage d’adresses IP privée, bien que cela ne soit pas obligatoire.



Ici on choisit Net_Virtuel_B : 172.16.1.0 / 255.255.255.0. Notez que la plage d’adresses originale et la plage d’adresses virtuelle doivent comporter exactement le même nombre d’adresses IP.

6- Définition de la politique de translation pour le site B La politique de translation de l’appliance UTM du site B doit être modifiée de manière à ce que les trafics à destination du site distant (site C) soient translatés vers la plage d’adresses virtuelle du site B. Ainsi vous devez ajouter les règles suivantes à votre politique :


map ipsec Net_B Net_C Net_virtuel_B

map ifx Net_B Net_C Net_virtuel_B


7- Activation de l’option « NAT avant le VPN » pour le site B



Sur chacun des sites qui ont leur plage d’adresses IP se recouvrent, il est nécessaire d’activer l’option « NAT avant le VPN » ce qui a pour effet d’effectuer les étapes de translation du trafic avant son passage dans le module VPN de l’appliance UTM NETASQ.

8- Définition de la politique VPN pour le site B Dernière étape de configuration pour le site B, la politique VPN tient compte des adaptations qui ont été faite à la politique de translation. En effet dès lors que la politique de translation est modifiée et que l’option « NAT avant le VPN » est cochée, le trafic du réseau Net_B est complètement translaté vers Net_virtuel_B avant d’entrer dans le module VPN. Ainsi l’extrémité locale du trafic devient ce réseau virtuel.





Net_virtuel_B Fw_pub_B Fw_pub_C Net_C

La configuration du site B est terminée. Il est nécessaire d’effectuer désormais la configuration du site « Serveur », le site C. Configuration à effectuer pour le site « Serveur » Vous noterez que la configuration du site « Serveur » est plus simple. De plus l’option « NAT avant le VPN » ne sera pas activée sur l’appliance UTM NETASQ du site « Serveur ». 1- Définition des réseaux « virtuels » pour les réseaux des sites A et B Ces réseaux virtuels n’auront aucune réalité physique. Ils permettront uniquement la définition de politique de tunnels VPN IPsec en concordance avec la configuration effectuée sur les sites



clients. Rappel : on avait choisi Net_Virtuel_A : 172.16.0.0 / 255.255.255.0 et Net_Virtuel_B : 172.16.1.0 / 255.255.255.0. 2- Définition de la politique VPN pour le site C Dernière étape de configuration pour le site C, la politique VPN tient compte des adaptations qui ont été faite à la politique de translation sur les sites « client ». Ainsi l’extrémité distante des trafics devient les réseaux virtuels qui ont été définis.





Net_C Fw_pub_C Fw_pub_A Net_virtuel_A

Net_C Fw_pub_C Fw_pub_B Net_virtuel_B

Architecture N vers N

Dans l’architecture N vers N présentée, les réseaux des A et B possédent la même plage d’adresses IP (la configuration serait la même si les plages d’adresses des réseaux A et B ne se recouvraient que partiellement). Les deux sites peuvent être à l’initiative de la mise en place du tunnel VPN IPsec.

Configuration à effectuer pour le site A 1- Définition des réseaux « virtuels » pour les réseaux des sites A et B Ces réseaux virtuels n’auront aucune réalité physique. Ils permettront la translation complète des reséaux des sites A et B et la définition de politique de tunnels VPN IPsec en concordance avec la configuration effectuée sur les sites A et B. Il est préférable de définir ces réseaux virtuels dans une plage d’adresses IP privée, bien que cela ne soit pas obligatoire. Ici on choisit Net_Virtuel_A : 172.16.0.0 / 255.255.255.0 et Net_Virtuel_B : 172.16.1.0 / 255.255.255.0.Notez que la plage d’adresses originale et la plage d’adresses virtuelle doivent comporter exactement le même nombre d’adresses IP.



2- Définition de la politique de translation pour le site A La politique de translation de l’appliance UTM du site A doit être modifiée de manière à ce que les trafics à destination du site distant soient translatés vers la plage d’adresses virtuelle du site A. De plus étant donné que l’ensemble du site distant est translaté, ce site distant est défini par le réseau virtuel défini préalablement. Ainsi vous devez ajouter les règles suivantes à votre politique :


map ipsec Net_A Net_virtuel_B Net_virtuel_A

map ifx Net_A Net_virtuel_B Net_virtuel_A


3- Activation de l’option « NAT avant le VPN » pour le site A Sur chacun des sites qui ont leur plage d’adresses IP se recouvrent, il est nécessaire d’activer l’option « NAT avant le VPN » ce qui a pour effet d’effectuer les étapes de translation du trafic avant son passage dans le module VPN de l’appliance UTM NETASQ.



4- Définition de la politique VPN pour le site A Dernière étape de configuration pour le site A, la politique VPN tient compte des adaptations qui ont été faite à la politique de translation. En effet dès lors que la politique de translation est modifiée et que l’option « NAT avant le VPN » est cochée, le trafic du réseau Net_A est complètement translaté vers Net_virtuel_A avant d’entrer dans le module VPN. Ainsi l’extrémité locale du trafic devient ce réseau virtuel.





Net_virtuel_A Fw_pub_A Fw_pub_B Net_virtuel_B

Configuration à effectuer pour le site B 1- Définition des réseaux « virtuels » pour les réseaux des sites A et B Ces réseaux virtuels n’auront aucune réalité physique. Ils permettront la translation complète des reséaux des sites A et B et la définition de politique de tunnels VPN IPsec en concordance avec la configuration effectuée sur les sites A et B. Il est préférable de définir ces réseaux virtuels dans une plage d’adresses IP privée, bien que cela ne soit pas obligatoire. Ici on choisit Net_Virtuel_A : 172.16.0.0 / 255.255.255.0 et Net_Virtuel_B : 172.16.1.0 / 255.255.255.0.Notez que la plage d’adresses originale et la plage d’adresses virtuelle doivent comporter exactement le même nombre d’adresses IP.



2- Définition de la politique de translation pour le site B La politique de translation de l’appliance UTM du site A doit être modifiée de manière à ce que les trafics à destination du site distant soient translatés vers la plage d’adresses virtuelle du site A. De plus étant donné que l’ensemble du site distant est translaté, ce site distant est défini par le réseau virtuel défini préalablement. Ainsi vous devez ajouter les règles suivantes à votre politique :


map ipsec Net_B Net_virtuel_A Net_virtuel_B

map ifx Net_B Net_virtuel_A Net_virtuel_B


3- Activation de l’option « NAT avant le VPN » pour le site B Sur chacun des sites qui ont leur plage d’adresses IP se recouvrent, il est nécessaire d’activer l’option « NAT avant le VPN » ce qui a pour effet d’effectuer les étapes de translation du trafic avant son passage dans le module VPN de l’appliance UTM NETASQ.



4- Définition de la politique VPN pour le site B Dernière étape de configuration pour le site B, la politique VPN tient compte des adaptations qui ont été faite à la politique de translation. En effet dès lors que la politique de translation est modifiée et que l’option « NAT avant le VPN » est cochée, le trafic du réseau Net_B est complètement translaté vers Net_virtuel_B avant d’entrer dans le module VPN. Ainsi l’extrémité locale du trafic devient ce réseau virtuel.





Net_virtuel_B Fw_pub_B Fw_pub_A Net_virtuel_A

Comment définir l’interface « ifx » ?

L’interface « ifx » doit être définie pour la configuration de la politique de translation. Cette interface est « l’interface sur laquelle seraient partis les paquets s’il n’y avait pas de tunnel VPN IPsec ». Dans la majorité des cas, cette interface est l’interface OUT mais il peut arriver que cela ne soit pas le cas comme dans l’exemple suivant :



Ici la direction « normale » du trafic à destination du réseau 192.168.0.0 / 255.255.255.0 aurait dû être l’interface DMZ. Mais du fait du tunnel on veut le rediriger vers le site B. Ainsi l’interface « ifx » est DMZ et non OUT comme dans le cas général.

howto : vpn ipsec entre 2 sites ayant la même...

Documents