Comment faire pour résoudre les problèmes IPSec VPN des problèmes de connectivité

Ce document est destiné à aider à résoudre les problèmes de connectivité VPN IPSec. Il est divisé en deux parties, une pour chaque Phase d’un VPN IPSec.

Phase 1

• Afin d’exclure les questions liées à l’ISP, essayez ping l’IP par les pairs de l’interface externe du PA. Veiller à ce que les pings sont activées sur l’interface externe de l’homologue.
• Si ping ont été bloquées par les exigences de sécurité, voir si les autres pairs répondant pour les mode principal/agressif des messages ou la DPD. Recherchez les réponses des messages « Es-tu là ? » de l’homologue dans les journaux système sous l’onglet moniteur, ou dans des journaux ikemgr.
• Vérifier que l’identité de IKE est correctement configurée.
• Vérifier que la politique est en place pour permettre des applications IKE et IPSec. Habituellement, cette stratégie n’est pas nécessaire s’il n’y a aucune règle de nettoyage configurée sur la boîte. Si une règle de nettoyage est configurée, la stratégie est configurée habituellement de la zone extérieure à la zone externe.
• Vérifier que les propositions sont correctes. Si incorrect, journaux sur l’incompatibilité se trouvent dans les journaux système, ou en utilisant la commande CLI suivante :

  > moins MP-log ikemgr. log  

• Vérifiez que la clé pré-partagée est correcte. Si incorrect, journaux sur l’incompatibilité se trouvent dans les journaux système, ou en utilisant la commande CLI suivante :

  > moins MP-log ikemgr. log  

• Prendre le paquet de captures pour analyser le trafic. Utiliser des filtres pour restreindre la portée du trafic capturé.
  
  
• Utiles commandes CLI :

> Show VPN IKE-sa Gateway <name> 
> test VPN IKE-sa Gateway <name>
> Debug IKE stat</name> </name>

Commandes avancées de CLI :

• Pour la journalisation détaillée, tourner sur le niveau de journalisation de débogage :

> Debug IKE global sur Debug
> moins MP-log ikemgr. log

• Pour afficher les négociations de mode principal/agressive et rapide, il est possible d’activer pcaps pour capturer ces négociations. Messages 5 et 6, dans le mode principal et tous les paquets en mode rapide ont leur charge utile de données chiffrée :

> Debug IKE PCAP on
> View-PCAP no-DNS-Lookup oui non-port-Lookup Oui Debug-PCAP ikemgr. PCAP

• Mettez hors tension débogue

> Debug IKE PCAP OFF 

Configuration des captures et filtre de paquets limite pcaps seulement à la debug travaillée, une montre de pcap IKE sur pcaps pour tout le trafic VPN.

Pour vérifier si le NAT-T est activé, les paquets seront sur le port 4500 au lieu de 500 des 5ème et 6ème messages de mode principal.

Vérifiez si le code fournisseur de l’homologue est pris en charge sur le dispositif de Palo Alto Networks et vice versa.

Phase 2

• Vérifiez si les pare-feu négocient les tunnels et s’assurer qu’il existe 2 SPIs unidirectionnels :

> Voir VPN IPSec-sa
> Show VPN IPSec-sa tunnel <tunnel.name></tunnel.name> 

• Vérifiez si les propositions sont correctes. Si incorrect, journaux sur l’incompatibilité se trouvent dans les journaux système sous l’onglet moniteur, soit en utilisant la commande suivante :

> moins MP-log ikemgr. log  

• Vérifier si pfs est activé sur les deux extrémités. Si incorrect, journaux sur l’incompatibilité se trouvent dans les journaux système sous l’onglet moniteur, ou en utilisant la commande :

>  moins MP-log ikemgr. log  

• Vérifiez la configuration de proxy-id. Ce n'est généralement pas nécessaire lorsque le tunnel est entre deux pare-feu Palo Alto Networks, mais lorsque l'homologue est d'un autre fournisseur, les ID doivent généralement être configurés.
  Une incompatibilité serait indiquée sous les journaux système ou en utilisant la commande:

> moins ikemgr.log mp-Journal

• Utiles commandes CLI :

> afficher le nom du flux VPN <tunnel.id unnel.name=""> 
> afficher le nom du flux VPN <tunnel.id unnel.name="">| octets de correspondance</tunnel.id> </tunnel.id>

• Vérifier si l’encapsulation et décapsulation octets sont multiplient. Si le pare-feu transmet le trafic, puis les deux valeurs devraient être en augmentation.

> afficher le nom du flux VPN <tunnel.id unnel.name="">| octets de correspondance</tunnel.id>

Si les octets de l’encapsulation sont multiplient et décapsulation est constante, le pare-feu est envoi mais ne pas réception de paquets.

• Vérifier si une politique est à la baisse du trafic, ou si un port traduisant l’appareil devant PAN qui pourrait tomber les paquets ESP.

> afficher le nom du flux VPN <tunnel.id unnel.name="">| octets de correspondance</tunnel.id>

Si octets de décapsulation sont multiplient et l’encapsulation est constante, alors le pare-feu est reçu mais ne pas transmission de paquets.

• Vérifier si une politique est à la baisse du trafic :

> test Routing FIB-Lookup Virtual-Router IP par défaut <destination ip=""> 
 --------------------------------------------------
Runtime Lookup route
--------------------------------------------------
Virtual-Router: destination par défaut
 : 10.5.1.1
résultat: interface tunnel. 1

> Show Routing route
> test VPN IPSec-sa <name></name> tunnel        </destination>

Advanced CLI commandes:
> Debug IKE global sur Debug
> moins MP-log ikemgr. log
> Debug IKE PCAP on
> View-PCAP no-DNS-Lookup oui non-port-Lookup Oui Debug-PCAP ikemgr. PCAP
> Debug IKE PCAP OFF    

Si les tunnels sont en hausse mais le trafic n’est pas passant par le tunnel :

• Vérifier la politique de sécurité et de routage.
• Vérifiez tous les périphériques en amont qui effectuent le port-et-adresse-traductions. Parce que l’ESP est un protocole de couche 3, les paquets ESP n’ont pas de numéros de port. Lorsque ces dispositifs reçoivent les paquets ESP, il y a une possibilité élevée, ils peuvent les déposer en silence, parce qu’ils ne voient pas les numéros de port à traduire.
• Appliquer les filtres de paquets de débogage, des captures ou des journaux, si nécessaire, pour isoler le problème où le trafic est obtenir supprimé.

propriétaire : Dany