Al implementar Cisco Secure Access VPN, los clientes Jabber experimentan problemas de conectividad debido a conflictos de resolución de registros DNS SRV. El problema ocurre cuando Jabber llega a dos registros DNS SRV: uno para CUCM (_cisco-UDS) y otro para ExpressWay (_collab-edge). Si el registro SRV de CUCM se resuelve, independientemente de si funciona, Jabber asume que se encuentra en las instalaciones e intenta conectarse a CUCM en lugar de a ExpressWay. Este comportamiento es evidente en el registro de Jabber con bEdgeServerFlag = 0 visto en Jabber.log. Además, el registro SRV de ExpressWay falla porque se envía al servidor DNS privado que Secure Client utiliza para la resolución y el servidor DNS privado no encuentra este registro SRV público de forma recursiva.
Cisco Secure Access (anteriormente Cisco AnyConnect Secure Mobility Client)
cliente Cisco Jabber
Cisco Unified Communications Manager (CUCM)
Cisco ExpressWay para acceso móvil y remoto
Infraestructura DNS con servidores DNS públicos y privados
Configuración de túnel VPN con capacidades de túnel dividido
El problema se resolvió enrutando el tráfico de Jabber a través del túnel VPN en lugar de intentar configurar manualmente el cliente para la conectividad de ExpressWay. Este enfoque garantiza que el tráfico de Jabber utilice la ruta de resolución de DNS adecuada y evita el conflicto de registro SRV que hace que el cliente asuma incorrectamente la conectividad en las instalaciones.
Paso 1: Analice las consultas de registro DNS SRV mediante la captura de paquetes de Wireshark.
Use Wireshark filter: dns.qry.type == 33
Paso 2: Revisar los registros de Jabber para ver el estado del indicador del servidor perimetral
Check Jabber.log for: bEdgeServerFlag = 0
Paso 3: Verificar el comportamiento de la resolución DNS para ambos registros SRV
Compruebe la resolución de:
_registro SRV de Cisco-UDS (CUCM)
_collab-edge SRV record (ExpressWay)
Configure el cliente VPN Cisco Secure Access para incluir el tráfico Jabber en el túnel en lugar de permitirle resolver consultas DNS a través del servidor DNS local/privado. Esto garantiza que:
El tráfico de Jabber utiliza la ruta de resolución DNS correcta
Se evitan los conflictos de registros SRV
La conectividad de ExpressWay está establecida correctamente
Se mantiene la funcionalidad completa de Jabber
Esta solución es preferible a la configuración manual del cliente Jabber para ExpressWay, lo que provocaría la pérdida de alguna funcionalidad.
La causa raíz es la lógica de resolución de registros DNS SRV en clientes Jabber. Cuando se inicia Jabber, consulta dos registros DNS SRV específicos: _cisco-UDS (para CUCM) y _collab-edge (para ExpressWay). El proceso de toma de decisiones del cliente da prioridad al registro SRV de CUCM. Si este registro se resuelve correctamente, Jabber asume que funciona en un entorno local y establece bEdgeServerFlag = 0, independientemente de si la conexión de CUCM real funciona o si el registro SRV de ExpressWay también se resuelve.
En escenarios de VPN con tunelización dividida, el registro SRV de ExpressWay (_collab-edge) se envía al servidor DNS privado utilizado por Secure Client. Dado que normalmente se trata de un registro DNS público y que el servidor DNS privado no realiza búsquedas recursivas de registros externos, la resolución SRV de ExpressWay falla. Este problema compuesto hace que Jabber no pueda establecer una conectividad adecuada a través de ninguna de las rutas.
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
1.0 |
04-May-2026
|
Versión inicial |