Tunnel fendu et plein de GlobalProtect provoque des utilisateurs de se connecter via SSL sur le bouclage

Demande client

Sous réseau > GlobalProtect > portails il sont deux passerelles de GlobalProtect ; Gateway1 (GW1) a pris fin l’ethernt1/1 de l’interface physique IP 88.88.88.88 et Gateway2 (GW2) a pris fin le loopback IP 1.1.1.1.  Sous l’onglet Client Configuraion, GW1 est utilisé pour le tunnel de Split et GW2 pour tunnel complet, comme indiqué ci-dessous :

À l’intérieur des informations utilisateur pour GW2, constate que les utilisateurs qui se connectent sur la passerelle de GlobalProtect terminée sur l’interface de bouclage seront toujours connecte via SSL, (bien que les utilisateurs à l’aide de GW1 peuvent se connecter via IPSec).

Cause

Ce comportement est attendu. Le client GlobalProtect fera une connexion VPN SSL pour adresse IP 88.88.88.88 sur le port 443 pour tunnel de Split ou l’adresse IP 88.88.88.88 sur le port 444 (utilisant un NAT à 1.1.1.1 le port 443) pour tunnel complet, selon quelle configuration de client GlobalProtect l’utilisateur connexion matches. Avec les connexions respectives étant réussie, GlobalProtect puis fera une connexion IPSec sur port 4501 en interne. La connexion de port et l’adresse IP interne restera la même, par exemple 88.88.88.88 sur port 4501 fois Split et complet du tunnel.

Cette demande peut être reçue par tunnel de Split sur la physique de l’interface ethernet 1/1, soit en plein tunnel sur l’interface de bouclage par NATing 88.88.88.88:4501 à 1.1.1.1:4501. Split et tunnel complet ne peut pas recevoir la demande de IPSec.

Pour plus d'informations sur GlobalProtect avec une passerelle, Split et Full tunnel, référencez le document suivant: utilisation de Global Protect avec une passerelle et les deux Split-Full tunnel

propriétaire : csharma