Zscaler ZPA - Arquitectura Zero Trust vs VPN Tradicional (Ivanti)
Análisis técnico basado en ZPA Client 4.8.0.115, Support Bundle del 2026-05-11, y documentación de arquitectura Zscaler.
1. Filosofía: 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 tráfico no se inspecciona de forma granular
- El túnel es un tubo opaco: todo el tráfico 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-autenticación
- Un endpoint comprometido = toda la red comprometida
- No hay inspección de los datos dentro del túnel (blind spot para DLP, malware, exfiltración)
- El túnel 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 conexión es una micro-segmentación individual: un micro-túnel por aplicación
- El tráfico se inspecciona y filtra en cada capa del stack de Zscaler
- La confianza es contextual y continua: identidad + postura del dispositivo + contexto de red + política de aplicación
Consecuencias:
- Movimiento lateral imposible por diseño (no hay red compartida)
- Un endpoint comprometido solo expone las aplicaciones autorizadas a ese usuario
- Inspección completa del tráfico en cada micro-túnel (ZIA inline si esta acoplado)
- No hay backhauling: el tráfico va directo al app connector más 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.corp.example.com) |
| - Session setup | | |
| - Micro-tunel | | O: crl.corp-example |
| orchestration | | (100.64.1.2) |
+-----------------+ +--------------------+
ZPA Client (Endpoint)
Los componentes del cliente ZPA, visibles en el bundle:
| Componente | Función | Detalle técnico |
|---|---|---|
| ZSATunnel.exe | Motor de túneles | Escucha en 8999/9009 (TCP/UDP). Establece micro-túneles DTLS o TLS hacia los Brokers. Cada app autorizada genera su propio micro-túnel (tag_id) |
| ZSAService | Servicio Windows | PID 20540. Gestiona ciclo de vida del cliente: sesiones de usuario, eventos de power, RPC con ZSATunnel. Versión 4.8.0.115, protocolo UPM Hard v28 / Soft v912 |
| ZSATrayManager | Interfaz de usuario | PID 23436. Muestra estado de conexión, notificaciones, interacción con el usuario. Conexión persistente a 165.225.92.40:443 |
| dgwip.exe | Proxy local | Escucha en 127.0.0.1:3128. Redirige tráfico HTTP/HTTPS de las apps locales a traves de los micro-túneles ZPA |
| zsawdrv.sys | Driver WFP (kernel) | Filtra tráfico a nivel de Windows Filtering Platform. 3,505 filtros activos. Intercepta conexiones salientes y las redirige por los micro-túneles |
| ZSAHelper | Proceso auxiliar | Spawn multipisodos por ZSATunnel para operaciones puntuales (registration, health checks) |
ZPA Broker (Cloud)
Los Brokers son la pieza central de la orquestación ZPA:
- No son proxys — no ven el tráfico de datos. Solo orquestan el establecimiento de micro-túneles
- Autentican al usuario via SAML/IdP
- Negocian las claves de sesión entre Client y App Connector
- Asignan el App Connector óptimo (basado en proximidad, carga, health)
- Una vez el micro-túnel esta establecido, el tráfico fluye directamente entre Client y App Connector (sin pasar por el Broker)
Brokers observados en el bundle:
165.225.101.236(Broker primario)198.51.100.10(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 aplicación: recibe tráfico del micro-túnel y lo reenvia al backend
- Las apps nunca están expuestas a Internet
ZPA Domain Cache
El cliente resuelve dominios internos a traves de ZPA, no via DNS local:
srv-app01.ad.corp.example.com -> 100.64.1.1 (TTL 180s)
crl.corp-example -> 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-Túneles
Esta es la diferencia arquitectonica más significativa con VPN.
VPN: Un túnel = Toda la red
[Cliente] ==== Tunel VPN (1 solo tunel) ==== [Firewall/Router] --> Red interna completa
- Todo el tráfico (DNS, HTTP, SMB, RDP, etc.) va por el mismo túnel
- 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 túnel es “all or nothing”: conectado o desconectado
ZPA: Un micro-túnel por aplicación
[Cliente] -- micro-tunel tag 65537 --> crl.corp-example (via App Connector A)
[Cliente] -- micro-tunel tag 65538 --> crl.corp-example (via App Connector A)
[Cliente] -- micro-tunel tag 65539 --> app1.ad.corp.example.com (via App Connector B)
[Cliente] -- micro-tunel tag 65540 --> app2.ad.corp.example.com (via App Connector B)
...
[Cliente] -- micro-tunel tag 65545 --> app7.ad.corp.example.com (via App Connector C)
- Cada aplicación autorizada genera su propio micro-túnel DTLS/TLS
- El cliente nunca ve la red — solo ve las aplicaciones que la política permite
- No hay IP interna virtual — el tráfico se redirige via WFP hooks y el proxy local (dgwip.exe)
- Los micro-túneles se crean y destruyen dinamicamente segun las aplicaciones que el usuario accede
- Si una app no tiene política, el micro-túnel 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-túneles cerrados en 7 segundos. Cada uno era una aplicación distinta. En VPN, un fallo de túnel desconectaria todo de golpe.
4. Protocolo DTLS vs TLS en ZPA
ZPA intenta establecer micro-túneles 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 tráfico interactivo (RDP, SSH, terminales)
- Cada micro-túnel es una sesión 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-túnel es una conexión TCP con TLS
- Mayor latencia por TCP handshake + TLS handshake por micro-túnel
- 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 degradación a TLS funciona como mecanismo de supervivencia, pero el rendimiento es inferior.
- Windows Filtering Platform (WFP) - Como ZPA Intercepta Tráfico
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
- zsawdrv.sys registra callouts en WFP (capas FWPM_LAYER_ALE_*)
- Cuando una aplicación intenta conectar a un destino, WFP invoca el callout de ZPA
- ZPA evalua si el destino pertenece a un App Segment configurado
- Si si: ZPA redirige la conexión a traves del micro-túnel correspondiente
- Si no: la conexión sale por la red normal (split tunnel automático)
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 198.51.100.10, 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 también usa WFP (o adaptadores virtuales con drivers de miniport). Cuando ambos están 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 tráfico ZPA
- Resultado: DTLS timeout (el paquete UDP de ZPA es interceptado por el driver de Ivanti y no llega al Broker)
6. Comparativa Técnica Detallada
| Dimension | Ivanti VPN (Pulse Secure) | Zscaler ZPA |
|---|---|---|
| Modelo | Tunnel-based (castle-and-moat) | Zero Trust (micro-perimeter) |
| Acceso | Red completa o segmentos | Aplicaciones individuales |
| Túneles | 1 túnel por sesión | N micro-túneles por aplicación |
| Capa de interceptación | Adaptador virtual (miniport driver) | WFP callouts (kernel-level) |
| Protocolo | IPSec o SSL/TLS sobre TCP | DTLS (UDP) con fallback TLS |
| Inspección de tráfico | No (túnel opaco) | Si (integrable con ZIA inline) |
| Exposición de red | El cliente ve subredes internas | El cliente nunca ve la red |
| IP interna | Si (IP virtual asignada) | No (resolución via ZPA Domain Cache, IPs 100.64.x.x) |
| DNS | DNS del servidor VPN | ZPA Domain Cache (resolución por app) |
| Puertos entrantes | Firewall abre puertos para VPN gateway | App Connector solo outbound (no puertos entrantes) |
| Lateral movement | Posible post-auth | Imposible por diseño |
| Split tunnel | Manual (por rutas) | Automático (por política de app) |
| Resiliencia | Túnel cae = todo cae | Fallo de micro-túnel no afecta otros |
| MTU | Fijo (configurado) | Adaptativo (1300 → 1200 con DTLS fallback) |
| Auth | Certificado + credenciales | SAML/IdP + postura de dispositivo |
| Offline | Sin acceso | Modo offline para apps configuradas |
| Backhauling | Si (tráfico al datacenter y de vuelta) | No (tráfico directo al app connector) |
| Escalabilidad | Limitada por capacidad del gateway VPN | Horizontal (más app connectors sin bottleneck) |
- Por qué ZPA Es Considerado “Software de los Más Sofisticados”
7.1. Arquitectura de tres planos
ZPA separa completamente tres planos que en VPN están acoplados:
- Plano de control: ZPA Admin + Brokers (orquestación, políticas, session setup)
- Plano de datos: Micro-túneles Client ←> App Connector (tráfico de aplicaciones)
- Plano de inspección: ZIA (si esta integrado, inspecciona el tráfico dentro de los micro-túneles)
En VPN, el gateway es todo en uno: control + datos + (a veces) inspección. 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-túnel 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-segmentación por aplicación
- Cada app es un micro-perimetro independiente
- Un usuario puede tener 7 micro-túneles activos (tag 65539-65545 como en el bundle)
- Comprometer un micro-túnel no da acceso a los demas
- La política puede variar por usuario, dispositivo, localización, 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 pública que escanear (Shodan no encuentra nada)
- Los Brokers no ven el tráfico de datos (solo orquestan claves)
7.5. Postura del dispositivo como factor de autenticación
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-túneles en tiempo real. En el bundle: FQDN_NO_MATCH denego el registro del cliente porque el hostname no coincidia con las políticas.
7.6. Integración con ZIA (inspección inline)
ZPA puede acoplar cada micro-túnel con ZIA (Zscaler Internet Access) para:
- Inspección de malware en descargas
- DLP (Data Loss Prevention) en uploads
- Filtrado de URLs
- Inspección TLS/SSL (man-in-the-middle autorizado)
- Sandbox de ficheros desconocidos
Esto convierte cada micro-túnel de “tubo opaco” a “tubo inspeccionado” — algo imposible en VPN tradicional sin romper el túnel.
- 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 más complejo del cliente. Intercepta, redirige, y protege todo el tráfico a nivel de kernel. El error FwpsFlowAssociateContext0 failed indica que la asociación de contexto de flujo fallo — un evento que en un entorno sin conflicto debería ser raro.
8.2. Los micro-túneles 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-túnel de forma independiente. Si la política no existe, ese micro-túnel 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 crítico
La degradación 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 (198.51.100.10) solo interviene en el setup del micro-túnel. Una vez establecido, el tráfico 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:
-
Dependencia de WFP — Cualquier otro driver WFP (como Ivanti) puede interferir. ZPA no tiene control sobre el orden de prioridad de sublayers de terceros.
-
FQDN_NO_MATCH es frágil — El mecanismo de validación de hostname es estricto y no tiene modo de fallback. Si el FQDN del equipo cambia (ej. roaming entre dominios), ZPA rechaza el registro.
-
Split VPN deshabilitado rompe coexistencia — Con
enableSplitVpnTN: 0, ZPA no detecta túneles VPN existentes y compite por recursos. ZPA asume que es el único agente de túneles en el sistema. -
Agotamiento de puertos — Los micro-túneles consumen puertos origen. Con muchas apps activas y otro consumidor de puertos (Ivanti), ZPHM (Zscaler Port Hole Mapper) reporta “Source port not available”.
-
DNS propio puede fallar — Los 21 fallos DNS para
pac.zscloud.netmuestran que si el DNS de ZPA es inalcanzable, ZPA no puede determinar si la red es trusted, afectando el perfil de forwarding. -
Sin política = sin acceso —
crl.corp-examplefue rechazada por error 5011. Si el administrador no creo la política, la app es inaccesible incluso con ZPA funcionando perfectamente. Es feature (least privilege) pero requiere configuración precisa.
10. Referencias
- Zscaler ZPA Architecture: https://help.zscaler.com/zpa
- NIST SP 800-207: Zero Trust Architecture
- ZPA Client 4.8.0.115 Release Notes
- Bundle source:
Zscaler-2026-05-11-13-13-21.zip(extraido en/opt/data/cache/zpa-logs/) - Análisis forense asociado: Analisis Forense - Colision ZPA e Ivanti
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, diagnóstico 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)