Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Présentation du VPN IPsec

Un VPN est un réseau privé qui utilise un réseau public pour connecter au moins deux sites distants. Au lieu d’utiliser des connexions dédiées entre les réseaux, les VPN utilisent des connexions virtuelles routés (tunnelisées) via des réseaux publics. Le VPN IPsec est un protocole composé d’un ensemble de normes utilisées pour établir une connexion VPN.

Un VPN permet aux ordinateurs distants de communiquer en toute sécurité sur un WAN public comme Internet.

Une connexion VPN peut relier deux réseaux LOCAUX (VPN de site à site) ou un utilisateur distant à connexion commuté et un réseau local. Le trafic qui transite entre ces deux points passe par des ressources partagées telles que des routeurs, des commutateurs et d’autres équipements réseau qui composent le WAN public. Pour sécuriser les communications VPN tout en passant par le WAN, les deux participants créent un tunnel IPsec (IP Security).

Le terme tunnel ne désigne pas le mode tunnel (voir Traitement des paquets en mode tunnel). Au lieu de cela, il fait référence à la connexion IPsec.

Topologies VPN IPsec sur les équipements SRX Series

Voici quelques-unes des topologies VPN IPsec prises en charge par le système d’exploitation Junos :

  • VPN de site à site : relie deux sites d’une entreprise et permet de sécuriser les communications entre les sites.

  • VPN en étoile : connecte les filiales au bureau d’entreprise dans un réseau d’entreprise. Vous pouvez également utiliser cette topologie pour connecter les rayons en envoyant du trafic via le hub.

  • VPN d’accès distant : permet aux utilisateurs travaillant à domicile ou voyageant de se connecter au bureau de l’entreprise et à ses ressources. Cette topologie est parfois appelée tunnel de bout en bout.

Comparaison des VPN basés sur des stratégies et basés sur le routage

Il est important de comprendre les différences entre les VPN basés sur des stratégies et les VPN basés sur le routage et pourquoi l’un peut être préférable à l’autre.

Tableau 1 répertorie les différences entre les VPN basés sur le routage et les VPN basés sur des stratégies.

Tableau 1 : Différences entre les VPN basés sur le routage et les VPN basés sur des stratégies

VPN basés sur le routage

VPN basés sur des stratégies

Avec les VPN basés sur le routage, une stratégie ne renvoie pas spécifiquement à un tunnel VPN.

Avec les tunnels VPN basés sur des stratégies, un tunnel est traité comme un objet qui, avec la source, la destination, l’application et l’action, constitue une stratégie de tunnel permettant le trafic VPN.

La stratégie renvoie à une adresse de destination.

Dans une configuration VPN basée sur des stratégies, une stratégie de tunnel fait spécifiquement référence à un tunnel VPN par son nom.

Le nombre de tunnels VPN basés sur le routage que vous créez est limité par le nombre d’entrées de routage ou le nombre d’interfaces st0 que l’équipement prend en charge, selon le nombre le plus faible.

Le nombre de tunnels VPN basés sur des stratégies que vous pouvez créer est limité par le nombre de stratégies que l’équipement prend en charge.

La configuration de tunnel VPN basée sur le routage est un bon choix lorsque vous souhaitez conserver les ressources du tunnel tout en définissant des restrictions granulaires du trafic VPN.

Avec un VPN basé sur des stratégies, bien que vous puissiez créer de nombreuses stratégies de tunnel faisant référence au même tunnel VPN, chaque paire de stratégies de tunnel crée une association de sécurité IPsec (SA) individuelle avec l’appairage distant. Chaque SA peut être considéré comme un tunnel VPN individuel.

Avec une approche basée sur le routage des VPN, la régulation du trafic n’est pas couplée aux moyens de sa distribution. Vous pouvez configurer des dizaines de stratégies pour réguler le trafic circulant à travers un tunnel VPN unique entre deux sites, et une seule sa IPsec est en service. En outre, une configuration VPN basée sur le routage vous permet de créer des stratégies faisant référence à une destination atteinte via un tunnel VPN dans lequel l’action est de refus.

Dans une configuration VPN basée sur des stratégies, l’action doit être permise et inclure un tunnel.

Les VPN basés sur le routage prennent en charge l’échange d’informations de routage dynamiques via des tunnels VPN. Vous pouvez activer une instance d’un protocole de routage dynamique, tel qu’OSPF, sur une interface st0 reliée à un tunnel VPN.

L’échange d’informations de routage dynamique n’est pas pris en charge dans les VPN basés sur des stratégies.

Les configurations basées sur le routage sont utilisées pour les topologies en étoile.

Les VPN basés sur des stratégies ne peuvent pas être utilisés pour les topologies en étoile.

Avec les VPN basés sur le routage, une stratégie ne renvoie pas spécifiquement à un tunnel VPN.

Lorsqu’un tunnel ne connecte pas de grands réseaux exécutant des protocoles de routage dynamiques et que vous n’avez pas besoin de conserver les tunnels ou de définir diverses stratégies pour filtrer le trafic par le tunnel, un tunnel basé sur des stratégies est le meilleur choix.

Les VPN basés sur le routage ne prennent pas en charge les configurations VPN d’accès distant (commuté).

Des tunnels VPN basés sur des stratégies sont requis pour les configurations VPN d’accès distant (commuté).

Les VPN basés sur le routage peuvent ne pas fonctionner correctement avec certains fournisseurs tiers.

Des VPN basés sur des stratégies peuvent être requis si un tiers nécessite des SAs distincts pour chaque sous-réseau distant.

Lorsque l’équipement de sécurité effectue une recherche de routage pour trouver l’interface à travers laquelle il doit envoyer le trafic pour atteindre une adresse, il trouve un itinéraire via une interface de tunnel sécurisé (st0) , qui est reliée à un tunnel VPN spécifique.

Avec un tunnel VPN basé sur le routage, vous pouvez considérer un tunnel comme un moyen de diffuser le trafic et peut considérer la stratégie comme une méthode permettant ou refusant la distribution de ce trafic.

Avec un tunnel VPN basé sur des stratégies, vous pouvez considérer un tunnel comme un élément dans la construction d’une stratégie.

Les VPN basés sur le routage prennent en charge la traduction d’adresses réseau (NAT) pour les interfaces st0.

Les VPN basés sur des stratégies ne peuvent pas être utilisés si la fonction NAT est requise pour le trafic tunnelisé.

L’ID de proxy est pris en charge à la fois pour les VPN basés sur le routage et les VPN basés sur des stratégies. Les tunnels basés sur le routage permettent également l’utilisation de plusieurs sélecteurs de trafic, également appelés ID multi-proxy. Un sélecteur de trafic est un accord entre les pairs IKE pour autoriser le trafic via un tunnel, si le trafic correspond à une paire spécifiée de préfixe d’adresse IP locale et distante, de plage de ports source, de plage de ports de destination et de protocole. Vous définissez un sélecteur de trafic dans un VPN basé sur le routage spécifique, ce qui peut entraîner plusieurs AS IPSec de phase 2. Seul le trafic conforme à un sélecteur de trafic est autorisé par l’intermédiaire d’un SA. Le sélecteur de trafic est généralement requis lorsque les équipements de passerelle distants ne sont pas des équipements Juniper Networks.

Les VPN basés sur des stratégies sont pris en charge uniquement sur les équipements SRX5400, SRX5600 et SRX5800. La prise en charge de la plate-forme dépend de la version de Junos OS dans votre installation.

Comparaison des VPN basés sur des stratégies et des VPN basés sur le routage

Tableau 2 résume les différences entre les VPN basés sur des stratégies et les VPN basés sur le routage.

Tableau 2 : Comparaison entre les VPN basés sur des stratégies et les VPN basés sur le routage

VPN basés sur des stratégies

VPN basés sur le routage

Dans les VPN basés sur des stratégies, un tunnel est traité comme un objet qui, avec la source, la destination, l’application et l’action, constitue une stratégie de tunnel permettant le trafic VPN.

Dans les VPN basés sur le routage, une stratégie ne renvoie pas spécifiquement à un tunnel VPN.

Une stratégie de tunnel fait spécifiquement référence à un tunnel VPN par son nom.

Un routage détermine le trafic envoyé par le tunnel en fonction d’une adresse IP de destination.

Le nombre de tunnels VPN basés sur des stratégies que vous pouvez créer est limité par le nombre de tunnels que l’équipement prend en charge.

Le nombre de tunnels VPN basés sur le routage que vous créez est limité par le nombre d’interfaces st0 (pour les VPN point à point) ou le nombre de tunnels que l’équipement prend en charge, selon la limite la plus faible.

Avec un VPN basé sur des stratégies, bien que vous puissiez créer de nombreuses stratégies de tunnel faisant référence au même tunnel VPN, chaque paire de stratégies de tunnel crée un SA IPsec individuel avec l’appairage distant. Chaque SA peut être considéré comme un tunnel VPN individuel.

Étant donné que le routage, et non la stratégie, détermine le trafic qui passe par le tunnel, plusieurs stratégies peuvent être prises en charge à l’aide d’un seul SA ou VPN.

Dans un VPN basé sur des stratégies, l’action doit être permise et inclure un tunnel.

Dans un VPN basé sur le routage, la régulation du trafic n’est pas couplée aux moyens de sa distribution.

L’échange d’informations de routage dynamique n’est pas pris en charge dans les VPN basés sur des stratégies.

Les VPN basés sur le routage prennent en charge l’échange d’informations de routage dynamiques via des tunnels VPN. Vous pouvez activer une instance d’un protocole de routage dynamique, tel qu’OSPF, sur une interface st0 reliée à un tunnel VPN.

Si vous avez besoin d’une plus grande granularité qu’un routage peut fournir pour spécifier le trafic envoyé à un tunnel, l’utilisation d’un VPN basé sur des stratégies avec des stratégies de sécurité est le meilleur choix.

Les VPN basés sur le routage utilisent des routes pour spécifier le trafic envoyé à un tunnel ; une stratégie ne renvoie pas spécifiquement à un tunnel VPN.

Avec un tunnel VPN basé sur des stratégies, vous pouvez considérer un tunnel comme un élément dans la construction d’une stratégie.

Lorsque l’équipement de sécurité effectue une recherche de route pour trouver l’interface à travers laquelle il doit envoyer le trafic pour atteindre une adresse, il trouve un itinéraire via une interface de tunnel sécurisé (st0).

Avec un tunnel VPN basé sur le routage, vous pouvez considérer un tunnel comme un moyen de diffuser le trafic et peut considérer la stratégie comme une méthode permettant ou refusant la distribution de ce trafic.

Comprendre le traitement des paquets IKE et IPsec

Un tunnel VPN IPsec est constitué d’une configuration de tunnel et d’une sécurité appliquée. Lors de la configuration du tunnel, les pairs établissent des associations de sécurité qui définissent les paramètres de sécurisation du trafic entre eux. (Voir Présentation d’IPsec.) Une fois le tunnel établi, IPsec protège le trafic envoyé entre les deux points de terminaison du tunnel en appliquant les paramètres de sécurité définis par les SAS pendant la configuration du tunnel. Dans le cadre de l’implémentation de Junos OS, iPsec est appliqué en mode tunnel, qui prend en charge les protocoles ESP (Encapsulating Security Payload) et AH (Authentication Header).

Cette rubrique comprend les sections suivantes :

Traitement des paquets en mode tunnel

IPsec fonctionne selon l’un des deux modes : le transport ou le tunnel. Lorsque les deux extrémités du tunnel sont hôtes, vous pouvez utiliser l’un ou l’autre mode. Lorsque l’un des points de terminaison d’un tunnel est une passerelle de sécurité, telle qu’un routeur ou un pare-feu Junos OS, vous devez utiliser le mode tunnel. Les équipements Juniper Networks fonctionnent toujours en mode tunnel pour les tunnels IPsec.

En mode tunnel, l’ensemble du paquet IP d’origine (charge utile et en-tête) est encapsulé dans une autre charge utile IP, et un nouvel en-tête y est ajouté, comme illustré dans Figure 1. L’ensemble du paquet d’origine peut être chiffré, authentifié, ou les deux. Avec le protocole AH (Authentication Header), l’AH et les nouveaux en-têtes sont également authentifiés. Avec le protocole ESP (Encapsulating Security Payload), l’en-tête ESP peut également être authentifié.

Figure 1 : Tunnel ModeTunnel Mode

Dans un VPN de site à site, les adresses source et de destination utilisées dans le nouvel en-tête sont les adresses IP de l’interface sortante. Voir Figure 2.

Figure 2 : VPN de site à site en mode tunnelVPN de site à site en mode tunnel

Dans un VPN commuté, il n’y a pas de passerelle de tunnel sur la fin du client d’accès commuté DU VPN; le tunnel s’étend directement au client lui-même (voir Figure 3). Dans ce cas, sur les paquets envoyés à partir du client d’accès commuté, le nouvel en-tête et l’en-tête d’origine encapsulé ont la même adresse IP : celui de l’ordinateur du client.

Certains clients VPN, comme le client VPN dynamique et Netscreen-Remote, utilisent une adresse IP interne virtuelle (également appelée « adresse rémanente »). Netscreen-Remote vous permet de définir l’adresse IP virtuelle. Le client VPN dynamique utilise l’adresse IP virtuelle attribuée lors de l’échange de configuration XAuth. Dans ce cas, l’adresse IP interne virtuelle est l’adresse IP source dans l’en-tête de paquet d’origine du trafic provenant du client, et l’adresse IP que le FAI assigne dynamiquement au client commuté est l’adresse IP source dans l’en-tête externe. À partir de Junos OS Version 21.4R1, le VPN dynamique n’est pas pris en charge sur les équipements SRX300, SRX320, SRX340, SRX345, SRX380 et SRX550 HM.

Figure 3 : VPN commuté en mode tunnelVPN commuté en mode tunnel

Distribution des sessions IKE et IPsec sur les SPU

Dans les équipements SRX5400, SRX5600 et SRX5800, IKE gère les tunnels pour IPsec et authentifie les entités finaux. IKE effectue un échange de clés Diffie-Hellman (DH) pour générer un tunnel IPsec entre les équipements réseau. Les tunnels IPsec générés par IKE sont utilisés pour chiffrer, déchiffrer et authentifier le trafic utilisateur entre les équipements réseau au niveau de la couche IP.

Le VPN est créé en distribuant la charge de travail IKE et IPsec entre les diverses unités de traitement des services (SPU) de la plate-forme. Pour les tunnels de site à site, le SPU le moins chargé est choisi comme SPU d’ancrage. Si plusieurs SPU ont la même charge la plus faible, n’importe lequel d’entre eux peut être choisi comme SPU d’ancrage. Ici, la charge correspond au nombre de passerelles site à site ou tunnels VPN manuels ancrés sur un SPU. Pour les tunnels dynamiques, les tunnels dynamiques nouvellement établis utilisent un algorithme round-robin pour sélectionner le SPU.

Dans IPsec, la charge de travail est distribuée par le même algorithme qui distribue l’IKE. Le SA de phase 2 d’une paire de points de terminaison de tunnel VPN est détenu exclusivement par un SPU particulier, et tous les paquets IPsec appartenant à cette sa de phase 2 sont transféré vers le SPU d’ancrage de ce SA pour traitement IPsec.

Plusieurs sessions IPsec (Phase 2 SA) peuvent fonctionner sur une ou plusieurs sessions IKE. Le SPU sélectionné pour l’ancrage de la session IPsec est basé sur le SPU qui ancre la session IKE sous-jacente. Par conséquent, toutes les sessions IPsec exécutées sur une passerelle IKE unique sont assurées par le même SPU et ne sont pas réparties en charge sur plusieurs SPU.

Tableau 3 illustre un exemple d’équipement de la gamme SRX5000 avec trois SPU exécutant sept tunnels IPsec sur trois passerelles IKE.

Tableau 3 : Distribution des sessions IKE et IPsec sur les SPU

SPU

Passerelle IKE

IPsec Tunnel

SPU0

IKE-1

IPsec-1

IPsec-2

IPsec-3

SPU1

IKE-2

IPsec-4

IPsec-5

IPsec-6

SPU2

IKE-3

IPsec-7

Les trois SPU ont une charge égale à une passerelle IKE chacune. Si une nouvelle passerelle IKE est créée, vous pouvez sélectionner SPU0, SPU1 ou SPU2 pour ancrer la passerelle IKE et ses sessions IPsec.

La configuration et la déchirure des tunnels IPsec existants n’affectent pas la session IKE sous-jacente ni les tunnels IPsec existants.

Utilisez la commande suivante show pour afficher le nombre de tunnels actuel par SPU : show security ike tunnel-map.

Utilisez l’option summary de la commande pour afficher les points d’ancrage de chaque passerelle : show security ike tunnel-map summary.

Prise en charge VPN pour l’insertion de cartes de traitement des services

Les équipements SRX5400, SRX5600 et SRX5800 sont dotés d’une architecture à processeur distribué sur châssis. La puissance de traitement des flux est partagée et est basée sur le nombre de cartes de traitement des services (SPC). Vous pouvez faire évoluer la puissance de traitement de l’équipement en installant de nouveaux SPC.

Dans un cluster de châssis SRX5400, SRX5600 ou SRX5800, vous pouvez insérer de nouveaux SPC sur les équipements sans affecter ni perturber le trafic sur les tunnels VPN IKE ou IPsec existants. Lorsque vous insérez une nouvelle carte SPC dans chaque châssis du cluster, les tunnels existants ne sont pas affectés et le trafic continue de circuler sans perturbation.

À partir de Junos OS Version 19.4R1, sur tous les équipements SRX5000 Series en cluster de châssis, vous pouvez insérer une nouvelle carte SRX5K-SPC3 (SPC3) ou SRX5K-SPC-4-15-320 (SPC2) sur un châssis existant contenant la carte SPC3. Vous pouvez uniquement insérer les cartes dans un emplacement supérieur à celui de la carte SPC3 existante sur le châssis. Vous devez redémarrer le nœud après l’insertion de SPC3 pour activer la carte. Une fois le redémarrage terminé, les tunnels IPsec sont distribués aux cartes.

Cependant, les tunnels existants ne peuvent pas utiliser la puissance de traitement des unités de traitement des services (SPU) dans les nouveaux SPC. Un nouveau SPU peut ancrer de nouveaux tunnels dynamiques de site à site. Toutefois, les tunnels nouvellement configurés ne sont pas garantis pour être ancrés sur un nouveau SPU.

Les tunnels de site à site sont ancrées sur différentes SPU en fonction d’un algorithme d’équilibrage de charge. L’algorithme d’équilibrage de charge dépend des threads de flux de nombres que chaque SPU utilise. Les tunnels appartenant aux mêmes adresses IP de passerelle locale et distante sont ancrées sur le même SPU sur différents threads RT de flux utilisés par le SPU. Le SPU ayant la plus petite charge est choisi comme SPU d’ancrage. Chaque SPU maintient le nombre de threads RT de flux hébergés dans ce SPU particulier. Le nombre de threads RT de flux hébergés sur chaque SPU varie en fonction du type de SPU.

Facteur de charge du tunnel = Nombre de tunnels ancrés sur le SPU / Nombre total de fils RT de flux utilisés par le SPU.

Les tunnels dynamiques sont ancrées sur différents SPU en fonction d’un algorithme round-robin. Les tunnels dynamiques nouvellement configurés ne sont pas garantis pour être ancrés sur la nouvelle carte SPC.

À partir des versions 18.2R2 et 18.4R1 de Junos OS, toutes les fonctionnalités VPN IPsec existantes actuellement prises en charge sur les équipements SRX5K-SPC3 (SPC3) seront uniquement prises en charge sur les équipements SRX5400, SRX5600 et SRX5800 lorsque les cartes SRX5K-SPC-4-15-320 (SPC2) et SPC3 sont installées et fonctionnent sur l’équipement en mode cluster de châssis ou en mode autonome.

Lorsque des cartes SPC2 et SPC3 sont installées, vous pouvez vérifier le mappage de tunnel sur les différents SPU à l’aide de la show security ipsec tunnel-distribution commande.

Utilisez la commande show security ike tunnel-map pour afficher le mappage de tunnel sur différentes SPU avec seule la carte SPC2 insérée. Cette commande show security ike tunnel-map n’est pas valide dans un environnement où les cartes SPC2 et SPC3 sont installées.

Insérer une carte SPC3 : Directives et limites :

  • Dans un cluster de châssis, si l’un des nœuds possède 1 carte SPC3 et l’autre nœud dispose de 2 cartes SPC3, le basculement vers le nœud doté de 1 carte SPC3 n’est pas pris en charge.

  • Vous devez insérer la carte SPC3 ou SPC2 dans un châssis existant dans un emplacement plus élevé qu’une carte SPC3 actuelle présente dans un emplacement inférieur.

  • Pour que SPC3 ISHU fonctionne, vous devez insérer la nouvelle carte SPC3 dans le numéro d’emplacement supérieur.

  • Sur le cluster de châssis SRX5800, vous ne devez pas insérer la carte SPC3 dans l’emplacement le plus élevé (emplacement n° 11) en raison de la limite d’alimentation et de distribution de la chaleur.

  • Nous ne prenons pas en charge le retrait à chaud SPC3.

Tableau 4 résume la gamme d’équipements SRX5000 avec la carte SPC2 ou SPC3 qui prend en charge kmd ou iked traite :

Tableau 4 : kmd/ Priseiked en charge des processus sur la gamme d’équipements SRX5000

Gamme d’équipements SRX5000

kmd Prise en charge ou iked processus

Gamme d’équipements SRX5000 avec uniquement une carte SPC2 installée

Processus de prise en charge kmd .

Gamme d’équipements SRX5000 avec uniquement une carte SPC3 installée

Processus de prise en charge iked .

Gamme d’équipements SRX5000 avec carte SPC2 et SPC3 installée

Processus de prise en charge iked .

Activation des fonctionnalités VPN IPsec sur la carte de traitement des services SRX5K-SPC3

La gamme d’équipements SRX5000 avec carte SRX5K-SPC3 nécessite junos-ike un package pour installer et activer n’importe quelle fonctionnalité VPN IPsec. Par défaut, le junos-ike package est installé dans Junos OS versions 20.1R2, 20.2R2, 20.3R2, 20.4R1 et versions ultérieures pour les équipements de la gamme SRX5000 avec RE3. En conséquence iked , le ikemd processus s’exécute sur le moteur de routage par défaut au lieu du démon de gestion des clés IPsec (kmd).

Si vous souhaitez utiliser kmd le processus pour activer les fonctionnalités VPN IPsec sur la gamme d’équipements SRX5000 sans carte SPC3, vous devez exécuter la request system software delete junos-ike commande. Après avoir exécuté la commande, vous devez redémarrer l’unité.

Pour vérifier le package installé junos-ike , utilisez la commande suivante :

Prise en charge des fonctionnalités VPN IPsec sur la gamme d’équipements SRX5000 avec les instances SRX5K-SPC3 et vSRX avec nouveau package

Cette rubrique contient un résumé des fonctionnalités et configurations VPN IPsec qui ne sont pas prises en charge par les équipements de la gamme SRX5000 avec SPC3 et sur les instances vSRX.

La fonctionnalité VPN IPsec est prise en charge par deux processus, iked et ikemd sur les instances SRX5K-SPC3 et vSRX. Une seule instance de iked et ikemd s’exécutera sur le moteur de routage à la fois.

Par défaut, Junos-ike le package est installé dans Junos OS Versions 20.1R2, 20.2R2, 20.3R2, 20.4R1 et versions ultérieures pour les équipements de la gamme SRX5000 avec RE3, et le processus et ikemd le iked processus s’exécutent sur le moteur de routage.

Pour redémarrer ikemd le processus dans le moteur de routine, utilisez la restart ike-config-management commande.

Pour redémarrer iked le processus dans le moteur de routage, utilisez la restart ike-key-management commande.

Si vous souhaitez utiliser kmd le processus pour activer les fonctionnalités VPN IPsec sur la gamme d’équipements SRX5000 sans carte SPC3, vous devez exécuter la request system software delete junos-ike commande. Après avoir exécuté la commande, vous devez redémarrer l’unité.

Fonctionnalités VPN IPsec non prises en charge

Pour déterminer si une fonctionnalité est prise en charge par une plate-forme ou une version de Junos OS spécifique, reportez-vous à l’explorateur de fonctionnalités.

Tableau 5 résume les fonctionnalités VPN IPsec non prises en charge sur les équipements SRX Series et vSRX en cours d’exécution :

Tableau 5 : Fonctionnalités VPN IPsec non prises en charge sur les équipements SRX Series et les instances vSRX

Fonctionnalités

Prise en charge des équipements de la gamme SRX5000 avec les instances SRX5K-SPC3 et vSRX

VPN de découverte automatique (ADVPN).

Non

Mode PIM (AutoVPN Protocol Independent Multicast) point à multipoint.

Non

Configuration de la classe de transfert sur les VPN IPsec.

Non

Basculement de la passerelle DPD (Dead Peer Detection).

Le basculement de la passerelle DPD n’est pas pris en charge sur vSRX.

VPN de groupe.

Non

Durée de vie d’IKE SA, en kilo-octets.

Non

Configuration de la taille des paquets pour la vérification des chemins de données IPsec.

Non

VPN IPsec basé sur des stratégies.

Non

Surveillance VPN.

Non

Prise en charge des protocoles de routage sur les tunnels VPN IPsec

Nous prenons en charge des protocoles de routage comme OSPF, BGP, PIM, RIP et BFD pour les exécuter sur des tunnels IPsec sur des équipements SRX Series et des routeurs MX Series en cours d’exécution kmd ou iked de traitement. La prise en charge du protocole varie en fonction du modèle d’adressage IP ou du type d’interface st0, point à point (P2P) ou point à multipoint (P2MP).

Tableau 6 résume la prise en charge du protocole OSPF sur les équipements SRX Series et les routeurs MX.

Tableau 6 : Prise en charge du protocole OSPF sur les tunnels VPN IPsec
OSPF
Equipements P2P P2MP
IPv4 IPv6 IPv4 IPv6
SRX100, SRX110, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345, SRX380, SRX550, SRX550 HM, SRX650, SRX1400, SRX1500, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600 et SRX5K-SPC2 Oui Non Oui Non
SRX5K-SPC3 Oui Non Oui Non
SRX5K en mode mixte (SPC3 + SPC2) Oui Non Oui Non
vSRX 3.0 Oui Non Oui Non
MX-SPC3 Oui Non Non Non

Tableau 7 résume la prise en charge du protocole OSPFv3 sur les équipements SRX Series et les routeurs MX.

Tableau 7 : Prise en charge du protocole OSPFv3 sur les tunnels VPN IPsec
OSPFv3
Equipements P2P P2MP
IPv4 IPv6 IPv4 IPv6
SRX100, SRX110, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345, SRX380, SRX550, SRX550 HM, SRX650, SRX1400, SRX1500, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600 et SRX5K-SPC2 Non Oui Non Oui
SRX5K-SPC3 Non Oui Non Oui
SRX5K en mode mixte (SPC3 + SPC2) Non Oui Non Oui
vSRX 3.0 Non Oui Non Oui
MX-SPC3 Non Oui Non Non

Tableau 8 résume la prise en charge du protocole BGP sur les équipements SRX Series et les routeurs MX.

Tableau 8 : Prise en charge du protocole BGP sur les tunnels VPN IPsec
BGP
Equipements P2P P2MP
IPv4 IPv6 IPv4 IPv6
SRX100, SRX110, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345, SRX380, SRX550, SRX550 HM, SRX650, SRX1400, SRX1500, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600 et SRX5K-SPC2 Oui Oui Oui Oui
SRX5K-SPC3 Oui Oui Oui Oui
SRX5K en mode mixte (SPC3 + SPC2) Oui Oui Oui Oui
vSRX 3.0 Oui Oui Oui Oui
MX-SPC3 Oui Oui Non Non

Tableau 9 résume la prise en charge du protocole PIM sur les équipements SRX Series et les routeurs MX.

Tableau 9 : Prise en charge du protocole PIM sur les tunnels VPN IPsec
PIM
Equipements P2P P2MP
IPv4 IPv6 IPv4 IPv6
SRX100, SRX110, SRX210, SRX220, SRX240, SRX550, SRX550 HM, SRX650, SRX1400, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600 et SRX5K-SPC2 Oui Non Non Non
SRX300, SRX320, SRX340, SRX345, SRX380 et SRX1500 Oui Non Oui Non
SRX5K-SPC3 Oui Non Non Non
SRX5K en mode mixte (SPC3 + SPC2) Oui Non Non Non
vSRX 3.0 Oui Non Oui
Remarque :

Le multithread n’est pas pris en charge.

Non
MX-SPC3 Oui Non Non Non

Tableau 10 résume la prise en charge du protocole RIP sur les équipements SRX Series et les routeurs MX.

Tableau 10 : Prise en charge du protocole RIP sur les tunnels VPN IPsec
RIP
Equipements P2P P2MP
IPv4 IPv6 IPv4 IPv6
SRX100, SRX110, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345, SRX380, SRX550, SRX550 HM, SRX650, SRX1400, SRX1500, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600 et SRX5K-SPC2 Oui Oui Non Non
SRX5K-SPC3 Oui Oui Non Non
SRX5K en mode mixte (SPC3 + SPC2) Oui Oui Non Non
vSRX 3.0 Oui Oui Non Non
MX-SPC3 Oui Oui Non Non

Tableau 11 résume la prise en charge du protocole BFP sur les équipements SRX Series et les routeurs MX.

Tableau 11 : Prise en charge du protocole BFD sur les tunnels VPN IPsec
BFD
Equipements P2P P2MP
IPv4 IPv6 IPv4 IPv6
SRX100, SRX110, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345, SRX380, SRX550, SRX550 HM, SRX650, SRX1400, SRX1500, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600 et SRX5K-SPC2 Oui Oui Oui Oui
SRX5K-SPC3 Oui Oui Oui Oui
SRX5K en mode mixte (SPC3 + SPC2) Oui Oui Oui Oui
vSRX 3.0 Oui Oui Oui Oui
MX-SPC3 Oui Oui Non Non

Fenêtre anti-replay

Sur les équipements SRX Series, anti-replay-window la valeur de la fenêtre est de 64 par défaut.

Sur la gamme SRX Series 5000 d’équipements dotés de cartes SPC3, vous pouvez configurer la anti-replay-window taille entre 64 et 8192 (puissance de 2). Pour configurer la taille de la fenêtre, utilisez la nouvelle anti-replay-window-size option. Un paquet entrant est validé pour une attaque en rejeu en fonction de la anti-replay-window-size configuration.

Vous pouvez configurer replay-window-size deux niveaux différents :

  • Global level: configuré au niveau de la hiérarchie [edit security ipsec].

    Par exemple :

  • VPN object: configuré au niveau de la hiérarchie [edit security ipsec vpn vpn-name ike].

    Par exemple :

Si l’anti-replay est configuré aux deux niveaux, la taille de la fenêtre configurée pour un niveau d’objet VPN prime sur la taille de la fenêtre configurée au niveau mondial. Si la fonction anti-replay n’est pas configurée, la taille de la fenêtre est de 64 par défaut.

Pour désactiver l’option de fenêtre anti-replay sur un objet VPN, utilisez la set no-anti-replay commande au niveau de la hiérarchie [edit security ipsec vpn vpn-name ike]. Vous ne pouvez pas désactiver l’anti-replay au niveau mondial.

Vous ne pouvez pas configurer les deux anti-replay-window-size et no-anti-replay sur un objet VPN.

Comprendre les VPN en étoile

Si vous créez deux tunnels VPN qui se terminent sur un équipement, vous pouvez configurer une paire de routes afin que l’équipement dirige le trafic sortant d’un tunnel vers l’autre tunnel. Vous devez également créer une stratégie permettant au trafic de passer d’un tunnel à l’autre. Une telle disposition est connue sous le nom de VPN en étoile. (Voir Figure 4.)

Vous pouvez également configurer plusieurs VPN et router le trafic entre deux tunnels.

Les équipements SRX Series ne prennent en charge que la fonctionnalité hub-and-spoke basée sur le routage.

Figure 4 : Plusieurs tunnels dans une configuration VPN en étoilePlusieurs tunnels dans une configuration VPN en étoile
Tableau de l'historique des versions
Version
Description
20.1R2
Par défaut, le junos-ike package est installé dans Junos OS versions 20.1R2, 20.2R2, 20.3R2, 20.4R1 et versions ultérieures pour les équipements de la gamme SRX5000 avec RE3. En conséquence iked , le ikemd processus s’exécute sur le moteur de routage par défaut au lieu du démon de gestion des clés IPsec (kmd).