Cuando las aplicaciones publicadas mediante RD Web en Windows Server 2012 R2 dejan de abrirse de un día para otro, la sensación de urgencia es inmediata: los usuarios se autentican sin problemas, el archivo .rdp se descarga, comienza a ejecutarse y, justo antes de mostrar la sesión, aparece un mensaje de error que les obliga a cerrar; en los visores de eventos no hay registros claros y, según el personal de TI, “nada ha cambiado”. En realidad, algo sí cambió—solo que fuera de la granja RDS. Este artículo explica cómo diagnosticar y resolver la desconexión de aplicaciones en RD Web cuando la causa es un ajuste en la VPN (u otros dispositivos de red), basándose en un caso real y aportando un método de trabajo reproducible.

Escenario típico y síntoma principal

En una granja RDS clásica sobre Windows Server 2012 R2 conviven:

• Servidores Broker, Gateway, Web y Licensing.
• Uno o varios hosts RDSH (Remote Desktop Session Host) donde residen las aplicaciones.
• Un firewall perimetral y, muy a menudo, uno o más túneles VPN para dar servicio a usuarios remotos o sedes secundarias.

El problema aparece así:

1. El usuario accede a https://rdweb.midominio.tld/RDWeb, introduce credenciales corporativas y ve el listado habitual de aplicaciones.
2. Al hacer clic sobre una aplicación, el portal genera y entrega el archivo .rdp.
3. El cliente de Escritorio Remoto lo abre, se muestra fugazmente “Configurando la conexión…” y enseguida un diálogo de error («No se puede conectar al equipo remoto» o similar).

Razones frecuentes tras la desconexión

Una caída repentina de este tipo casi siempre se debe a uno de estos factores:

• Caducidad o sustitución de certificados en Gateway o Broker.
• Cambios de contraseña del usuario que aún no han llegado a la sesión RDP cacheada.
• Actualizaciones de seguridad que alteran TLS, CredSSP o políticas de canal seguro.
• Saturación de recursos (CPU/RAM) en los roles de la granja.
• Ajustes de red: reglas de firewall, listas de control de acceso (ACL) o, como en el caso que nos ocupa, una reconfiguración de la VPN.

Resumen del caso real

Durante varios días la granja funcionó con normalidad. Tras un fin de semana, los usuarios que se conectaban a través de la VPN corporativa descubrieron que ninguna aplicación publicada iniciaba. Internamente, el equipo de sistemas comprobó:

• Visores de eventos en Broker, Gateway y RDSH sin errores.
• Sin alertas de rendimiento ni de licencia.
• Sin actualizaciones instaladas desde la última revisión.

Finalmente se confirmó que el equipo de comunicaciones había migrado el túnel de la VPN a nuevo hardware. El perfil creado por defecto en el nuevo dispositivo bloqueaba tráfico saliente/entrante no explícitamente permitido. En consecuencia, los puertos RDS dejaban de estar accesibles en el momento en que el cliente RDP intentaba la conexión posterior al portal.

Una vez añadidos los puertos y protocolos RDS a las reglas de la VPN, las aplicaciones se abrieron sin incidencias.

Estrategia de diagnóstico paso a paso

Comprobar conectividad de red

Antes de profundizar en la capa de aplicación, confirma que los puertos RDS son alcanzables desde un cliente afectado. Las herramientas básicas (ping, telnet, Test-NetConnection en PowerShell) detectan al instante un bloqueo:

Test-NetConnection -ComputerName gateway.midominio.tld -Port 3389
Test-NetConnection -ComputerName broker.midominio.tld -Port 443 -InformationLevel "Detailed"

Si alguno de los puertos devuelve “TcpTestSucceeded: False”, detente y revisa el recorrido paquete a paquete.

Revisar certificados y componentes RDS

Abre Remote Desktop Management Services en el Broker y usa la pestaña Deployment Properties para verificar:

• Fecha de expiración de cada certificado.
• Coincidencia de nombres (CN/SAN) con el FQDN usado por los clientes.

Después reinicia, en este orden, los servicios RD Connection Broker, RD Web Access y RD Gateway para descartar estados “fantasma”.

Supervisar recursos del servidor

Aún con puertos y certificados correctos, una granja saturada puede denegar nuevas sesiones. Ejecuta perfmon o Get-Counter para vigilar:

• % Processor Time > 80 % sostenido.
• Memoria disponible < 500 MB.
• Disco con latencia > 20 ms.

Probar desde otro cliente y fuera de la VPN

Conecta un equipo portátil directamente a la LAN (o mediante 4G) y repite la apertura de la aplicación. Si funciona, la sospecha recae oficialmente sobre la VPN.

Auditar cambios recientes en red o seguridad

No subestimes la comunicación interdepartamental. Pregunta al área de redes:

• ¿Hubo migración de firewalls o concentradores de VPN?
• ¿Se aplicó un nuevo template de seguridad que filtre puertos por defecto?
• ¿Modificaron rutas estáticas o NAT que afecten al rango de la granja?

Puertos y protocolos que deben permanecer abiertos

Puerto	Protocolo	Rol RDS	Descripción
443	TCP	Gateway / Web	Autenticación, canal seguro de gestión
3389	TCP	RDSH / Broker	Tráfico RDP tradicional
3391	UDP	Gateway	UDP Transport para RemoteFX/AVD
5985	TCP	Todos los roles	WinRM para administración
80	TCP	Web (opcional)	Redirección HTTP→HTTPS

Comprobaciones específicas en Windows Server 2012 R2

• TLS 1.2: Asegúrate de que esté habilitado si algún cliente moderno lo exige; la desalineación de versiones TLS provoca fallos silenciosos.
• Hotfixes para CredSSP: Windows Server 2012 R2 recibió parches que invalidan conexiones sin canal cifrado actualizado.
• Política de seguridad “Restrict NTLM”: Si el dominio la endurece, el cliente podría no delegar credenciales.

Inspección de la capa de red y VPN

En el caso real, el concentrador VPN sustituyó una regla “permitir todo LAN ↔ Servidor RDS” por “permitir solo puertos esenciales de dominio”. El tráfico RDP (3389/TCP y 3391/UDP) quedó fuera. Para confirmar:

1. Captura paquetes en el cliente con netsh trace start capture=yes scenario=internetClient.
2. Inicia la aplicación publicada.
3. Detén la traza y abre el archivo .etl con Microsoft Message Analyzer o Wireshark.
4. Filtra por tcp.port == 3389 o udp.port == 3391; si solo ves paquetes Client Hello sin respuesta, el bloqueo es total.

Buenas prácticas para evitar reincidencias

• Documentar rutas y puertos en un diagrama actualizado al que tengan acceso redes y sistemas.
• Establecer ventanas de cambio coordinadas: antes de aplicar plantillas de firewall o reemplazar hardware, la granja RDS debe tener su propio punto de control.
• Configurar alertas de salud en el Broker y Gateway usando Performance Monitor y Event Log; un disparador que detecte “failed connection” repetida puede avisar al NOC en minutos.
• Automatizar pruebas sintéticas: con mstsc /shadow o scripts de PowerShell que levanten una sesión RDP cada hora y reporten disponibilidad al sistema de monitoreo.

Conclusión

Los problemas de desconexión en RD Web sobre Windows Server 2012 R2 rara vez se originan en un único punto. Sin embargo, cuando los síntomas aparecen de forma súbita y sin cambios aparentes en los servidores, es prudente empezar por la ruta de red. En el caso estudiado, la causa fue un ajuste de VPN que interrumpió puertos críticos. El método propuesto—validar conectividad, certificados, recursos del servidor y, sobre todo, coordenadas de red—acorta radicalmente el tiempo de reparación. Mantén un registro de cambios exhaustivo y comunica cualquier actualización de infraestructura para que el servicio de aplicaciones publicadas permanezca estable y disponible.