RDP entre oficinas sin puertos abiertos: la configuración segura «RDP solo vía VPN»

Qué significa realmente «RDP solo vía VPN»

«RDP solo vía VPN» no es una sensación. Es un conjunto concreto de controles:

• Sin exposición pública de RDP. No «seguridad por oscuridad» con un puerto distinto. No «solo IPs en lista blanca» en la WAN. Simplemente no.
• RDP escucha solo en interfaces internas (o, más prácticamente, las reglas de firewall hacen cumplir que sea accesible únicamente desde la subred de la VPN).
• La VPN es la única vía de ingreso desde la Oficina A a la Oficina B para tráfico de gestión.
• Controles de identidad y dispositivo en la VPN, idealmente MFA y dispositivos vinculados a certificados.
• Registro que puedas usar. No una casilla para marcar. Telemetría real que te diga quién se conectó, desde dónde y si falló.

Por qué «simplemente abrir 3389» da vergüenza profesional

RDP es un objetivo de alto valor. No es personal; es economía. A los atacantes les gusta RDP porque es ubicuo, ofrece acceso interactivo y a menudo conduce directamente al robo de credenciales o ransomware.
Exponerlo públicamente significa que tus defensas deben ser perfectas todos los días. Tu adversario solo necesita que estés cansado una vez.

Modelo de amenaza en un párrafo

Los riesgos principales son stuffing de credenciales, intentos de fuerza bruta, explotación de fallos relacionados con RDP, movimiento lateral una vez dentro y la clásica mala configuración.
La VPN no hace que RDP sea «seguro». Hace que RDP sea privado, luego debes endurecer RDP y la red circundante para que una compromesa no se convierta en un evento a nivel empresa.

Una cita que vale la pena mantener en un post-it:
«La esperanza no es una estrategia.» — Gen. Gordon R. Sullivan

Broma #1: Exponer 3389 en Internet es como dejar la puerta de tu oficina abierta porque instalaste un felpudo mejor. A los ladrones les encanta la mejora.

Hechos interesantes y un poco de historia

Conocer el contexto te ayuda a hacer mejores concesiones. Aquí hay puntos concretos que suelen sorprender incluso a equipos de TI:

1. RDP existe desde los años 90. Surgió en la era de Terminal Services de Microsoft, mucho antes de que «zero trust» fuera un tema de presentaciones.
2. TCP/3389 se volvió un imán de escaneo porque es predecible. La automatización de ataques prospera sobre valores por defecto. Mucha «radiación de fondo» de Internet son bots tocando esa puerta.
3. Network Level Authentication (NLA) cambió el juego. NLA fuerza la autenticación antes de crear una sesión de escritorio completa, reduciendo abuso de recursos y algunas clases de superficie de ataque pre-auth.
4. El robo de credenciales, no los fallos del protocolo, es la ruta habitual. En muchos incidentes reales, RDP es simplemente el punto de entrada conveniente después de adivinar o reutilizar contraseñas.
5. La «seguridad» de RDP y la usabilidad luchan constantemente. Desactivar NLA o permitir ajustes TLS antiguos suele suceder porque «una aplicación de un proveedor no funciona», y así empieza la putrefacción.
6. Las VPN pasaron de appliances hardware a túneles definidos por software. Las cajas IPsec solían ser lo habitual; hoy WireGuard y stacks modernos IKEv2 son comunes porque los equipos de operaciones quieren configuraciones más simples y observables.
7. «Cambiar el puerto de RDP» no es seguridad real. Reduce el ruido aleatorio, no a atacantes determinados, y puede romper herramientas y auditorías.
8. El rendimiento de RDP depende mucho de la latencia y pérdida de paquetes. El ancho de banda importa, pero 30–60 ms de latencia y pequeñas tasas de pérdida pueden hacer que la sesión parezca escribir a través de pudín.

Opciones de arquitectura: sitio-a-sitio vs acceso remoto

Opción A: VPN sitio-a-sitio entre oficinas (recomendada para RDP «oficina a oficina»)

Si el requisito es «desde la Oficina A hacia servidores en la Oficina B», una VPN sitio-a-sitio es lo más limpio. Crea un dominio de enrutamiento privado y controlado entre ambas redes.
Entonces puedes permitir RDP solo desde subredes origen específicas o hosts de salto sobre esa VPN.

Obtienes control centralizado, menos piezas móviles en endpoints y enrutamiento predecible. También obtienes la responsabilidad de mantener el enrutamiento ajustado para que tu VPN no se convierta accidentalmente en una red plana que lo permita todo en todas partes.

Opción B: VPN de acceso remoto para usuarios individuales

Esto es «laptops de usuarios que se conectan a la oficina central». A menudo es necesario, pero cambia tu problema.
Ahora validas postura del dispositivo, debates sobre split-tunnel y gestionas redes móviles. No es malo, solo distinto.

Opción C: RDP Gateway (útil, pero no «sin puertos abiertos»)

RDP Gateway envuelve RDP en HTTPS y centraliza el acceso. Puede hacerse de forma segura, pero típicamente requiere exponer 443 (al menos) a Internet.
Si tu requisito es explícitamente «sin puertos entrantes abiertos», RDP Gateway no es tu herramienta principal. Es una arquitectura distinta.

Recomendación con opinión

Para «entre oficinas», construye una VPN sitio-a-sitio y aplica «RDP solo desde la subred VPN» en los firewalls de Windows.
Añade un host de salto (o mejor, dos) y obliga a los administradores a RDP al host de salto y desde allí hacia los servidores. Así mantienes RDP accesible y el radio de daño pequeño.

Línea base recomendada: WireGuard sitio-a-sitio con listas de permitidos estrictas para RDP

Diseño de red de referencia

• Office A LAN: 10.10.0.0/16
• Office B LAN: 10.20.0.0/16
• WireGuard tunnel subnet: 10.99.0.0/24
• Office A VPN gateway: office-a-vpn (Linux)
• Office B VPN gateway: office-b-vpn (Linux)
• Windows jump host en Office B: jump-b01 (10.20.10.10)
• Objetivos RDP en Office B: DCs/servidores de aplicaciones según sea necesario

Estrategia de enrutamiento que no te hará daño después

Mantén el túnel estrecho. Enruta solo lo que necesites. Evita «0.0.0.0/0 a través del túnel» para sitio-a-sitio a menos que disfrutes explicarle a finanzas por qué las llamadas de Teams suenan como un submarino.

El modelo limpio:

• Office A enruta 10.20.0.0/16 a través del túnel.
• Office B enruta 10.10.0.0/16 a través del túnel.
• El firewall de Windows en Office B permite TCP/3389 solo desde 10.10.0.0/16 (o, mejor, solo desde la subred de salto de Office A).

NAT: evítalo a menos que debas

El NAT dentro de una VPN sitio-a-sitio es como crear misterios futuros. Puede ser necesario si las subredes se solapan (más adelante hablaremos), pero si puedes evitarlo, hazlo.
Las VPN enrutadas con subredes distintas son más fáciles de razonar, depurar y auditar.

Esqueleto de configuración de WireGuard

WireGuard es simple por diseño. Eso es una característica. La mayoría de fallos no están en WireGuard; están en el enrutamiento y los firewalls alrededor de él.

cr0x@server:~$ sudo cat /etc/wireguard/wg0.conf
[Interface]
Address = 10.99.0.1/24
ListenPort = 51820
PrivateKey = <redacted>

# Route Office B LAN through the tunnel
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT

[Peer]
PublicKey = <redacted>
AllowedIPs = 10.99.0.2/32, 10.20.0.0/16
PersistentKeepalive = 25

Observa lo que importa: AllowedIPs es tanto enrutamiento como política. Si por accidente permites 0.0.0.0/0, acabas de decirle a tu gateway que acepte «todo» de ese peer.
Eso puede estar bien en un laboratorio. En producción es un incidente esperando a un becario aburrido con Wireshark.

Endurecimiento de RDP: las partes que evitan incidentes

1) Restringir quién puede alcanzar RDP (controles de red)

No confíes en «contraseñas fuertes» como primera barrera. Tu primera barrera es: solo la subred de la VPN (o un host de salto) puede siquiera iniciar un handshake TCP.
RDP que no se puede alcanzar no puede ser atacado por fuerza bruta.

2) Requerir NLA y cifrado moderno

Habilita NLA. Haz cumplir TLS. Desactiva capas de seguridad legadas si puedes. Sí, encontrarás un producto antiguo de un proveedor que se queja. Tu trabajo es hacer que eso sea su problema, no tu brecha.

3) Usa hosts de salto, no «RDP por todas partes»

Crea un enclave de gestión: uno o dos hosts Windows endurecidos que sean los únicos sistemas permitidos para RDP hacia los servidores.
Los admins RDP al host de salto vía VPN, y desde allí RDP a los objetivos internos.

Esto reduce la exposición de credenciales (menos endpoints tocando contextos de admin de dominio) y concentra los registros para que sean más útiles.

4) Identidad: mínimo privilegio, MFA y flujos de trabajo administrativos sensatos

MFA pertenece en la VPN. Si tu VPN no puede hacer MFA, reemplázala o pon una puerta frontal consciente de identidad delante.
En Windows, usa cuentas de administrador separadas, elimina membresías innecesarias del grupo Administradores locales y trata el acceso RDP como un permiso controlado, no como un derecho de nacimiento.

5) Registro y alertas: decide qué investigarás

Querrás saber:

• Eventos de peer VPN arriba/abajo y churn de handshakes.
• Logones exitosos y fallidos en Windows vía RDP (logon type 10).
• Denegaciones del firewall para 3389 (para ver misrutas).

Manténlo accionable. Registrar todo sin retención ni revisión es solo un olvido caro.

Tareas prácticas: comandos, salidas y decisiones

A continuación hay tareas prácticas que puedes ejecutar en gateways VPN Linux y hosts Windows para validar «RDP solo vía VPN», diagnosticar lentitud y probarte a ti mismo que no construiste una puerta trasera.
Cada tarea incluye: comando, salida de ejemplo, qué significa y la decisión que tomas a partir de ello.

Tarea 1: Confirmar el estado de la interfaz WireGuard

cr0x@server:~$ sudo wg show
interface: wg0
  public key: qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq=
  listening port: 51820

peer: ppppppppppppppppppppppppppppppppppppppppp=
  endpoint: 203.0.113.20:51820
  allowed ips: 10.99.0.2/32, 10.20.0.0/16
  latest handshake: 34 seconds ago
  transfer: 1.28 GiB received, 2.02 GiB sent
  persistent keepalive: every 25 seconds

Significado: El handshake está reciente; el alcance de enrutamiento está limitado a la IP del túnel + la LAN de Office B. Los contadores de transferencia muestran tráfico real.

Decisión: Si «latest handshake» tiene minutos/horas, arregla la alcanzabilidad (UDP, NAT, IP del endpoint) antes de tocar RDP.

Tarea 2: Validar rutas del kernel para la LAN remota

cr0x@server:~$ ip route show | grep 10.20.0.0
10.20.0.0/16 dev wg0 proto static scope link

Significado: El gateway enviará el tráfico de Office B al túnel, no al gateway por defecto.

Decisión: Si falta esta ruta, RDP nunca llegará. Arregla AllowedIPs de WireGuard o añade rutas explícitas.

Tarea 3: Confirmar que el reenvío está habilitado (sitio-a-sitio lo requiere)

cr0x@server:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Significado: El host Linux enruta paquetes entre interfaces.

Decisión: Si es 0, habilita el reenvío; si no, tu VPN es una decoración costosa.

Tarea 4: Revisar reglas de firewall en el gateway VPN (camino de forward)

cr0x@server:~$ sudo iptables -S FORWARD
-P FORWARD DROP
-A FORWARD -i wg0 -o eth0 -d 10.20.0.0/16 -j ACCEPT
-A FORWARD -i eth0 -o wg0 -s 10.20.0.0/16 -j ACCEPT

Significado: Drop por defecto con allow explícito entre wg0 y la LAN. Así es como se ve un «enrutamiento ajustado».

Decisión: Si FORWARD es DROP por defecto sin las reglas allow, tu handshake estará arriba pero los paquetes no pasarán. Añade reglas específicas, no «ACCEPT all».

Tarea 5: Verificar que NO haya NAT (a menos que lo hayas planeado)

cr0x@server:~$ sudo iptables -t nat -S | head
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT

Significado: No hay reglas NAT presentes. Bueno para enrutamiento limpio y logs precisos.

Decisión: Si ves reglas MASQUERADE para tráfico VPN, confirma que sea necesario (subredes solapadas). Si no es necesario, elimínalo para evitar confusión de «quién es esta IP» más adelante.

Tarea 6: Probar alcanzabilidad al puerto RDP desde el lado Office A

cr0x@server:~$ nc -vz 10.20.10.10 3389
Connection to 10.20.10.10 3389 port [tcp/ms-wbt-server] succeeded!

Significado: El camino de red y el firewall de Windows permiten TCP/3389 desde tu origen.

Decisión: Si hace timeout, es enrutamiento/firewall. Si aparece «refused», el host es alcanzable pero el servicio RDP está caído o bloqueado localmente.

Tarea 7: Confirmar que RDP no sea alcanzable desde Internet público (prueba negativa)

cr0x@server:~$ nc -vz 198.51.100.45 3389
nc: connect to 198.51.100.45 port 3389 (tcp) failed: Connection timed out

Significado: Bien. La IP pública no responde en 3389. Los timeouts suelen ser preferibles a «refused» porque revelan menos.

Decisión: Si tiene éxito, detente. Has expuesto RDP. Ciérralo en el firewall perimetral y verifica que no haya port-forwarding ni reglas de security group en la nube filtrándolo.

Tarea 8: Medir latencia y pérdida sobre el túnel (la sensación de RDP depende de esto)

cr0x@server:~$ ping -c 10 10.20.10.10
PING 10.20.10.10 (10.20.10.10) 56(84) bytes of data.
64 bytes from 10.20.10.10: icmp_seq=1 ttl=127 time=23.9 ms
64 bytes from 10.20.10.10: icmp_seq=2 ttl=127 time=24.1 ms
64 bytes from 10.20.10.10: icmp_seq=3 ttl=127 time=24.3 ms
64 bytes from 10.20.10.10: icmp_seq=4 ttl=127 time=24.0 ms
64 bytes from 10.20.10.10: icmp_seq=5 ttl=127 time=26.8 ms
64 bytes from 10.20.10.10: icmp_seq=6 ttl=127 time=24.2 ms
64 bytes from 10.20.10.10: icmp_seq=7 ttl=127 time=24.1 ms
64 bytes from 10.20.10.10: icmp_seq=8 ttl=127 time=24.3 ms
64 bytes from 10.20.10.10: icmp_seq=9 ttl=127 time=24.0 ms
64 bytes from 10.20.10.10: icmp_seq=10 ttl=127 time=24.4 ms

--- 10.20.10.10 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9018ms
rtt min/avg/max/mdev = 23.9/24.6/26.8/0.8 ms

Significado: 25 ms con 0% de pérdida suele sentirse bien para RDP.

Decisión: Si ves pérdida > 1% o picos de jitter, arregla la red antes de culpar la configuración de RDP.

Tarea 9: Revisar problemas relacionados con MTU (común en VPNs)

cr0x@server:~$ ping -c 3 -M do -s 1372 10.20.10.10
PING 10.20.10.10 (10.20.10.10) 1372(1400) bytes of data.
1372 bytes from 10.20.10.10: icmp_seq=1 ttl=127 time=25.1 ms
1372 bytes from 10.20.10.10: icmp_seq=2 ttl=127 time=25.3 ms
1372 bytes from 10.20.10.10: icmp_seq=3 ttl=127 time=25.2 ms

--- 10.20.10.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 25.1/25.2/25.3/0.1 ms

Significado: El Path MTU soporta tramas ~1400 bytes. Eso normalmente es seguro para WireGuard.

Decisión: Si esto falla pero tamaños más pequeños funcionan, baja el MTU de WireGuard (por ejemplo, 1380) y vuelve a probar; los agujeros MTU hacen que RDP «se congele aleatoriamente».

Tarea 10: Confirmar que Windows escucha en 3389 (desde el host Windows vía SSH o consola)

cr0x@server:~$ ssh admin@10.20.10.10 "netstat -ano | findstr :3389"
  TCP    0.0.0.0:3389           0.0.0.0:0              LISTENING       1140
  TCP    [::]:3389              [::]:0                 LISTENING       1140

Significado: TermService está escuchando en IPv4 e IPv6, PID 1140.

Decisión: Si no hay nada escuchando, el servicio RDP está parado o deshabilitado. Inicia el servicio y confirma que la política no haya desactivado RDP.

Tarea 11: Verificar que el firewall de Windows permita RDP solo desde la subred VPN/oficina

cr0x@server:~$ ssh admin@10.20.10.10 "powershell -NoProfile -Command \"Get-NetFirewallRule -DisplayGroup 'Remote Desktop' | Get-NetFirewallAddressFilter | Select-Object -First 5\""
RemoteAddress : 10.10.0.0/16
RemoteAddress : 10.10.0.0/16
RemoteAddress : 10.10.0.0/16
RemoteAddress : 10.10.0.0/16
RemoteAddress : 10.10.0.0/16

Significado: Las reglas de RDP están limitadas a la subred de Office A. Ese es el punto de aplicación «solo vía VPN» que más importa a los auditores.

Decisión: Si ves RemoteAddress : Any, ajústalo. «Any» inevitablemente se convertirá en «cualquiera» por alguna misruta futura.

Tarea 12: Validar que NLA esté habilitado

cr0x@server:~$ ssh admin@10.20.10.10 "powershell -NoProfile -Command \"(Get-ItemProperty -Path 'HKLM:\\SYSTEM\\CurrentControlSet\\Control\\Terminal Server\\WinStations\\RDP-Tcp' -Name UserAuthentication).UserAuthentication\""
1

Significado: 1 significa que NLA es obligatorio.

Decisión: Si es 0, habilítalo salvo que tengas una razón de compatibilidad muy específica. Si un proveedor insiste en desactivarlo, resiste firmemente.

Tarea 13: Revisar los registros de eventos de Windows para logones RDP (éxito/fallo)

cr0x@server:~$ ssh admin@10.20.10.10 "powershell -NoProfile -Command \"Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 3 | Select-Object TimeCreated, Id, Message\""
TimeCreated            Id Message
-----------            -- -------
12/28/2025 08:34:11 4625 An account failed to log on.
12/28/2025 08:32:07 4625 An account failed to log on.
12/28/2025 08:29:52 4625 An account failed to log on.

Significado: Hay intentos de logon fallidos. Ahora correlacionas IP de origen, nombre de cuenta y tipo de logon. Si estos vienen desde dentro de la VPN, podrías tener credenciales comprometidas o acceso demasiado amplio.

Decisión: Si ves ráfagas, restringe el acceso VPN, habilita MFA y considera ajustes de política de bloqueo de cuentas (con cuidado: los bloqueos pueden usarse como DoS).

Tarea 14: Confirmar que la VPN sea la única ruta (chequeo de sanidad de enrutamiento)

cr0x@server:~$ traceroute -n 10.20.10.10 | head -n 6
traceroute to 10.20.10.10 (10.20.10.10), 30 hops max, 60 byte packets
 1  10.99.0.1  1.032 ms  0.981 ms  0.965 ms
 2  10.20.0.1  22.412 ms  22.376 ms  22.341 ms
 3  10.20.10.10  23.918 ms  23.882 ms  23.851 ms

Significado: El tráfico entra al túnel y llega a Office B. No hay desvíos extraños por rutas de Internet.

Decisión: Si el hop 1 es el router de tu ISP, no estás pasando por la VPN. Arregla rutas y confirma que las suposiciones de split-tunnel coincidan con la realidad.

Tarea 15: Observar tráfico en vivo para confirmar que los flujos RDP van por el túnel

cr0x@server:~$ sudo tcpdump -ni wg0 tcp port 3389 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
08:41:22.112233 IP 10.10.50.25.51432 > 10.20.10.10.3389: Flags [S], seq 12223344, win 64240, options [mss 1360,sackOK,TS val 111 ecr 0], length 0
08:41:22.134455 IP 10.20.10.10.3389 > 10.10.50.25.51432: Flags [S.], seq 99887766, ack 12223345, win 65160, options [mss 1360,sackOK,TS val 222 ecr 111], length 0
08:41:22.134900 IP 10.10.50.25.51432 > 10.20.10.10.3389: Flags [.], ack 1, win 64240, options [TS val 112 ecr 222], length 0
08:41:22.145000 IP 10.10.50.25.51432 > 10.20.10.10.3389: Flags [P.], length 64
08:41:22.150000 IP 10.20.10.10.3389 > 10.10.50.25.51432: Flags [P.], length 128

Significado: SYN/SYN-ACK en wg0 demuestra que la sesión atraviesa la interfaz del túnel VPN.

Decisión: Si no ves paquetes aquí pero los usuarios dicen que están haciendo RDP, pueden estar usando otra ruta (herramienta remota shadow IT, borde expuesto o una VPN distinta). Investiga y cierra la vía de bypass.

Tarea 16: Identificar cuello de botella en el gateway Linux (CPU/presión de interrupciones)

cr0x@server:~$ top -b -n 1 | head -n 15
top - 08:44:01 up 37 days,  2:11,  2 users,  load average: 0.62, 0.71, 0.68
Tasks: 141 total,   1 running, 140 sleeping,   0 stopped,   0 zombie
%Cpu(s):  7.2 us,  2.1 sy,  0.0 ni, 89.9 id,  0.1 wa,  0.0 hi,  0.7 si,  0.0 st
MiB Mem :   3932.1 total,    812.5 free,    701.1 used,   2418.5 buff/cache
MiB Swap:   1024.0 total,   1024.0 free,      0.0 used.   2978.2 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 1890 root      20   0  131456  24192  10432 S   6.0   0.6  18:22.11 wg-quick
 1022 root      20   0       0      0      0 S   1.3   0.0  12:10.23 ksoftirqd/0

Significado: Mucho margen de CPU; no hay indicios de que el gateway sea el cuello de botella.

Decisión: Si la CPU está al máximo o softirq es alto, puedes estar infraaprovisionado o sufriendo problemas de NIC/driver. Escala el gateway o ajusta offloads con cuidado (y prueba).

Broma #2: La VPN no es «lenta»; simplemente toma una ruta escénica y reflexiva. Desafortunadamente tus usuarios están intentando sprintar.

Guion rápido de diagnóstico

Cuando alguien dice «RDP está caído», no empiezas reinstalando Remote Desktop Services o reiniciando el firewall como si fuera un ritual.
Sigues una secuencia ajustada que encuentra el cuello de botella en minutos.

Primero: prueba que la ruta VPN esté viva

1. Comprueba el handshake del túnel. Si el túnel no está arriba, nada más importa. Usa wg show (Tarea 1) o tu herramienta de estado IPsec.
2. Revisa rutas. Confirma que la LAN remota routee al túnel (Tarea 2). Las misrutas parecen exactamente «RDP está caído».
3. Revisa forwarding + firewall en los gateways. Si el túnel está arriba pero el reenvío cae tráfico, verás handshakes pero no sesiones (Tareas 3–4).

Segundo: prueba que el host objetivo sea alcanzable y esté escuchando

1. Prueba de reachabilidad TCP a 3389. Usa nc -vz (Tarea 6). Timeout vs refused te indica dónde mirar.
2. Confirma que el servicio esté escuchando. netstat en el objetivo (Tarea 10). Sin listener, no hay RDP.
3. Confirma el alcance del firewall de Windows. Asegúrate de que las reglas RDP estén limitadas a rangos VPN/oficina (Tarea 11). Una regla demasiado estricta es tan mala como una demasiado laxa—solo que con menos titulares.

Tercero: diagnostica «lentitud» con física de red, no sensaciones

1. Ping y pérdida/jitter. Tarea 8. La pérdida hace que RDP se sienta como si perdiera pulsaciones.
2. Prueba MTU. Tarea 9. Los agujeros MTU causan bloqueos intermitentes que los usuarios describen como «se congela a veces».
3. Observa tráfico en vivo del túnel. Tarea 15. Si el tráfico no está en wg0, el usuario puede no estar usando la ruta prevista.
4. Revisa carga del gateway. Tarea 16. Cifrado y reenvío son trabajo real; no lo ejecutes en una VM olvidada con 1 vCPU esperando milagros.

Qué hacer cuando el túnel está arriba pero RDP sigue fallando

En ese punto, enfócate en controles del lado Windows:

• NLA habilitado (Tarea 12)
• Permisos de cuentas y membresías de grupos (Remote Desktop Users vs Administradores locales)
• Registros de eventos para fallos (Tarea 13)
• Corrección de DNS (clientes conectándose a la IP correcta)

Tres micro-historias corporativas desde el terreno

1) El incidente causado por una suposición equivocada: «Es interno, así que es seguro»

Una empresa mediana tenía dos oficinas y una VPN sitio-a-sitio. Hicieron lo «correcto» al no exponer RDP públicamente.
También hicieron lo «clásico» al permitir RDP desde «cualquier subred interna» porque era más fácil que gestionar reglas.

La suposición equivocada fue sutil: trataron la VPN como si mágicamente hiciera confiar a ambos lados.
En la práctica, Office A tenía un montón de dispositivos no gestionados: una laptop de un proveedor que iba y venía, algunos PCs kiosco y una red Wi‑Fi que no estaba tan segmentada como todos creían.

Un intento de stuffing de credenciales contra una sola contraseña débil de admin local tuvo éxito—no porque RDP fuera público, sino porque era alcanzable desde demasiados lugares internos.
Una vez que el atacante consiguió pie en un servidor en Office B, lo usó para consultar AD, pulverizar credenciales y moverse lateralmente.

El postmortem no trató de exploits exóticos. Fue sobre alcance y límites de identidad.
Lo arreglaron introduciendo hosts de salto y limitando las reglas del firewall RDP a la subred de los hosts de salto, además de habilitar MFA en la VPN de acceso remoto para administradores.
La VPN se quedó. El modelo de confianza cambió.

2) La optimización que salió mal: «Vamos a split-tunneling para mejorar rendimiento»

Otra organización tenía quejas legítimas: las sesiones RDP se sentían lentas en horas pico.
Alguien propuso split tunneling para toda la red de la oficina: mantener el tráfico de Internet local y enrutar solo subredes corporativas por la VPN. En papel parecía razonable.

El revés vino de dos frentes. Primero, DNS se volvió ambiguo: algunos clientes resolvían nombres de servidor a IPs públicas debido a una configuración DNS mixta y forwarders condicionales que no se aplicaban consistentemente.
Segundo, el monitoreo de seguridad asumía que todo el tráfico administrativo llegaba por la interfaz del túnel y dejó de alertar casi nada cuando sesiones comenzaron a llegar desde fuentes inesperadas.

El resultado fue extraño: algunos admins se conectaban por la VPN como estaba previsto, otros «accidentalmente» usaban una vía alterna a través de una herramienta remota heredada que aún estaba instalada en los hosts de salto.
Los problemas de RDP se volvieron intermitentes porque la gente no usaba la misma ruta. Los tickets de soporte sonaban a folklore.

La solución no fue «nunca split-tunnel». Fue: definirlo con precisión, aplicar DNS y eliminar herramientas de bypass.
Implementaron DNS condicional con reglas claras, restringieron el tráfico de gestión al VLAN de hosts de salto y añadieron alertas cuando RDP venía de fuera de las subredes esperadas.
El rendimiento mejoró, pero solo después de restaurar la determinismo.

3) La práctica aburrida pero correcta que salvó el día: «Una regla, una fuente, un propósito»

Una empresa del sector financiero llevaba todo muy estricto. Su equipo de red insistía en reglas de firewall dolorosamente específicas:
RDP a servidores estaba permitido solo desde dos hosts de salto, y esos hosts de salto eran alcanzables solo vía VPN.

Era burocrático. La gente se quejaba porque no podían simplemente RDP desde sus escritorios «por cinco minutos».
El equipo de seguridad se encogía de hombros y repetía la misma frase: «El acceso de gestión tiene un punto de estrangulamiento.»

Entonces la laptop de un contratista se infectó fuera de la oficina y luego se conectó a la red de la empresa. El malware intentó el guion habitual: escanear, propagarse, fuerza bruta.
Pudo ver muchas cosas, pero no alcanzó RDP en los servidores porque las reglas del firewall de Windows estaban limitadas estrictamente a los hosts de salto.

La respuesta al incidente aún fue trabajo—contención, reinstalación y restablecimiento de credenciales—pero nunca llegó a una toma de servidores.
La «regla aburrida» no evitó que la laptop se infectara. Evitó que la infección se convirtiera en un evento que destruya el negocio.
Ese es el tipo de aburrimiento que quieres.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: VPN muestra «conectado», pero RDP hace timeout

Causa raíz: El túnel está arriba, pero reglas de forwarding o firewall descartan tráfico entre wg0 y la LAN (o el reenvío IP está desactivado).

Solución: Confirma rutas (Tarea 2), habilita reenvío (Tarea 3) y añade allows explícitos en FORWARD (Tarea 4). Verifica con tcpdump (Tarea 15).

2) Síntoma: RDP funciona desde algunos PCs pero no desde otros

Causa raíz: Existen múltiples caminos (split tunnel, VPN alterna, DNS obsoleto o ruta directa a Internet). Algunos clientes no usan realmente la VPN sitio-a-sitio.

Solución: Usa traceroute (Tarea 14) desde clientes fallidos y funcionando, arregla enrutamiento/DNS y elimina herramientas de bypass. Aplica alcance de firewall a subredes conocidas.

3) Síntoma: RDP se conecta pero se congela aleatoriamente por segundos

Causa raíz: Agujero MTU o pérdida intermitente de paquetes en la ruta del túnel.

Solución: Ejecuta sondas MTU (Tarea 9) y pruebas de pérdida/jitter (Tarea 8). Baja MTU de WireGuard, arregla enlaces WAN o prioriza tráfico VPN en el perímetro.

4) Síntoma: Los usuarios reciben repetidos avisos de credenciales y luego «The logon attempt failed»

Causa raíz: NLA + desajuste de políticas, skew de reloj que afecta Kerberos o restricciones de cuenta. A veces es un usuario intentando una cuenta local que no está permitida para RDP.

Solución: Confirma estado de NLA (Tarea 12), revisa logs (Tarea 13), valida sincronización horaria y asegura que el usuario esté en Remote Desktop Users (o equivalente) y permitido por la política.

5) Síntoma: Tras «endurecer», nadie puede RDP

Causa raíz: El scope de direcciones remotas del firewall de Windows quedó demasiado estrecho (subred equivocada), o bloqueaste los mismos hosts de salto.

Solución: Valida los filtros de dirección del firewall (Tarea 11), confirma rangos IP de origen y mantiene una ruta de emergencia break-glass (acceso por consola / fuera de banda) para revertir reglas de forma segura.

6) Síntoma: RDP es alcanzable desde Internet a pesar de «no lo abrimos»

Causa raíz: NAT/port-forwarding en el borde, regla de security group en la nube o el módem del ISP haciendo forwarding «útil». A veces un segundo firewall hace UPnP inesperado.

Solución: Haz una prueba negativa desde fuera (Tarea 7), luego audita NAT perimetral y dispositivos aguas arriba. Desactiva UPnP. Trata cualquier exposición pública de RDP como un incidente y rota credenciales.

7) Síntoma: La VPN es estable pero el rendimiento RDP es pésimo solo en ciertos momentos

Causa raíz: Bufferbloat o saturación en el WAN, o gateway VPN con CPU limitada bajo carga.

Solución: Revisa carga del gateway (Tarea 16), aplica QoS/traffic shaping en el perímetro y dimensiona gateways con holgura. No ahorres recursos en la encriptación en una VM diminuta.

8) Síntoma: RDP funciona, pero auditorías se quejan «sin MFA»

Causa raíz: MFA se puso solo en el login de Windows (o en ningún lado), mientras que el riesgo principal es quién puede alcanzar el servicio. La autenticación VPN es el punto de control correcto.

Solución: Habilita MFA en la autenticación VPN, restringe acceso VPN por grupos y mantiene RDP accesible solo desde VPN/hosts de salto.

Listas de verificación / plan paso a paso

Paso a paso: construir «RDP solo vía VPN» entre dos oficinas

1. Inventaria subredes y corrige solapamientos. Si ambas oficinas usan el mismo rango RFC1918, decide ahora si renumerarás o usarás NAT. Renumerar duele una vez; NAT confunde para siempre.
2. Elige el tipo de VPN. Para dos sitios fijos, elige sitio-a-sitio (WireGuard o IPsec/IKEv2). Prioriza lo que tu equipo pueda operar a las 3 a.m.
3. Define el rango IP del túnel. Usa un /24 o /30 pequeño reservado para endpoints VPN (p. ej., 10.99.0.0/24).
4. Implementa enrutamiento. Añade rutas para LANs remotas al túnel; evita tunelizar la ruta por defecto a menos que sea necesario.
5. Bloquea el reenvío en gateways. Drop por defecto, luego permite solo tráfico requerido entre sitios (RDP a hosts de salto, AD/LDAP si hace falta, monitorización, etc.).
6. Despliega hosts de salto. Endurécelos, parchealos, monitoréalos. Son tu punto de estrangulamiento.
7. Limita reglas del firewall de Windows. Permite TCP/3389 solo desde la subred VPN o subred de hosts de salto. Prefiere «permitir solo desde hosts de salto» para servidores.
8. Habilita NLA y TLS moderno. No negocies con clientes antiguos; actualízalos o aíslalos.
9. Aplica MFA en el acceso VPN. Haz de la VPN la puerta. Además restringe qué usuarios/grupos pueden conectarse.
10. Centraliza logs. Recopila eventos VPN y logs de Seguridad de Windows relevantes para RDP.
11. Realiza pruebas negativas. Verifica que 3389 no sea alcanzable públicamente. Verifica que RDP falle cuando no estés en la VPN.
12. Documenta la ruta. Anota las IPs fuente esperadas, IPs objetivo y puertos permitidos. Tu yo futuro te agradecerá la nota.

Lista operativa: qué monitorizar continuamente

• Uptime del túnel VPN/frescura de handshakes y churn
• Pérdida de paquetes/jitter entre gateways
• Logones fallidos en Windows (4625) con picos de logon type 10
• Logs de denegación del firewall para 3389 desde fuentes inesperadas
• Conformidad de parches en hosts de salto y objetivos RDP

Lista de seguridad: qué prohibir explícitamente

• Sin inbound público a 3389, nunca
• Sin scope de dirección «Any» en reglas de firewall RDP de Windows
• Sin cuentas administrativas compartidas para RDP
• Sin endpoints no gestionados con acceso administrativo VPN
• Sin excepciones «temporales» sin fecha de expiración y responsable

Preguntas frecuentes

1) ¿»RDP solo vía VPN» es suficiente, o aún necesito endurecer RDP?

Aún debes endurecer RDP. La VPN limita quién puede alcanzar el puerto; el endurecimiento de RDP limita qué ocurre cuando alguien lo alcanza.
Haz ambas cosas. La defensa en profundidad no es un eslogan; es cómo sobrevives al cambio de personal.

2) ¿Debería usar WireGuard o IPsec para sitio-a-sitio?

Usa lo que tu equipo pueda operar de forma fiable. WireGuard es más simple y suele ser más fácil de depurar. IPsec está ampliamente soportado en appliances y puede ser «configúralo y olvídalo» si se hace bien.
El protocolo importa menos que el enrutamiento correcto, el scope de firewall y MFA en las vías de acceso.

3) ¿Puedo simplemente cambiar el puerto de RDP en lugar de usar una VPN?

No. Cambiar puertos reduce escaneos aleatorios; no aborda ataques dirigidos, stuffing de credenciales o deriva de configuración.
Si debes exponer algo públicamente, expón una puerta endurecida y consciente de identidad—no RDP crudo.

4) ¿Necesito un host de salto si la VPN ya está restringida?

Si tienes más de un par de servidores, sí. Los hosts de salto crean un punto de estrangulamiento para control de acceso, parcheo y registros.
También reducen la cantidad de endpoints que manejan credenciales privilegiadas.

5) ¿Cuál es la mejor forma de restringir RDP en Windows?

Limita las reglas del Firewall de Windows para «Remote Desktop» a rangos de fuente de confianza (subred VPN o hosts de salto).
No confíes solo en firewalls perimetrales; las reglas locales evitan exposiciones accidentales por futuros cambios de enrutamiento.

6) ¿Por qué RDP se siente lento aunque el ancho de banda es bueno?

RDP es sensible a latencia y pérdida. Un enlace rápido con jitter y pérdida se sentirá peor que uno más lento pero estable.
Revisa pérdida/jitter de ping y problemas MTU primero (Tareas 8 y 9).

7) ¿Deberíamos habilitar split tunneling?

Para sitio-a-sitio ya tienes comportamiento «split» al enrutar solo subredes requeridas. Para acceso remoto, el split tunneling es una decisión de política:
puede reducir carga y mejorar rendimiento, pero complica la monitorización y aumenta el riesgo de caminos no deseados. Si lo haces, sé explícito y prueba DNS y enrutamiento a fondo.

8) ¿Qué pasa si ambas oficinas usan la misma subred (solapamiento)?

Las subredes solapadas son la mina oculta clásica. La solución limpia es renumerar un sitio.
Si no puedes, necesitarás NAT dentro de la VPN y mapeo cuidadoso (por ejemplo, traducir el 192.168.1.0/24 de una oficina a un rango virtual no solapado). Documenta agresivamente y espera tiempo extra de troubleshooting para siempre.

9) ¿Cómo demostramos a los auditores que RDP no está expuesto públicamente?

Proporciona evidencia de política de firewall (reglas de borde que muestran no 3389 inbound), además de pruebas negativas externas (Tarea 7) y el scope del firewall de Windows (Tarea 11).
A los auditores les gustan los controles en capas porque asumen que las equivocaciones ocurren. Tienen razón.

10) ¿Podemos evitar RDP por completo?

A veces. Para administración de servidores, PowerShell Remoting, Windows Admin Center o herramientas de gestión pueden reducir el uso interactivo de RDP.
Pero aún querrás una ruta interactiva «break glass» para emergencias—solo mantenla VPN-only y muy acotada.

Conclusión: siguientes pasos prácticos

La configuración más segura de «RDP entre oficinas» no es ingeniosa. Es disciplinada: VPN sitio-a-sitio, enrutamiento estricto, scope del firewall de Windows, hosts de salto, MFA en la VPN y registros que realmente leas.
No 3389 abierto. No excepciones que vivan para siempre. No rutas misteriosas.

Haz esto a continuación, en orden:

1. Ejecuta la prueba negativa desde fuera y confirma que RDP público está muerto (Tarea 7).
2. Limita las reglas del firewall RDP de Windows a fuentes VPN/hosts de salto (Tarea 11) y verifica con una prueba de alcanzabilidad (Tarea 6).
3. Implementa (o ajusta) enrutamiento y reglas de forwarding sitio-a-sitio (Tareas 1–4).
4. Valida latencia/pérdida y MTU para evitar tickets de «se congela a veces» (Tareas 8–9).
5. Configura el punto de estrangulamiento: hosts de salto, MFA y logs centralizados (Tarea 13 como tu señal de partida).

Hazlo aburrido. Luego mantenlo aburrido. Así es como la producción sigue viva.