Tengo una máquina con Windows Server 2012 (no R2), alojada en la virtualización Hyper-V con RD Session Host y RD Gateway instalados. Se utiliza para ejecutar una aplicación SIG de escritorio.
El rendimiento a través de WAN es bastante pobre. Agregué un puerto UDP a NAT para mejorar el rendimiento, pero la conexión UDP todavía no se utiliza.
En el entorno de prueba de LAN (para evitar configuraciones erróneas de NAT/firewall), me conecto desde una máquina Win10. La barra de información de conexión muestra "excelente calidad", pero no menciona nada sobre UDP. En el caso de la conexión inversa (Windows Server => Windows 10), la barra de información de conexión dice que UDP está habilitado.
Apagué por completo el Firewall de Windows instalado en Windows Server. Verifiqué dos veces que el transporte UDP esté habilitado en RD Gateway. No hay diferencia si me conecto usando Gateway (443+3391) o Direct (3389+3389). Reinicié toda la máquina dos veces y me desplacé por todos los enlaces en las primeras tres páginas de resultados de Google.
¿Tienes alguna idea de lo que puede estar mal?
Respuesta1
Sospecho que hay un error de ruta. Ejecute un Wirehark para asegurarse de que se reciba el paquete UDP. Como vi, es a través de una WAN, el enrutador generalmente no permite bien los paquetes.
1.5 Prerrequisitos/Condiciones previas
Los puntos finales del protocolo requieren que se establezca conectividad UDP. La ruta de red entre los puntos finales debería permitir la transferencia de datagramas UDP en ambas direcciones.
Los requisitos previos para este protocolo son idénticos a los del protocolo UDP.
1.3.2.1
Inicialización de la conexión UDP En esta fase, ambos puntos finales se inicializan con parámetros mutuamente aceptables para la conexión. El cliente terminal inicia la conexión enviando un datagrama SYN. El cliente terminal también determina el modo de operación, RDP-UDP-R o RDP-UDP-L, como se describe en la sección 1.3.1. El servidor de terminal responde con un datagrama con el indicador SYN configurado, junto con un indicador ACK, para acusar recibo del datagrama SYN. El cliente terminal reconoce el datagrama SYN enviando un ACK. El cliente terminal puede adjuntar los paquetes codificados junto con el datagrama ACK. Este datagrama indica que se ha establecido una conexión y se pueden intercambiar datos. Todos los datagramas en esta fase (SYN, SYN+ACK y ACK) se entregan de manera confiable mediante retransmisiones persistentes, independientemente del modo en el que esté operando el transporte.
Respuesta2
¿Ha comprobado que UDP pueda pasar a través del servidor host Hyper-v?
Si es posible, intente utilizar un tipo de adaptador de red virtual alternativo en el administrador de conmutador virtual y/o que los ajustes de configuración del adaptador de red físico identifiquen cualquier configuración relacionada con UDP que pueda estar desactivada.
Respuesta3
Estuve buscando este problema durante bastante tiempo y no pude encontrar la solución en ningún otro lugar. La misma situación que la tuya, la conexión directa al servidor RDS no funcionó con el transporte UDP. UDP 3391 estaba escuchando y no estaba bloqueado por el firewall. Otros servidores que no son RDS funcionaron con transporte UDP.
Configuré el siguiente GPO, lo ejecuté gpupdate /target:Computer /forcey listo, está funcionando.
Establecer Computer Configuration > Remote Desktop Services > Remote Desktop Session Host > Security > Require use of specific security layer for remote (RDP) connectionsen Habilitado (SSL)