Impossible de se connecter ou de Pinger une interface de pare-feu

Demande client

Lors d'une tentative d'accès ou de connexion à une adresse IP d'interface de pare-feu pour un service ou lors d'une tentative de ping de l'interface, la communication échoue.  Cela pourrait être de gérer le périphérique sur HTTPS ou SSH, de se connecter au portail GlobalProtect ou au portail Web NetConnect, ou simplement de tenter de Pinger l'interface.

Résolution

• Assurez-vous que l'interface possède le profil de gestion approprié configuré pour ce qui permet les services nécessaires et qui permet les adresses IP à partir de laquelle la connexion est effectuée.
  • Si le profil de gestion est suspect, exécutez la commande de compteur suivante et montrez les incréments de compteur: > Show Counter global Name flow_host_service_deny
• Vérifiez qu'aucune stratégie de sécurité ne bloque le trafic vers l'interface en vérifiant les journaux de trafic. Filtrer l'adresse de destination à l'adresse IP de l'interface du pare-feu. En général, une stratégie de sécurité ne bloque pas la connectivité, mais c'est possible.
  • Si l'interface atteinte est différente de l'interface que le paquet initiant pénètre dans le pare-feu, et ces deux interfaces se trouvent dans des zones différentes, alors cela serait considéré comme une session inter-zone et une stratégie de sécurité doit être présente qui permet la session.
  • Si l'interface à atteindre est la même que l'interface que le paquet initiant pénètre dans le pare-feu, alors cela serait considéré comme une session intra zone et une stratégie de sécurité n'est pas requise car les sessions intra zone sont autorisées par défaut. Toutefois, la présence d'un Deny explicitement défini à n'importe quelle stratégie de sécurité de zone remplacera la valeur par défaut Allow. Il serait alors nécessaire d'avoir une politique plus explicite qui a permis à la session d'initiation à l'interface de pare-feu.
    

Remarque: si aucun journal n'est observé pour la session d'interface, rappelez-vous que lorsque des actions par défaut sont effectuées sur des sessions inter-zones ou des sessions intra zone, il n'y a pas d'historique de trafic généré pour ce Deny ou allow (respectivement).

• Si le problème n'est toujours pas résolu, un autre problème possible est la présence d'un NAT source qui traduit l'adresse source du paquet initial vers l'adresse de l'interface qui est atteinte. Cela provoque le pare-feu de déposer le paquet dès le début dans son traitement du paquet, car après la traduction le paquet ressemble à une attaque terrestre où les adresses source et de destination sont les mêmes.
  • C'est souvent le comportement observé lors du test de connectivité au portail GlobalProtect lorsqu'il est configuré sur l'interface externe et que l'ordinateur de test se trouve sur le réseau interne, car le paquet initial sera traduit dans l'interface externe par le source NAT utilisée pour accéder à la zone externe.
  • Aucun journal de trafic ne sera vu dans ce cas car ce mécanisme se lancera avant le processus de journalisation.
  • Émettez la commande suivante pour vérifier les incréments pour voir si c'est le problème: > Show Counter global name flow_policy_nat_land
  • Pour résoudre le problème, clonez la stratégie de nat incriminée et remplacez la traduction source par «None» et l'adresse de destination par l'adresse IP de l'interface concernée, puis placez cette stratégie directement au-dessus de la stratégie NAT incriminée.  Cela empêche la traduction de se produire pour ces hôtes uniquement lorsque la destination est l'interface.
• Un autre problème qui peut être provoqué par une stratégie de NAT est si un NAT de destination est configuré pour traduire des paquets qui ont une adresse de destination en tant qu'adresse d'interface concernée dans l'adresse d'un serveur.  En général, ce NAT de destination implique l'adresse IP pubienne de l'interface externe, il existe deux configurations NAT différentes qui peuvent être rencontrés pour ce problème.
  • Si le NAT de destination est pour tous les services, alors n'importe quel paquet avec une adresse de destination comme interface qui frappe cette stratégie de NAT sera traduit même si l'intention est d'atteindre l'interface et pas l'hôte distant. Les éléments suivants pourraient résoudre ce problème:
    • Si le serveur est uniquement nécessaire pour des services spécifiques ou des ports qui sont différents, puis le port nécessaire pour atteindre l'interface de pare-feu, puis restreindre la stratégie NAT afin que seuls les services nécessaires sont traduits et transmis au serveur.
  • Si des services particuliers sont spécifiés pour ce NAT de destination, seuls les paquets qui correspondent à un port de destination avec ces services seront traduits à l'hôte et si le port 443 est parmi les services traduits par exemple, alors il n'y aura pas d'accès au port 443 sur le interface de pare-feu pour les paquets qui correspondent à la stratégie NAT de destination.  Les éléments suivants pourraient résoudre ce problème:
  • Ajoutez une autre adresse à l'interface du pare-feu s'il y a une adresse libre disponible.  Si vous ajoutez une adresse dans le même sous-réseau, le masque de sous-réseau doit être a/32.
  • L'adresse de l'interface du pare-feu doit être modifiée ou l'adresse du serveur doit être modifiée.
  • Si aucune des options ci-dessus sont des actions désirées, alors le problème est probablement dû à ne pas avoir assez d'adresses publiques pour les services offerts.  Une solution de contournement plus compliquée peut être possible, mais il peut être nécessaire d'acquérir des adresses publiques supplémentaires.
• Si aucun des ci-dessus résoudre le problème, alors il est certainement utile de vérifier les itinéraires sur les réseaux entre l'ordinateur initiateur et l'interface de pare-feu.  Vérifiez si d'autres ordinateurs peuvent accéder à l'interface du pare-feu.  Si nécessaire, faites une capture de paquets sur le pare-feu pour voir si le paquet d'amorçage atteint même le pare-feu.

Exemple de source NAT qui empêche les hôtes de la zone d'approbation d'accéder à l'adresse IP de l'interface externe:

Exemple de destination nat qui empêcherait tout accès de l'Internet à l'interface externe adresse IP:

Remarque: les résolutions ne s'appliquent pas à l'interface de gestion du pare-feu.

propriétaire : astanton