Sammi De Blas | Knowledge Base

Zscaler ZPA - Arquitectura Zero Trust vs VPN Tradicional

Se lee en 13 min

Zscaler ZPA - Arquitectura Zero Trust vs VPN Tradicional (Ivanti)

Analisis tecnico basado en ZPA Client 4.8.0.115, Support Bundle del 2026-05-11, y documentacion de arquitectura Zscaler.

1. Filosofia: Modelo de Confianza

VPN Tradicional (Ivanti/Pulse Secure)

La VPN opera bajo el modelo de castillo y foso (castle-and-moat):

  • El usuario autenticado obtiene acceso completo a la red interna (o al segmento asignado)
  • Una vez dentro, el trafico no se inspecciona de forma granular
  • El tunel es un tubo opaco: todo el trafico va cifrado de extremo a extremo, el contenido es invisible para los controles de seguridad intermedios
  • La confianza es binaria: dentro/fuera. Si estas dentro, eres de confianza

Consecuencias:

  • Movimiento lateral sin restricciones post-autenticacion
  • Un endpoint comprometido = toda la red comprometida
  • No hay inspeccion de los datos dentro del tunel (blind spot para DLP, malware, exfiltracion)
  • El tunel consume ancho de banda completo (backhauling)

Zscaler ZPA (Zero Trust)

ZPA opera bajo el modelo de confianza minima (least privilege):

  • El usuario nunca obtiene acceso a la red — solo a aplicaciones especificas
  • Cada conexion es una micro-segmentacion individual: un micro-tunel por aplicacion
  • El trafico se inspecciona y filtra en cada capa del stack de Zscaler
  • La confianza es contextual y continua: identidad + postura del dispositivo + contexto de red + politica de aplicacion

Consecuencias:

  • Movimiento lateral imposible por diseño (no hay red compartida)
  • Un endpoint comprometido solo expone las aplicaciones autorizadas a ese usuario
  • Inspeccion completa del trafico en cada micro-tunel (ZIA inline si esta acoplado)
  • No hay backhauling: el trafico va directo al app connector mas cercano

2. Arquitectura ZPA - Componentes

                          +------------------+
                          |  ZPA Admin       |
                          |  (Cloud)         |
                          |  - Politicas     |
                          |  - App segments  |
                          |  - Enrollment    |
                          +--------+---------+
                                   |
                          API / Policy sync
                                   |
              +--------------------+--------------------+
              |                                         |
     +--------v--------+                     +----------v----------+
     |  ZPA Client     |                     |  App Connector      |
     |  (Endpoint)     |                     |  (Datacenter/Cloud) |
     |  - ZSATunnel    |<---Micro-tunel---->|  - Proxy de app     |
     |  - ZSAService   |    (DTLS/TLS)       |  - Registrado en    |
     |  - ZSATray      |                     |    ZPA Controller   |
     |  - WFP Driver   |                     |  - Outbound-only    |
     +--------+--------+                     +----------+----------+
              |                                         |
              | ZPN Tunnel                              | App traffic
              | (per-micro-tunel)                        | (to backend)
              |                                         |
     +--------v--------+                     +----------v----------+
     |  ZPA Broker      |                     |  Backend App       |
     |  (Cloud)         |                     |  (v8128svc008.     |
     |  - Auth & auth   |                     |   ad.bbva.com)     |
     |  - Session setup |                     |                    |
     |  - Micro-tunel   |                     |  O: crl.igrupobbva |
     |    orchestration |                     |  (100.64.1.2)      |
     +-----------------+                     +--------------------+

ZPA Client (Endpoint)

Los componentes del cliente ZPA, visibles en el bundle:

ComponenteFuncionDetalle tecnico
ZSATunnel.exeMotor de tunelesEscucha en 8999/9009 (TCP/UDP). Establece micro-tuneles DTLS o TLS hacia los Brokers. Cada app autorizada genera su propio micro-tunel (tag_id)
ZSAServiceServicio WindowsPID 20540. Gestiona ciclo de vida del cliente: sesiones de usuario, eventos de power, RPC con ZSATunnel. Version 4.8.0.115, protocolo UPM Hard v28 / Soft v912
ZSATrayManagerInterfaz de usuarioPID 23436. Muestra estado de conexion, notificaciones, interaccion con el usuario. Conexion persistente a 165.225.92.40:443
dgwip.exeProxy localEscucha en 127.0.0.1:3128. Redirige trafico HTTP/HTTPS de las apps locales a traves de los micro-tuneles ZPA
zsawdrv.sysDriver WFP (kernel)Filtra trafico a nivel de Windows Filtering Platform. 3,505 filtros activos. Intercepta conexiones salientes y las redirige por los micro-tuneles
ZSAHelperProceso auxiliarSpawn multipisodos por ZSATunnel para operaciones puntuales (registration, health checks)

ZPA Broker (Cloud)

Los Brokers son la pieza central de la orquestacion ZPA:

  • No son proxys — no ven el trafico de datos. Solo orquestan el establecimiento de micro-tuneles
  • Autentican al usuario via SAML/IdP
  • Negocian las claves de sesion entre Client y App Connector
  • Asignan el App Connector optimo (basado en proximidad, carga, health)
  • Una vez el micro-tunel esta establecido, el trafico fluye directamente entre Client y App Connector (sin pasar por el Broker)

Brokers observados en el bundle:

  • 165.225.101.236 (Broker primario)
  • 87.58.87.247 (Broker secundario)
  • 165.225.93.176:443 (SME — Signing and Management Engine)

App Connector (Datacenter)

  • Se despliega dentro de la red corporativa (on-prem o cloud)
  • Solo hace conexiones outbound hacia los Brokers — no abre puertos entrantes
  • Cada App Connector se registra con el ZPA Controller
  • Proxy inverso de la aplicacion: recibe trafico del micro-tunel y lo reenvia al backend
  • Las apps nunca estan expuestas a Internet

ZPA Domain Cache

El cliente resuelve dominios internos a traves de ZPA, no via DNS local:

v8128svc008.ad.bbva.com -> 100.64.1.1 (TTL 180s)
crl.igrupobbva          -> 100.64.1.2 (TTL 180s)

Las IPs 100.64.x.x son direcciones RFC 6598 (CGNAT) usadas por ZPA como direcciones virtuales. No son IPs reales del backend — son identificadores logicos que ZPA mapea internamente al App Connector correcto.

3. Arquitectura de Micro-Tuneles

Esta es la diferencia arquitectonica mas significativa con VPN.

VPN: Un tunel = Toda la red

[Cliente] ==== Tunel VPN (1 solo tunel) ==== [Firewall/Router] --> Red interna completa
  • Todo el trafico (DNS, HTTP, SMB, RDP, etc.) va por el mismo tunel
  • El cliente obtiene una IP interna virtual (ej. 10.x.x.x)
  • El cliente tiene visibilidad de toda la subred (o las subredes del split-tunnel)
  • El tunel es “all or nothing”: conectado o desconectado

ZPA: Un micro-tunel por aplicacion

[Cliente] -- micro-tunel tag 65537 --> crl.igrupobbva (via App Connector A)
[Cliente] -- micro-tunel tag 65538 --> crl.igrupobbva (via App Connector A)
[Cliente] -- micro-tunel tag 65539 --> app1.ad.bbva.com (via App Connector B)
[Cliente] -- micro-tunel tag 65540 --> app2.ad.bbva.com (via App Connector B)
...
[Cliente] -- micro-tunel tag 65545 --> app7.ad.bbva.com (via App Connector C)
  • Cada aplicacion autorizada genera su propio micro-tunel DTLS/TLS
  • El cliente nunca ve la red — solo ve las aplicaciones que la politica permite
  • No hay IP interna virtual — el trafico se redirige via WFP hooks y el proxy local (dgwip.exe)
  • Los micro-tuneles se crean y destruyen dinamicamente segun las aplicaciones que el usuario accede
  • Si una app no tiene politica, el micro-tunel se rechaza (error 5011 BRK_MT_SETUP_FAIL_NO_POLICY_FOUND)

Evidencia en los logs del bundle

La cascada de desconexiones del 11/05 demuestra la granularidad:

11:11:21 - BRK_MT_CLOSED_FROM_ASSISTANT tag 65539
11:11:22 - BRK_MT_CLOSED_FROM_ASSISTANT tag 65540
11:11:23 - BRK_MT_CLOSED_FROM_ASSISTANT tag 65541
11:11:24 - BRK_MT_CLOSED_FROM_ASSISTANT tag 65542
11:11:25 - BRK_MT_CLOSED_FROM_ASSISTANT tag 65543
11:11:26 - BRK_MT_CLOSED_FROM_ASSISTANT tag 65544
11:11:28 - BRK_MT_CLOSED_FROM_ASSISTANT tag 65545

7 micro-tuneles cerrados en 7 segundos. Cada uno era una aplicacion distinta. En VPN, un fallo de tunel desconectaria todo de golpe.

4. Protocolo DTLS vs TLS en ZPA

ZPA intenta establecer micro-tuneles sobre DTLS (Datagram TLS) primero, y fallback a TLS si DTLS falla.

DTLS (preferido)

  • Basado en UDP — sin overhead deconexion TCP (3-way handshake, ACKs, retransmisiones)
  • Menor latencia — optimal para trafico interactivo (RDP, SSH, terminales)
  • Cada micro-tunel es una sesion DTLS independiente
  • En el bundle: DTLS falla sistematicamente (error 10060 timeout, 18 intentos, 0 exitosos) debido a interferencia WFP/VPN

TLS (fallback)

  • Basado en TCP — fiable pero con mayor overhead
  • Connection-oriented — cada micro-tunel es una conexion TCP con TLS
  • Mayor latencia por TCP handshake + TLS handshake por micro-tunel
  • En el bundle: ZPA opera en TLS fallback como estado final

El ciclo de fallo DTLS observado

Ciclo 1 (11:08:01 - 11:08:17):
  FailureCount 0 -> Timeout (error 10060) -> MTU 1300
  FailureCount 1 -> Timeout
  ...
  FailureCount 5 -> Timeout -> Retrials exhausted
  DTLS -> TLS fallback event raised

Ciclo 2 (11:09:01 - 11:09:17):
  MTU 1200 -> mismo patron -> TLS fallback

Ciclo 3 (11:10:51 - 11:11:07):
  MTU 1200 -> mismo patron -> TLS fallback

La degradacion a TLS funciona como mecanismo de supervivencia, pero el rendimiento es inferior.

5. Windows Filtering Platform (WFP) - Como ZPA Intercepta Trafico

ZPA no crea adaptadores de red virtual como las VPN. En su lugar, usa el driver WFP (zsawdrv.sys) para interceptar conexiones a nivel de kernel.

Mecanismo

  1. zsawdrv.sys registra callouts en WFP (capas FWPM_LAYER_ALE_*)
  2. Cuando una aplicacion intenta conectar a un destino, WFP invoca el callout de ZPA
  3. ZPA evalua si el destino pertenece a un App Segment configurado
  4. Si si: ZPA redirige la conexion a traves del micro-tunel correspondiente
  5. Si no: la conexion sale por la red normal (split tunnel automatico)

Filtros observados en el bundle

3,505 filtros WFP cargados

Primeros 8 filtros: DROP en puertos 8999/9009 (TCP/UDP, IPv4/IPv6)
  -> Protegen los puertos de escucha de ZSATunnel de conexiones externas

Filtros de bypass: tráfico ZPA a IPs destino 87.58.87.247, 165.225.93.176, etc.
  -> Permiten que el tráfico de control de ZPA no sea interceptado por otros filtros

El conflicto con Ivanti

Ivanti VPN tambien usa WFP (o adaptadores virtuales con drivers de miniport). Cuando ambos estan activos:

  • Ambos registran callouts en las mismas capas WFP
  • El orden de prioridad depende del sublayer weight
  • ZPA reporta: Desired sublayer weight is not assigned. Assigned weight = 65532
  • Si Ivanti tiene un sublayer weight mayor, sus filtros se ejecutan antes y pueden bloquear el trafico ZPA
  • Resultado: DTLS timeout (el paquete UDP de ZPA es interceptado por el driver de Ivanti y no llega al Broker)

6. Comparativa Tecnica Detallada

DimensionIvanti VPN (Pulse Secure)Zscaler ZPA
ModeloTunnel-based (castle-and-moat)Zero Trust (micro-perimeter)
AccesoRed completa o segmentosAplicaciones individuales
Tuneles1 tunel por sesionN micro-tuneles por aplicacion
Capa de interceptacionAdaptador virtual (miniport driver)WFP callouts (kernel-level)
ProtocoloIPSec o SSL/TLS sobre TCPDTLS (UDP) con fallback TLS
Inspeccion de traficoNo (tunel opaco)Si (integrable con ZIA inline)
Exposicion de redEl cliente ve subredes internasEl cliente nunca ve la red
IP internaSi (IP virtual asignada)No (resolucion via ZPA Domain Cache, IPs 100.64.x.x)
DNSDNS del servidor VPNZPA Domain Cache (resolucion por app)
Puertos entrantesFirewall abre puertos para VPN gatewayApp Connector solo outbound (no puertos entrantes)
Lateral movementPosible post-authImposible por diseño
Split tunnelManual (por rutas)Automatico (por politica de app)
ResilienciaTunel cae = todo caeFallo de micro-tunel no afecta otros
MTUFijo (configurado)Adaptativo (1300 → 1200 con DTLS fallback)
AuthCertificado + credencialesSAML/IdP + postura de dispositivo
OfflineSin accesoModo offline para apps configuradas
BackhaulingSi (trafico al datacenter y de vuelta)No (trafico directo al app connector)
EscalabilidadLimitada por capacidad del gateway VPNHorizontal (mas app connectors sin bottleneck)

7. Por Que ZPA Es Considerado “Software de los Mas Sofisticados”

7.1. Arquitectura de tres planos

ZPA separa completamente tres planos que en VPN estan acoplados:

  • Plano de control: ZPA Admin + Brokers (orquestacion, politicas, session setup)
  • Plano de datos: Micro-tuneles Client ←> App Connector (trafico de aplicaciones)
  • Plano de inspeccion: ZIA (si esta integrado, inspecciona el trafico dentro de los micro-tuneles)

En VPN, el gateway es todo en uno: control + datos + (a veces) inspeccion. Un punto de fallo.

7.2. Never-fail architecture

  • App Connectors se despliegan en pares (active-active)
  • Si un App Connector falla, el Broker redirige el micro-tunel al otro
  • Los Brokers operan en multiples regiones (observados: 165.225.x.x y 87.58.x.x)
  • El cliente fallback de DTLS a TLS, y de un Broker a otro

7.3. Micro-segmentacion por aplicacion

  • Cada app es un micro-perimetro independiente
  • Un usuario puede tener 7 micro-tuneles activos (tag 65539-65545 como en el bundle)
  • Comprometer un micro-tunel no da acceso a los demas
  • La politica puede variar por usuario, dispositivo, localizacion, y hora

7.4. Zero exposed attack surface

  • App Connectors solo hacen conexiones outbound al Broker
  • No hay puertos abiertos en el datacenter accesibles desde Internet
  • No hay IP publica que escanear (Shodan no encuentra nada)
  • Los Brokers no ven el trafico de datos (solo orquestan claves)

7.5. Postura del dispositivo como factor de autenticacion

ZPA evalua continuamente:

  • Disco cifrado (BitLocker)
  • Antivirus actualizado
  • Patch level del OS
  • Certificado de dispositivo (DeviceToken)
  • Dominio del equipo (FQDN matching)
  • Presencia de software de gestion (Tanium, SCCM)

Si la postura cambia, ZPA puede revocar micro-tuneles en tiempo real. En el bundle: FQDN_NO_MATCH denego el registro del cliente porque el hostname no coincidia con las politicas.

7.6. Integracion con ZIA (inspeccion inline)

ZPA puede acoplar cada micro-tunel con ZIA (Zscaler Internet Access) para:

  • Inspeccion de malware en descargas
  • DLP (Data Loss Prevention) en uploads
  • Filtrado de URLs
  • Inspeccion TLS/SSL (man-in-the-middle autorizado)
  • Sandbox de ficheros desconocidos

Esto convierte cada micro-tunel de “tubo opaco” a “tubo inspeccionado” — algo imposible en VPN tradicional sin romper el tunel.

8. Lo Que Los Logs Del Bundle Ensenan Sobre ZPA

8.1. El WFP driver es el corazon del cliente

Con 3,505 filtros, zsawdrv.sys es el componente mas complejo del cliente. Intercepta, redirige, y protege todo el trafico a nivel de kernel. El error FwpsFlowAssociateContext0 failed indica que la asociacion de contexto de flujo fallo — un evento que en un entorno sin conflicto deberia ser raro.

8.2. Los micro-tuneles son discretos y efímeros

La secuencia BRK_MT_SETUP_FAIL_NO_POLICY_FOUND (tag 65537, 65538) para crl.empresa.com demuestra que cada app intenta abrir su micro-tunel de forma independiente. Si la politica no existe, ese micro-tunel falla pero los demas siguen funcionando.

8.3. El Domain Cache es fundamental

ZPA no usa el DNS del sistema para resolver aplicaciones internas. Usa su propio Domain Cache con TTL de 180s. Las IPs 100.64.x.x son virtuales — ZPA las asigna internamente y las mapea al App Connector correcto via protocolo ZPN.

8.4. DTLS es preferido pero no critico

La degradacion DTLS → TLS es un feature, no un bug. Pero el rendimiento es diferente:

  • DTLS: latencia baja, sin head-of-line blocking
  • TLS: latencia alta, head-of-line blocking, pero fiable

8.5. El Broker no es un proxy

Los logs muestran que el Broker (87.58.87.247) solo interviene en el setup del micro-tunel. Una vez establecido, el trafico fluye directamente entre Client y App Connector. Esto lo diferencia radicalmente de un proxy HTTP que procesaria cada request.

9. Limitaciones de ZPA (Contexto del Bundle)

ZPA no es perfecto. Los logs revelan debilidades reales:

  1. Dependencia de WFP — Cualquier otro driver WFP (como Ivanti) puede interferir. ZPA no tiene control sobre el orden de prioridad de sublayers de terceros.

  2. FQDN_NO_MATCH es fragil — El mecanismo de validacion de hostname es estricto y no tiene modo de fallback. Si el FQDN del equipo cambia (ej. roaming entre dominios), ZPA rechaza el registro.

  3. Split VPN deshabilitado rompe coexistencia — Con enableSplitVpnTN: 0, ZPA no detecta tuneles VPN existentes y compite por recursos. ZPA asume que es el unico agente de tuneles en el sistema.

  4. Agotamiento de puertos — Los micro-tuneles consumen puertos origen. Con muchas apps activas y otro consumidor de puertos (Ivanti), ZPHM (Zscaler Port Hole Mapper) reporta “Source port not available”.

  5. DNS propio puede fallar — Los 21 fallos DNS para pac.zscloud.net muestran que si el DNS de ZPA es inalcanzable, ZPA no puede determinar si la red es trusted, afectando el perfil de forwarding.

  6. Sin politica = sin acceso — crl.igrupobbva fue rechazada por error 5011. Si el administrador no creo la politica, la app es inaccesible incluso con ZPA funcionando perfectamente. Es feature (least privilege) pero requiere configuracion precisa.

10. Referencias

Nota generada por Hermes Agent

Prompt

Hola de esta nota que viene de unos logs reales descargados de Zscaler ZPA, no sé sabrias darme una hoja de ruta sencilla para ver con tantos logs primero que archivos mirar y descartar innecesarios y posteriormente como hacer un filtrado de palabras clave para identificar fallos errores, diagnostico etc… a mano (típico filtrado con Notepad++ por ejemplo o no se si se puede hacer con la herramienta de Chrome que chrome://net-internals (o brave://net-internals)

Vista Gráfica