Différences

Ci-dessous, les différences entre deux révisions de la page.

--- checkpoint:vpn-1:vpn-s2s [07.08.2007 13:01] – création youp3
+++ checkpoint:vpn-1:vpn-s2s [07.01.2010 12:32] (Version actuelle) – modification externe 127.0.0.1
@@ Ligne 1: / Ligne 1: @@
 ====== VPN site à site ======
-Cette page recense normalement tout ce qu'il vous faut pour monter un tunnel site à site avec Checkpoint.
+Cette page recense normalement tout ce qu'il faut pour monter un tunnel site à site avec Check Point.\\
+===== La communauté VPN =====
+Pour créer la communauté VPN, rendez-vous sur l'onglet VPN du SmartDashboard :
+  - Faire un clic droit dans le cadre du haut.
+  - Choisir //New Community// > //Meshed...//
+  - Donner un nom à la communauté (nous prendrons //Zamiz// pour le reste de cette page).
+  - Dans //VPN Properties//
+    - IKE (Phase 1) Properties
+      * Perform key exchange encrytpion with: **AES-256**
+      * Perform data integrity with: **SHA1**
+    - IPSec (Phase 2) Properties
+      * Perform IPSec data encryption with: **AES-256**
+      * Perform data integrity with: **SHA1**
+  - Dans //Tunnel management// (NGX R65), choisir l'option //VPN Tunnel Sharing// qui convient le mieux à votre situation. Généralement pour un tunnel site à site, le troisième et dernier choix //One VPN Tunnel per Gateway pair// est suffisante.
+  - Dans //Advanced Settings//
+    - //Excluded Services// : ajouter ici le port UDP/500 (IKE) ainsi que tout autre port que vous ne voulez absolument pas voir passer dans le tunnel.
+    - //Shared Secret// : utile uniquement si vous souhaitez utiliser monter un tunnel en utilisant une clé partagée (Pre Shared Key ou PSK). Si possible, privilégiez plutôt la solution avec certificats.
+    - //Advanced VPN Properties// :
+      - IKE (Phase 1)
+        * Use Diffie-Hellman group: **Group 2 (1024 bit)** [On peut utiliser à la rigueur le groupe 5 mais pas plus pour garder la compatibilité avec NGAI]
+        * Renegociate IKE security associations every **1440** minutes
+        * Use aggressive mode : peut être coché ou non, cela dépend des VPN utilisées.
+      - IPSec (Phase 2)
+        * Cocher //Use Perfect Forward Secrecy// et choisir **Group 2 (1024 bit)** pour l'option //Use Diffie-Hellman group//. Même remarque que précédemment concernant le groupe 5.
+        * Renegociate IPSec security associations every **3600** seconds
+    - //Wire Mod// : il faut évitez si possible d'utiliser ce genre d'option.
+===== Les objets VPN =====
+Nous prenons comme hypothèse qu'une seule VPN est gérée par notre SmartCenter.
+==== VPN A ====
+La VPN A sera celle gérée par notre SmartCenter et nous considèrerons ici que c'est un objet Check Point de type //VPN-1 Power / UTM Gateway//.
+  - Donner un nom et l'adresse IP externe de la VPN (celle connue par notre partenaire, indispensable avant NGX).
+  - Renseigner précisément partie //Topology//.
+  - Toujours dans cette partie Topology, il faut définir le //VPN Domain//. Il faut définir ici les adresses qui sont protégées par VPN A et donc pour lesquelles VPN B enverra les flux dans le tunnel. Généralement on privilégie l'option //Manually defined// car elle permet d'indiquer précisément les adresses.
+  - Dans la partie VPN, ajouter la communauté //Zamiz// en cliquant sur //Add...//
+  - Cliquer ensuite sur //Traditionnal mode configuration...//
+    - Support key exchange encryption with:
+      * Cocher uniquement **AES-256**.
+    - Support data integrity with:
+      * Cocher uniquement **SHA1**
+    - Support authentication methods:
+      * Cocher de préférence uniquement //Public Key Signatures//. Il est possible de spécifier les certificats de quelle AC la passerelle doit utiliser en cliquant sur le bouton //Specify//. Mais ceci n'est valable que pour le dialogue avec des VPN gérées par le même SmartCenter
+    - Cliquer enfin sur //Advanced...//
+      - Support Diffie-Hellman groups for IKE (phase 1) Security associations
+        * Cocher **Group 2 (1024 bit)** [On peut utiliser à la rigueur le groupe 5 mais pas plus pour garder la compatibilité avec NGAI]
+      - Renegociate IKE (phase 1) Security associtations every **1440** Minutes
+      - Renegociate IPsec (IKE phase 2) Security associations every **3600** Seconds
+      - Cocher éventuellement la case //Support aggressive mode// selon le besoin.
+==== VPN B ====
+La VPN B, que ce soit un matériel Check Point ou non doit être du type //Interoperable Devices//. Pour un équipement Check Point, un objet Check Point de type //Externally Managed VPN Gateway// mais ceci peut être gênant lorsque cette VPN est dans une version plus récente que celle de notre SmartCenter. Dans le cas d'un //Interoperable Devices//, il faut :
+  - Donner un nom et l'adresse IP externe de la VPN (celle connue de nous).
+  - Dans la partie Topology, renseigner une interface (bidon) avec l'adresse IP précédemment utilisée.
+  - Toujours dans cette partie Topology, il faut définir le //VPN Domain//. Il faut définir ici les adresses qui sont protégées par VPN B et donc pour lesquelles VPN A enverra les flux dans le tunnel. Généralement on privilégie l'option //Manually defined// car elle permet d'indiquer précisément les adresses.
+  - Dans la partie VPN, ajouter la communauté //Zamiz// en cliquant sur //Add...//
+  - Dans //Matching Criteria...//, choisir l'autorité de certification (AC) dont doit être issu le certificat présenté par VPN B lors de l'établissement du tunnel. Et pour vous assurer que c'est bien VPN B, il est conseillé de renseigner le DN du certificat qui doit normalement être présenté par cette VPN. Le DN peut se présenter sous la forme : <code>CN=VPN2,OU=VPN-01,O=BIDULE</code> Ainsi si ce n'est pas le bon certificat qui est présenté, le tunnel ne pourra pas être monté.
+===== Flux à ouvrir pour le tunnel =====
+Les deux règles suivantes permettent l'établissement du tunnel VPN IPSec
+<code>VPN A > VPN B : UDP/500 (IKE)
+VPN B > VPN A : UDP/500 (IKE)</code>
+**__Attention__** : la création de ces règles ne suffit pas et il faut penser à exclure le port UDP/500 de la [[checkpoint:vpn-1:vpn-s2s#La communauté VPN|communauté VPN]]. Sans quoi vous vous retrouverez très certainement avec le flux IKE droppé avec le message suivant :<code>encryption failure: Clear texte packet should be encrypted</code>
+===== Flux tunnelisés =====
+Check Point recommande d'utiliser des politiques de sécurité utilisant le mode simplifié. Dans ce mode, si nous avons une machine C (protégée par VPN A) qui veut faire un flux HTTP sur une machine D (protégée par VPN B), il suffit dans un premier temps d'écrire une règle classique <code>C > D : TCP/80</code> et d'ajouter dans la colone //VPN// de cette règle la communauté //Zamiz//.
+===== Déboguer un tunnel ne fonctionnant pas =====
+Sur le module VPN, activer le mode déboguage en exécutant la commande suivante : <code>vpn debug trunc</code>En réalité, cette comme équivaux aux deux commandes <code>vpn debug on
+vpn debug ikeon</code>
+Ne pas oublier d'arrêter le déboguage, une fois les tests terminés, avec les commandes <code>vpn debug off
+vpn debug ikeoff</code>Le résultat des traces se trouve dans les fichiers //$FWDIR/log/ike.elg// et //$FWDIR/log/vpnd.elg//\\
+Pour exploiter ces traces de manière simple, vous pouvez télécharger l'outil IKEView sur le [[https://supportcenter.checkpoint.com|site de CheckPoint]]. Pour cela il faut disposer d'un compte sur leur site et chercher "ike view".