Trucs et astuces: Pourquoi utiliser un identifiant de proxy VPN?
Resolution
Rappelez-vous notre dilemme de la semaine dernière, où nous avons eu chevauchements sous-réseaux sur un tunnel VPN IPSec? Nous cherchions un moyen d'obtenir des réseaux peer communiquer. ID proxy à la rescousse. Si vous avez un pare-feu de réseaux de Palo Alto fonctionnant avec un VPN basé par stratégie de soutien d'homologue, vous aurez besoin des identifications de mandataire.
Discussion de la semaine dernière de la semaine (DotW) est l' aide avec les ID proxy, mais nous allons parler plus sur les ID proxy VPN et pourquoi il est important de les utiliser.
Lorsque nous parlons de tunnels VPN IPSec, si vous paramétrez le pare-feu de Palo Alto Networks pour travailler avec un homologue qui prend en charge le VPN basé sur des stratégies, vous devez définir des ID proxy. Les périphériques qui prennent en charge les VPN basés sur des stratégies utilisent des règles/stratégies de sécurité spécifiques ou des listes d'accès (adresses source, adresses de destination et ports) pour permettre un trafic intéressant via un tunnel IPSec. Ces règles sont référencées lors de la négociation Quick mode/IKE phase 2 et sont échangées en tant qu'id proxy dans le premier ou le deuxième message du processus.
Ainsi, si vous configurez le pare-feu de Palo Alto Networks pour travailler avec un homologue VPN basé sur une stratégie, pour une négociation de phase 2 réussie, vous devez définir l'ID de proxy afin que le paramètre sur les deux homologues soit identique. Si l'ID de proxy n'est pas configuré, parce que le pare-feu de Palo Alto Networks prend en charge le VPN basé sur la route, les valeurs par défaut utilisées comme ID de proxy sont IP source: 0.0.0.0/0, IP de destination: 0.0.0.0/0 et application: any; et lorsque ces valeurs sont échangées avec l'homologue, le résultat est un défaut de configuration de la connexion VPN.
Maintenant, nous allons jeter un oeil à la fenêtre ID proxy et les options:
À l'intérieur de la section ID de proxy, (situé à l'intérieur du WebGUI-réseau > IPSec tunnels > sélectionnez un tunnel > proxy ID onglet), vous verrez de nombreuses options:
- ID proxy : cliquez sur Ajouter et entrez un nom pour identifier le proxy. Peut être n'importe quel nom. Si seulement des nombres sont utilisés, il ne sera pas accepté.
- Local : Entrez une adresse IP ou un sous-réseau au format ip_address/Mask (par exemple, 10.1.2.1/24).
- Remote — si l'homologue l'exige, entrez une adresse IP ou un sous-réseau au format ip_address/Mask (par exemple, 10.1.1.1/24).
- Protocole -Spécifiez le protocole et les numéros de port pour les ports locaux et distants:
- Numéro (Number): spécifiez le numéro de protocole (utilisé pour l'interopérabilité avec les périphériques tiers).
- Any : autorise le trafic TCP et/ou UDP.
- TCP : spécifie les numéros de port TCP locaux et distants.
- UDP : spécifiez les numéros de ports UDP locaux et distants.
Remarque: chaque ID de proxy est compté comme un tunnel VPN, et donc compté vers la capacité du tunnel VPN IPSec du pare-feu. (Exemple: site-toiSite IPSec VPN Tunnel Limit-PA-3020-1000, PA-2050-100, PA-200-25)
L'avantage avec les ID proxy est la possibilité d'obtenir granulaire avec des numéros de protocole ou TCP/UDP numéros de port si vous avez un trafic spécifique que vous souhaitez parcourir le tunnel VPN uniquement. Les ID proxy permettent facilement une telle granularité.
Étant donné qu'il existe 2 versions d'IKE, le comportement avec les ID proxy est différent:
-avec IKEv1, les périphériques Palo Alto Networks ne prennent en charge que le proxy-ID exact match. Dans le cas où l'ID proxy de l'homologue ne correspondent pas, alors il y aura des problèmes avec le VPN fonctionne correctement.
-Avec IKEv2, il ya un sélecteur de trafic de soutien rétrécissement lorsque le paramètre ID proxy est différent sur les deux passerelles VPN, seul le choix implémenté est décrit dans les cas d'utilisation ci-dessous.
Cas d'Utilisation IKEv2
Veuillez consulter ci-dessous la liste des cas d'utilisation avec IPSec et IKEv2 qui peuvent aider à expliquer de nombreuses configurations VPN IPSec et comment utiliser correctement les ID de proxy.
Exemple: il existe deux passerelles VPN: a et B. IKE la négociation est lancée par le VPN GW-A. i = initiateur, r = répondeur
Supposons que le VPN GW-a défini le sélecteur de trafic TSI-a/TSr-a; Le VPN GW-b est réglé pour le sélecteur de trafic TSi-b/TSr-b. TSr-a est le même que TSr-b, de sorte qu'il peut être ignoré. TSI-a peut différer de TSI-b.
A. TSI-a est identique à TSI-b, par exemple, les deux sont 5.10.11.0/24.
ATTENDU: alors il n'y a pas de rétrécissement requis, le comportement est le même que le cas existant IKEv1 proxy ID. Le trafic ne serait pas en mesure de passer, dans cet exemple, NAT serait nécessaire pour permettre une bonne communication.
VPN GW-a: Send: TSi: 5.10.11.0-5.10.11.255
VPN GW-b: réponse: TSi: 5.10.11.0-5.10.11.255 [résultat final]
Cette solution est détaillée dans l'article DotW ici:
Aide avec l'ID de proxy
b. TSI-a est sur-ensemble de TSI -b:
B1. VPN GW-a propose TSi-a = 5.10.0.0/16; Sur le VPN GW-b: TSi-b = 5.10.11.0/24.
J’ai. Tunnel est élevé sans trafic (par exemple, pendant l'initialisation ou par la commande de test).
Attendus: comme le répondeur, VPN GW-b répond à VPN GW-a avec 5.10.11.0/24. VPN GW-a doit l'accepter et de créer CHILD SA.
VPN GW-a: Send: TSi: 5.10.0.0-5.10.255.255
VPN GW-b: réponse: TSI: 5.10.11.0-5.10.11.255 [limité au sous-ensemble commun]
II. UN hôte derrière VPN GW-a (par exemple, Host IP 5.10.11.2) tente de faire monter le tunnel.
Attendus: comme le répondeur, VPN GW-b répond à VPN GW-a avec 5.10.11.0/24. VPN GW-a doit l'accepter et de créer CHILD SA. Le trafic devrait passer.
VPN GW-a: envoi: TSi: 5.10.11.2; 5.10.0.0-5.10.255.255
VPN GW-b: réponse: TSI: 5.10.11.0-5.10.11.255 [limité au sous-ensemble commun]
Si nous sommes l'initiateur, nous n'envoyons pas le premier sélecteur de trafic spécifique (5.10.11.2) dans la charge utile IKE.
En tant que répondeur, nous devrions être en mesure de gérer l'homologue qui envoie le sélecteur de trafic spécifique. Nous allons aussi restreindre le sélecteur de trafic au sous-ensemble commun.
III. UN hôte derrière VPN GW-a (par exemple, Host IP 5.10.6.2) tente de faire monter le tunnel.
Attendus: comme le répondeur, VPN GW-b répond à VPN GW-a avec 5.10.11.0/24. VPN GW-a doit l'accepter et de créer CHILD SA.
VPN GW-a: Send: TSi: 5.10.6.2; 5.10.0.0-5.10.255.255
VPN GW-b: réponse: TSI: 5.10.11.0-5.10.11.255 [limité au sous-ensemble commun]
Si nous sommes l'initiateur, nous n'envoyons pas le premier sélecteur de trafic spécifique (5.10.6.2) dans la charge utile IKE.
En tant que répondeur, nous allons restreindre le sélecteur de trafic au sous-ensemble commun. Si la charge utile TS reçue contient le sélecteur de trafic spécifique, même si elle est hors de la stratégie locale, nous faisons toujours le rétrécissement, mais ignoré le sélecteur de trafic spécifique par RFC 5996.
B2. VPN GW-a propose TSi-a = 5.10.0.0/16; Sur le VPN GW-b: il y a plus d'une entrées définies: TSi-b = 5.10.11.0/24 + 5.10.12.0/24.
J’ai. Tunnel est élevé sans trafic.
Les entrées multiples par sélecteur de trafic sont prises en charge par strongswan. Ainsi strongswan peut être employé pour installer en tant que VPN GW-b. Si PANOS est GW-b, nous avons besoin de configurer plusieurs proxy-IDs.
VPN GW-a: Send: TSi: 5.10.0.0-5.10.255.255
VPN GW-b: réponse: TSi: 5.10.11.0-5.10.11.255 [PANOS: le sous-ensemble commun de la première entrée correspondante]
Ce qui précède montre le résultat de Panos comme le répondeur (VPN GW-b). Il répond à VPN GW-a avec l'une des entrées: 5.10.11.0/24 ou 5.10.12.0/24 (la première entrée basée sur l'ordre dans "Show VPN Tunnel", l'ordre alphabétique du nom du tunnel complet).
Certains fournisseurs (comme VPN GW-b) peuvent retourner un TS avec les deux entrées (5.10.11.0-5.10.11.255 + 5.10.12.0-5.10.12.255), mais nous n'installons que la première entrée.
II. UN hôte derrière VPN GW-a (par exemple, Host IP 5.10.11.2) tente de faire monter le tunnel.
Attendus: comme le répondeur, VPN GW-b répond à VPN GW-a avec 5.10.11.0/24. Le trafic devrait passer.
VPN GW-a: Send: TSi: 5.10.11.2; 5.10.0.0-5.10.255.255
VPN GW-b: réponse: TSI: 5.10.11.0-5.10.11.255 [Pan-OS: le sous-ensemble commun de la première entrée correspondante, préférant la politique qui peut couvrir 5.10.11.2]
Si nous sommes l'initiateur, nous n'envoyons pas le premier sélecteur de trafic spécifique (5.10.11.2) dans la charge utile IKE.
Si nous sommes le répondeur, nous cherchons tous les proxy-ID configuré jusqu'à ce qu'une entrée peut couvrir le sélecteur de trafic spécifique et peut être restreinte ou exacte correspondant. Si le sélecteur de trafic spécifique ne peut pas être couvert par le sous-ensemble commun, nous essayons encore de faire le rétrécissement.
III. Après l'étape II, un autre hôte derrière VPN GW-a (par exemple, Host IP 5.10.12.2) tente d'atteindre L'autre extrémité du VPN.
ATTENDU: comme le trafic ne correspond pas au tunnel VPN précédemment créé, une autre IPSec sa sera négociée.
VPN GW-a: Send: TSi: 5.10.12.2; 5.10.0.0-5.10.255.255
VPN GW-b: réponse: TSI: 5.10.12.0-5.10.12.255 [Panos: le sous-ensemble commun de la première entrée correspondante, préférant la politique qui peut couvrir 5.10.12.2]
À ce moment, les tunnels VPN pour les deux proxy-ID sont en place et le trafic de passage.
Certains fournisseurs ne peuvent pas démarrer une autre négociation IKE. Ils envoient des paquets utilisant le tunnel existant établi à l'étape II bien qu'il ne corresponde pas à 5.10.12.2. Nous devons vérifier tout le processus de négociation du tunnel pour analyser ce genre de comportement.
IV. UN hôte derrière le VPN GW-a (par exemple, Host IP 5.10.6.2) tente d'atteindre L'autre extrémité du VPN (sans les étapes II et III).
ATTENDU: parce qu'il n'y a pas de SA correspondant sur le VPN GW-a, il essaie de négocier avec le VPN GW-b. La réponse peut être dépendant de la mise en œuvre.
VPN GW-a: Send: TSi: 5.10.6.2; 5.10.0.0-5.10.255.255
VPN GW-b: réponse: TSi: 5.10.12.0-5.10.12.255 [PANOS: le sous-ensemble commun de la première entrée correspondante]
c. Après l'étape III, un hôte derrière VPN GW-a (par exemple, Host IP 5.10.6.2) tente d'atteindre L'autre extrémité du VPN.
L'initiateur peut utiliser un tunnel précédemment établi pour acheminer le trafic vers l'homologue. Choix du tunnel qui peut être dépendant du fournisseur.
B3. Pour le VPN GW-b qui ne supporte pas le rétrécissement du sélecteur de trafic
Certains périphériques VPN ne prennent pas en charge le rétrécissement du sélecteur de trafic, par exemple Cisco IOS 15,0 réponses NO_PROPOSAL_CHOSEN dans ce cas.
Tunnel ne peut pas être établie et la configuration doit être modifiée.
C. TSi-a est un sous-ensemble de TSr-b:
VPN GW-a propose TSi-a = 5.10.11.0/24; Sur le VPN GW-b: TSr-b = 5.10.0.0/16.
J’ai. Tunnel est élevé sans trafic.
Attendus: VPN GW-b réponses 5.10.11.0/24. Tunnel est établi en utilisant la partie commune des sélecteurs de trafic (5.10.11.0/24).
VPN GW-a: Send: TSi: 5.10.11.0-5.10.11.255
VPN GW-b: réponse: TSi: 5.10.11.0-5.10.11.255 [résultat final-le sous-ensemble commun]
II. UN hôte derrière VPN GW-a (par exemple, Host IP 5.10.11.2) tente de faire monter le tunnel.
Prévu: un tunnel avec sélecteur de trafic 5.10.11.0/24 est établi. Le trafic devrait pouvoir passer.
VPN GW-a: Send: TSi: 5.10.11.2; 5.10.11.0-5.10.11.255
VPN GW-b: réponse: TSi: 5.10.11.0-5.10.11.255 [résultat final]
Si nous sommes l'initiateur, nous n'envoyons pas le premier sélecteur de trafic spécifique (5.10.11.2) dans la charge utile IKE.
En tant que répondeur, nous devrions être en mesure de gérer l'homologue qui envoie le sélecteur de trafic spécifique. Nous allons choisir le sélecteur de trafic de l'initiateur car il est plus petit.
III. UN hôte derrière VPN GW-a (par exemple, Host IP 5.10.6.2) tente de mettre en place le tunnel
Attendu:
VPN GW-a: Send: TSi: 5.10.6.2; 5.10.11.0-5.10.11.255
VPN GW-b: réponse: TSi: 5.10.11.0-5.10.11.255 [résultat final]
Lorsque PAN-OS est l'initiateur, S'il n'y a pas d'ID proxy ou d'ID proxy unique défini sur la même interface tunnel, tunnel sera négocié comme ci-dessus et le trafic sera envoyé par le tunnel.
En cas de code proxy multiple, nous allons continuer à vérifier d'autres ID de proxy (ID de tunnel) pour voir S'il ya une correspondance. S'il n'y a pas de correspondance, le dernier ID de proxy est utilisé pour négocier le tunnel et envoyer le trafic. Il s'agit du comportement défini dans IPsec plusieurs associations de phase 2.
Si Pan-OS est le répondeur et qu'un autre fournisseur qui exécute le VPN de stratégie est l'initiateur, il peut ne pas démarrer la négociation de tunnel car le paquet est hors de la plage de sa stratégie locale. Si elle commence la négociation de tunnel, nous allons utiliser le sélecteur de trafic de l'initiateur car il est plus étroit.
D. il y a chevauchement entre TSI-a et TSr-b.
VPN GW-a propose TSi-a = 5.10.0.0/16; Sur le VPN GW-b: TSr-b = 5.10.11.0/24 + 5.9.0.0/24.
J’ai. Tunnel est élevé sans trafic.
Attendus: VPN GW-b réponses 5.10.11.0/24. Tunnel est établi en utilisant la partie commune des sélecteurs de trafic (5.10.11.0/24).
VPN GW-a: Send: TSi: 5.10.0.0-5.10.255.255
VPN GW-b: réponse: TSI: 5.10.11.0-5.10.11.255 [résultat final-le sous-ensemble superposé]
II. UN hôte derrière VPN GW-a (par exemple, Host IP 5.10.11.2) tente de faire monter le tunnel.
Prévu: un tunnel avec sélecteur de trafic 5.10.11.0/24 est établi. Le trafic devrait pouvoir passer.
VPN GW-a: Send: TSi: 5.10.11.2, 5.10.0.0-5.10.255.255
VPN GW-b: réponse: TSi: 5.10.11.0-5.10.11.255 [sous-ensemble commun]
Si nous sommes l'initiateur, nous n'envoyons pas le premier sélecteur de trafic spécifique (5.10.11.2) dans la charge utile IKE.
En tant que répondeur, nous devrions être en mesure de gérer l'homologue qui envoie le sélecteur de trafic spécifique. Nous allons aussi restreindre le sélecteur de trafic au sous-ensemble commun.
III. UN hôte derrière VPN GW-a (par exemple, Host IP 5.10.12.2-dans la politique pour le VPN GW-a, mais en dehors de la politique de VPN GW-b) tente de faire monter le tunnel.
Attendu:
VPN GW-a: Send: TSi: 5.10.12.2, 5.10.0.0-5.10.255.255
VPN GW-b: réponse: TSI: 5.10.11.0-5.10.11.255 [sous-ensemble commun]
Si Panos est l'initiateur: le répondeur ne peut pas trouver une plage qui est utile pour 5.10.12.2 de sorte qu'il retourne la plage commune (5.10.11.0/24). Tunnel peut être établi. Nous n'envoyons pas le sélecteur de trafic spécifique.
Sur la base de notre comportement existant défini dans IPSec plusieurs associations de phase 2, le paquet sera envoyé par le biais de ce tunnel, mais pourrait être supprimé par le répondeur. Le tunnel VPN d'envoi peut ne pas le remarquer.
IV. UN hôte derrière VPN GW-a (par exemple Host IP 5.9.0.2-dans la politique pour le VPN GW-b, mais en dehors de la politique de VPN GW-a) tente de faire monter le tunnel.
Attendus:
VPN GW-a: Send: TSI: 5.9.0.2, 5.10.0.0-5.10.255.255
VPN GW-b: réponse: TSI: 5.10.11.0-5.10.11.255 [sous-ensemble commun]
Si l'initiateur est PAN-OS, l'ID de proxy 0.0.0.0/0 (S'il n'y a pas d'ID de proxy défini) ou le dernier ID de proxy (dans le cas où il existe plusieurs ID proxy définis sur l'interface tunnel) est utilisé dans TSi.
Le trafic pourrait être supprimé par le répondeur (VPN basé sur une stratégie) car il viole les TS rétrécis.
Si l'initiateur effectue une vérification de stratégie VPN stricte (et non pas Pan-OS), la négociation IKE peut ne pas être déclenchée car elle enfreint la stratégie VPN.
Ça conclut les trucs et astuces. J'espère que vous avez appris quelque chose de cet article.
Comme toujours, nous saluons tous les commentaires et suggestions ci-dessous.
Restez en sécurité!
Joe Delio