GlobalProtect actualizaciones de cliente que no se pueden completar.

GlobalProtect actualizaciones de cliente que no se pueden completar.

55360
Created On 03/08/19 08:16 AM - Last Modified 03/26/21 18:21 PM


Symptom


GlobalProtect se configura en el portal para permitir las actualizaciones de cliente de forma transparente o manual. Cuando la actualización se inicia de forma manual o transparente, el proceso se inicia pero no se completa.

Environment


GlobalProtect con la actualización del cliente permitida en la configuración del portal (transparente o manual).

Cause


El problema es específicamente si el portal y las puertas de enlace se hospedan en IP direcciones diferentes, ya que el GlobalProtect cliente intentará descargar la actualización desde el portal a través del GlobalProtect túnel.

Los siguientes errores muestran que la actualización se inicia, pero se produce un error en la descarga de archivos.
 
(T14088) 03/08/19 17:31:50:199 Error( 291): CPanHTTPSession::SendRequest: WinHttpSendRequest failed with error 12002.
(T14088) 03/08/19 17:31:50:199 Error( 148): DownloadURLToFile: download failed
(T14088) 03/08/19 17:31:50:199 Error( 361): CPanHTTPSession::DownloadData: WinHttpQueryHeaders failed with error 12019.
(T14088) 03/08/19 17:31:50:199 Error( 167): DownloadURLToFile: cancel download
(T14088) 03/08/19 17:31:50:199 Info (2375): DownloadProc: download file failed.



Las cosas a comprobar son:
  • Cuando el cliente está conectado a la puerta de enlace, debe poder resolver el nombre de host del portal.Si los DNS servidores cambian cuando están conectados a la puerta de enlace y, por alguna razón, no pueden resolver el nombre de host del portal, se producirá un error en la descarga del archivo.
  • Si la resolución de nombres funciona bien, debe haber un policy para permitir el acceso del portal a través del túnel en la puerta de enlace.Como se ve en los registros abajo, antes de que el GlobalProtect cliente esté conectado, el portal (192.168.0.1) se accede directamente pero una vez que el cliente está conectado el tráfico pasa a través del GlobalProtect túnel y como no hay seguridad se policy deniega el tráfico.

Registros de tráfico:
GlobalProtect Registros
  1. El acceso al portal a través del navegador muestra que la conexión está permitida en este caso, ya que es directamente de L3-Trust a L3-Trust.
  2. Una vez que el GlobalProtect cliente está conectado, el acceso al portal vía el navegador se bloquea porque el tráfico es de la GP L3- zona que es para el túnel y no hay regla para permitir el GlobalProtect tráfico.

Topología de prueba:
Esto fue probado usando un solo firewall con el gateway configurado en la interfaz L3-Trust y el portal configurado en una interfaz loopback también en el L3-Trust pero una dirección diferente al IP gateway.
Los puntos clave son el gateway y el portal son direcciones diferentes IP y las rutas de acceso proporcionadas al cliente significan que el tráfico al portal se GlobalProtect rutea a través del túnel cuando GlobalProtect está conectado.

Seguridad de policy prueba:
GlobalProtect Seguridad policy
Se permite la conectividad del portal y del gateway para el cliente tal como ambos están en la zona L3-Trust.
Una vez que el cliente se conecte estará en la GP zona L3. El policy permite la zona L3-a GP L3-Untrust pero no L3-Trust que es la zona donde está la dirección de loopback del portal.
 


Resolution


  1. Asegúrese de que el cliente todavía puede resolver el nombre de host del portal cuando está conectado a la puerta de enlace.
  2. Asegúrese de que la seguridad policy en la puerta de enlace permitirá la conectividad desde el cliente GlobalProtect IP /Zone al portal.


Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000boIFCAY&lang=es&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

Choose Language