VPN de oficina + RDP: Escritorio remoto seguro sin exponer RDP a Internet

noviembre 24, 2025 • febrero 3, 2026 • Lectura: 27 min • Views: 11

¿Te fue útil?

La empresa quiere “solo RDP” porque es familiar, rápido y funciona con cualquier cosa heredada de Windows que se niega a morir.
Seguridad pide “sin puertos públicos” porque han visto lo que hace Internet con un 3389 expuesto. Estás atrapado en el medio, sosteniendo un pager.

La buena noticia: puedes tener escritorio remoto que se siente como RDP, sin permitir nunca que RDP toque Internet pública.
La mala noticia: debes ser disciplinado con los límites de red, la identidad y el diagnóstico—porque cuando se rompe, se rompe a las 2 a.m.

El objetivo: RDP permanece privado

La regla principal es vergonzosamente simple: RDP nunca debe ser alcanzable desde Internet público.
No “está bien si limitamos la tasa.” No “está bien si cambiamos el puerto.” No “está bien porque somos pequeños.”
Debe ser inrutables desde afuera. Punto final.

En su lugar, los usuarios establecen un túnel seguro hacia la red de la oficina—típicamente una VPN—y solo entonces inician RDP a hosts internos.
Eso te da un punto de estrangulamiento para autenticación, MFA, controles de dispositivo y registro. También te da un lugar donde romper cosas,
lo cual es… honestamente mejor que romperlas por todas partes.

Si te tienta publicar 3389 con una regla de firewall “temporal”, recuerda: las reglas temporales tienen la vida útil de las sobras sin etiqueta en la nevera de la oficina.

Hechos y contexto histórico (lo que explica el lío actual)

RDP existe desde finales de los 90, evolucionando desde la era de Terminal Services de Microsoft; fue diseñado para redes gestionadas, no para bordes hostiles de Internet.
TCP/3389 se convirtió en un imán de escaneos en cuanto el escaneo masivo de Internet se abarató; cambiar el puerto por “seguridad por oscuridad” nunca solucionó eso.
Network Level Authentication (NLA) se introdujo para mover la autenticación más temprano en el flujo de conexión, reduciendo abuso de recursos y parte de la superficie de ataque.
BlueKeep (CVE-2019-0708) recordó a todos que los fallos de RDP previos a la autenticación pueden ser propagables; no fue el primero y no será el último.
Los grupos de ransomware operacionalizaron la fuerza bruta sobre RDP porque es directo y rentable: una credencial = un escritorio = movimiento lateral.
Las VPN pasaron de “plomería sitio-a-sitio” a “puerta de identidad” con el crecimiento del trabajo remoto; muchas orgs aún las tratan como túneles tontos.
El split tunneling se popularizó para reducir costes de ancho de banda y evitar hairpinning, y también es popular entre quienes disfrutan del dolor al responder incidentes.
RD Gateway existe porque RDP puro es incómodo a escala: ofrece política central y transporte HTTPS, pero sigue siendo un servicio publicado que hay que proteger.
El acceso remoto moderno converge hacia patrones Zero Trust: postura del dispositivo + acceso por aplicación; VPN+RDP puede aproximarse a esto si eres estricto.

Arquitectura de referencia: VPN primero, RDP después

Aquí está la arquitectura que tiende a sobrevivir auditorías y atacantes reales:

Punto final VPN en un gateway endurecido (o par, si te gusta dormir), expuesto a Internet en un solo puerto (p. ej., UDP/51820 para WireGuard).
Autenticación fuerte: certificados/keys más MFA (o una VPN que se integre con un IdP). Si no puedes hacer MFA, no has terminado.
RDP solo interno: RDP escucha en interfaces LAN/VPN solamente; las reglas de firewall restringen orígenes a subredes VPN y solo a hosts de salto autorizados.
Segmentación: los usuarios solo pueden alcanzar los hosts que necesitan. “Los usuarios VPN pueden acceder a todo un /16” es cómo entrenas al ransomware para correr.
Registro: conexiones/desconexiones VPN, inicios de sesión RDP y acciones de administrador centralizados. Si no puedes responder “quién accedió al host X a la hora Y”, estás adivinando.
Host de salto opcional / bastión: uno o pocos hosts Windows de salto con políticas endurecidas. Los usuarios hacen RDP al host de salto, y desde allí a los objetivos internos.

Por qué un host de salto suele ser la opción adulta

Los hosts de salto parecen anticuados, pero obligan a un límite limpio: la VPN te lleva al host de salto, y el host de salto te lleva a todo lo demás.
Eso significa que menos máquinas necesitan tener RDP habilitado, menos máquinas necesitan membresías en “Remote Desktop Users”, y menos máquinas deben lidiar con extraños fallos de cliente RDP.

También centralizan el registro. Windows puede registrar actividad RDP por host, claro, pero consolidar el acceso a través de un pequeño conjunto de hosts hace tu línea temporal de incidentes
menos como una búsqueda del tesoro y más como una investigación.

Decisiones difíciles: VPN vs RD Gateway vs ambos

VPN + RDP interno (el enfoque aquí)

Lo mejor cuando controlas los dispositivos cliente, puedes desplegar la configuración VPN limpiamente y quieres que RDP permanezca interno.
Este es el enfoque “no expongas RDP a Internet” en su forma más pura: el único componente con cara pública es el endpoint VPN.

RD Gateway (RDP sobre HTTPS)

RD Gateway envuelve RDP en HTTPS (TCP/443), lo que funciona bien con redes restrictivas.
Centraliza la autorización y puede reducir la necesidad de acceso de red completo. Pero es un servicio público: debes parchearlo, monitorizarlo
y defenderlo como cualquier otro sistema expuesto a Internet.

Ambos (sí, a veces)

Algunas organizaciones colocan RD Gateway detrás de una VPN de todos modos. Suena redundante hasta que te enfrentas a:
(1) contratistas que deberían acceder solo a un subconjunto de escritorios,
(2) la necesidad de controles de acceso condicional en múltiples capas,
(3) regímenes de cumplimiento que prefieren defensa en profundidad cuando está realmente bien configurada.

Opinión marcada: si eres una organización pequeña o mediana y puedes desplegar clientes VPN de forma fiable, VPN + hosts de salto es la mejor relación coste-seguridad.
Si tienes muchos dispositivos no gestionados, considera RD Gateway con endurecimiento serio—o, mejor, un modelo de acceso por aplicación que evite acceso de red amplio.

Construir: VPN de oficina con WireGuard (práctico, rápido, aburrido)

WireGuard no es magia. Sin embargo, es refrescantemente pequeño, rápido y fácil de razonar en comparación con pilas VPN más antiguas.
Si administras sistemas de producción, “fácil de razonar” es una característica que puedes justificar en la hoja de cálculo del presupuesto.

Plan de red (no improvises en producción)

Subred VPN: 10.44.0.0/24 (los clientes viven aquí)
LAN de la oficina: 10.10.0.0/16 (servidores/escritorios viven aquí)
Servidor WireGuard: 10.44.0.1
Hosts de salto: 10.10.20.10–10.10.20.20

Conceptos básicos de endurecimiento del servidor

Pon el endpoint VPN en una VM o appliance dedicado, no en el servidor de archivos, no en el controlador de dominio, y definitivamente no en “esa caja debajo del escritorio de alguien”.
Mantén el SO ligero. Párchelo. Restringe puertos entrantes al puerto VPN y SSH solo desde rangos administrativos de confianza.

Asegurar RDP en Windows (para que se comporte)

Activar RDP es fácil. Activarlo de forma segura es donde la gente empieza a regatear.
Quieres: NLA habilitado, TLS moderno, timeouts sensatos, membresías de grupo limitadas y alcance del firewall limitado a la subred VPN (y tal vez al subnet de hosts de salto).

También: deshabilita cuentas administrativas “por si acaso”. Usa identidades administrativas separadas. Registra. Si no puedes registrar, no puedes defender.

Firewall y segmentación (donde la mayoría falla)

La VPN no es una capa mágica de seguridad. Es un evento de enrutamiento. Si los clientes VPN pueden enrutar a todo,
entonces un portátil comprometido también puede enrutar a todo. Tus reglas de firewall deberían reflejar el trabajo, no la topología de red que heredaste.

Postura mínima de firewall

Los clientes VPN pueden alcanzar solo hosts de salto en TCP/3389.
Los administradores pueden alcanzar puertos de gestión (WinRM, SSH, etc.) desde subredes administrativas dedicadas.
Bloquear RDP este-oeste excepto donde sea explícitamente necesario.
Registrar denegaciones desde la subred VPN. No para siempre, pero el tiempo suficiente para investigar incidentes.

Split tunneling: elegir con cuidado

El split tunneling significa que solo parte del tráfico va por la VPN; el resto sale directamente a Internet.
Es bueno para ancho de banda y terrible para suposiciones. Si tu modelo de seguridad depende de “VPN = red de confianza”, el split tunneling lo rompe.

Si debes usar split tunneling, trata a los clientes VPN como semi-hostiles: restringe lo que pueden alcanzar, exige MFA y registra agresivamente.

Identidad: MFA, postura del dispositivo y el mito de la “VPN de confianza”

El acceso VPN no es identidad. Es conectividad. Identidad es: ¿quién es este usuario, desde qué dispositivo, con qué nivel de garantía, y todavía merece acceso ahora mismo?

Si tu VPN soporta SSO y acceso condicional, úsalo. Si no, compensa: credenciales de corta duración, claves por usuario y una puerta MFA separada.
Para RDP en sí, no permitas cuentas locales cuando puedas evitarlas. Vincúlalo a identidades de directorio y controla la membresía en “Remote Desktop Users”.

Una idea parafraseada de Werner Vogels (CTO de Amazon): “Todo falla, todo el tiempo.” Construye el acceso remoto como si la falla fuera el estado por defecto.
Porque lo es.

Registro y monitorización: prueba quién hizo qué

Necesitas dos líneas de tiempo: línea de tiempo VPN (quién se conectó, desde dónde, con qué dispositivo) y línea de tiempo Windows (quién inició sesión, dónde y qué tipo de sesión).
Ponlas en el mismo lugar. Correlaciona por nombre de usuario, IP de origen (IP VPN) y tiempo.

En Windows te importan los eventos de logon (interactivo vs remoto interactivo), los inicios fallidos, los bloqueos de cuenta y los cambios en membresías de grupo.
En el gateway VPN te importan el éxito de handshakes, cambios de configuración y anomalías de tráfico.

Tareas prácticas: 12+ comandos, salidas y decisiones

Estas son las tareas que realmente ejecuto cuando construyo o depuro VPN+RDP en producción. Cada una incluye: un comando, qué significa la salida y qué decisión tomar a continuación.
Los comandos se muestran desde un gateway VPN Linux salvo que se indique. Para comprobaciones en Windows, uso PowerShell en un host Windows donde hace falta, pero invocado en bash vía SSH o un shell de gestión.

Tarea 1: Confirmar interfaz WireGuard y handshakes de peers

cr0x@server:~$ sudo wg show
interface: wg0
  public key: 6xk2n3m...redacted
  listening port: 51820

peer: uRk9hQ...redacted
  endpoint: 198.51.100.24:53312
  allowed ips: 10.44.0.10/32
  latest handshake: 1 minute, 12 seconds ago
  transfer: 148.32 MiB received, 210.77 MiB sent
  persistent keepalive: every 25 seconds

Significado: “latest handshake” te dice que el túnel está vivo; los contadores de transferencia indican que el tráfico fluye.
Decisión: Si el handshake es “never” o muy antiguo, deja de culpar a RDP. Arregla primero accesibilidad VPN, keys, NAT o firewall.

Tarea 2: Verificar que el servidor escucha en el puerto VPN

cr0x@server:~$ sudo ss -lunpt | grep 51820
udp   UNCONN 0      0            0.0.0.0:51820      0.0.0.0:*    users:(("wg-quick",pid=1123,fd=6))

Significado: UDP 51820 está ligado en todas las interfaces.
Decisión: Si nada escucha, el servicio WireGuard no está arriba o está enlazado incorrectamente. Arregla el servicio y la configuración antes de cualquier otra cosa.

Tarea 3: Confirmar reenvío de IP en el gateway VPN (Linux)

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

Significado: El gateway puede enrutar paquetes entre interfaces.
Decisión: Si es 0, los clientes VPN pueden conectarse pero no alcanzarán hosts LAN. Habilita el reenvío y persístelo.

Tarea 4: Revisar la tabla de rutas para la subred VPN y la ruta LAN

cr0x@server:~$ ip route
default via 203.0.113.1 dev eth0
10.10.0.0/16 via 10.10.0.1 dev eth1
10.44.0.0/24 dev wg0 proto kernel scope link src 10.44.0.1

Significado: El gateway sabe dónde vive la LAN y que wg0 posee la subred VPN.
Decisión: Si la ruta LAN falta o es incorrecta, el tráfico de clientes VPN se perderá. Arregla enrutamiento antes de tocar Windows.

Tarea 5: Verificar que el firewall permite WireGuard y bloquea RDP público

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    tcp dport 22 ip saddr 203.0.113.50 accept
    udp dport 51820 accept
    tcp dport 3389 drop
  }
}

Significado: La VPN está permitida; RDP en el propio gateway se descarta explícitamente (un buen “cinturón y tirantes”).
Decisión: Si ves una regla accept para tcp/3389 en una interfaz pública, elimínala. No negocies con incidentes futuros.

Tarea 6: Probar conectividad desde el gateway a un host de salto Windows en 3389

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

Significado: El host de salto es alcanzable y el puerto RDP está abierto desde la perspectiva de red del gateway.
Decisión: Si falla, probablemente tengas Windows Firewall, ACLs de red o problemas de enrutamiento entre el gateway y la subred de salto.

Tarea 7: Probar desde una IP cliente VPN hacia el host de salto (simular desde el gateway)

cr0x@server:~$ sudo nft add rule inet filter forward ip saddr 10.44.0.0/24 ip daddr 10.10.20.10 tcp dport 3389 counter accept
cr0x@server:~$ sudo nft list chain inet filter forward
table inet filter {
  chain forward {
    type filter hook forward priority 0; policy drop;
    ip saddr 10.44.0.0/24 ip daddr 10.10.20.10 tcp dport 3389 counter packets 0 bytes 0 accept
  }
}

Significado: Has creado una regla explícita de permitir para clientes VPN al RDP del host de salto, con contadores.
Decisión: Usa contadores para confirmar que el tráfico golpea la regla. Si los contadores permanecen en 0 durante un intento de conexión, el tráfico no está llegando a esta caja (enrutamiento/NAT/config cliente).

Tarea 8: Confirmar que Windows tiene RDP habilitado y NLA requerido (PowerShell en el host de salto)

cr0x@server:~$ ssh admin@10.10.20.10 'powershell -NoProfile -Command "Get-ItemProperty -Path \"HKLM:\System\CurrentControlSet\Control\Terminal Server\" -Name fDenyTSConnections; Get-ItemProperty -Path \"HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\" -Name UserAuthentication"'
fDenyTSConnections : 0
PSPath              : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server
PSParentPath        : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control
PSChildName         : Terminal Server
PSDrive             : HKLM
PSProvider          : Microsoft.PowerShell.Core\Registry

UserAuthentication : 1
PSPath             : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
PSParentPath       : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations
PSChildName        : RDP-Tcp
PSDrive            : HKLM
PSProvider         : Microsoft.PowerShell.Core\Registry

Significado: fDenyTSConnections=0 significa RDP habilitado; UserAuthentication=1 significa que NLA es obligatorio.
Decisión: Si NLA está desactivado, actívalo a menos que tengas una razón documentada (y un plan) para operar sin él.

Tarea 9: Revisar alcance de la regla de Windows Firewall para RDP (evitar “Any”)

cr0x@server:~$ ssh admin@10.10.20.10 'powershell -NoProfile -Command "Get-NetFirewallRule -DisplayGroup \"Remote Desktop\" | Get-NetFirewallAddressFilter | Select-Object Name,RemoteAddress | Format-Table -AutoSize"'
Name                                   RemoteAddress
----                                   -------------
RemoteDesktop-UserMode-In-TCP           Any
RemoteDesktop-UserMode-In-UDP           Any
RemoteDesktop-Shadow-In-TCP             Any

Significado: “Any” en dirección remota significa que cualquiera que pueda enrutar a este host puede intentar RDP.
Decisión: Cambia el alcance a la subred VPN (10.44.0.0/24) y/o solo al subnet de salto. “Any” está bien en laboratorio; es pereza en producción.

Tarea 10: Validar que RDP no está expuesto públicamente (escaneo externo desde el lado público del gateway)

cr0x@server:~$ nmap -Pn -p 3389 203.0.113.10
Starting Nmap 7.94 ( https://nmap.org ) at 2025-12-28 15:42 UTC
Nmap scan report for 203.0.113.10
Host is up (0.012s latency).

PORT     STATE  SERVICE
3389/tcp closed ms-wbt-server

Nmap done: 1 IP address (1 host up) scanned in 0.21 seconds

Significado: Closed es bueno aquí. “Filtered” también es aceptable (a menudo mejor), dependiendo de la política.
Decisión: Si está abierto, detente. Arregla el firewall/NAT perimetral inmediatamente. No procedas hasta que 3389 no sea alcanzable desde Internet.

Tarea 11: Revisar comportamiento DNS para clientes VPN (la causa sigilosa de “RDP está caído”)

cr0x@server:~$ dig +short jump01.corp.example A @10.10.0.53
10.10.20.10

Significado: DNS interno resuelve el host de salto a una IP interna.
Decisión: Si los clientes VPN usan DNS público, pueden resolver a un registro público o a nada. Arregla el push de DNS de la VPN o la política del resolvedor del cliente.

Tarea 12: Confirmar que el cliente puede enrutar a la LAN vía VPN (desde el gateway VPN, inspecciona conntrack)

cr0x@server:~$ sudo conntrack -L | grep 10.44.0.10 | head
tcp      6 431999 ESTABLISHED src=10.44.0.10 dst=10.10.20.10 sport=53422 dport=3389 src=10.10.20.10 dst=10.44.0.10 sport=3389 dport=53422 [ASSURED] mark=0 use=1

Significado: La sesión TCP RDP existe a través del gateway; los paquetes fluyen y están rastreados.
Decisión: Si no ves un flujo establecido cuando el usuario intenta conectar, el problema está antes (config cliente, enrutamiento, firewall).

Tarea 13: Revisar problemas MTU/fragmentación (clásico “la VPN funciona pero RDP es terrible”)

cr0x@server:~$ ping -c 3 -M do -s 1372 10.44.0.10
PING 10.44.0.10 (10.44.0.10) 1372(1400) bytes of data.
1380 bytes from 10.44.0.10: icmp_seq=1 ttl=64 time=34.2 ms
1380 bytes from 10.44.0.10: icmp_seq=2 ttl=64 time=33.5 ms
1380 bytes from 10.44.0.10: icmp_seq=3 ttl=64 time=33.9 ms

--- 10.44.0.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 33.5/33.8/34.2/0.3 ms

Significado: Un paquete de 1400 bytes con DF pasa, lo que sugiere que MTU no está obviamente roto para ese camino.
Decisión: Si falla con “Frag needed”, ajusta el MTU de WireGuard (a menudo rango 1280–1420 según uplinks) y vuelve a probar.

Tarea 14: Verificar que los logs de Windows muestran inicios de sesión RDP (probar si es autenticación o red)

cr0x@server:~$ ssh admin@10.10.20.10 'powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName=\"Security\"; Id=4624} -MaxEvents 5 | Select-Object TimeCreated,Id,Message | Format-List"'
TimeCreated : 12/28/2025 3:41:02 PM
Id          : 4624
Message     : An account was successfully logged on.
...
Logon Type: 10
...

Significado: Logon Type 10 indica RemoteInteractive (RDP). Tienes prueba de que el usuario realmente alcanzó y autenticó en el host.
Decisión: Si los usuarios se quejan pero ves inicios de sesión exitosos, el problema es rendimiento de la sesión, carga de perfil, GPO o lentitud de la aplicación—no “VPN caída”.

Tarea 15: Revisar inicios de sesión fallidos y bloqueos (fuerza bruta o error humano)

cr0x@server:~$ ssh admin@10.10.20.10 'powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName=\"Security\"; Id=4625} -MaxEvents 5 | Select-Object TimeCreated,Id,Message | Format-List"'
TimeCreated : 12/28/2025 3:39:11 PM
Id          : 4625
Message     : An account failed to log on.
...
Status: 0xC000006D
Sub Status: 0xC000006A
...

Significado: Substatus 0xC000006A típicamente indica contraseña incorrecta. Eventos repetidos pueden indicar fuerza bruta o un usuario con contraseñas guardadas incorrectas (el tipo humano).
Decisión: Si es un usuario real, restablece credenciales o arregla contraseñas guardadas. Si es desconocido, investiga la IP origen (IP VPN), deshabilita la cuenta y busca movimiento lateral.

Tarea 16: Confirmar que el servicio RDP está sano y escucha en Windows

cr0x@server:~$ ssh admin@10.10.20.10 'powershell -NoProfile -Command "Get-Service TermService | Format-Table Status,Name,DisplayName -AutoSize; netstat -ano | findstr \":3389\""'
Status Name        DisplayName
------ ----        -----------
Running TermService Remote Desktop Services
  TCP    0.0.0.0:3389           0.0.0.0:0              LISTENING       1204

Significado: El servicio RDP está en ejecución y el puerto está en escucha.
Decisión: Si el servicio está detenido o el puerto no escucha, no estás persiguiendo fantasmas VPN—estás arreglando el host.

Guía de diagnóstico rápido (encuentra el cuello de botella)

Cuando el escritorio remoto “no funciona”, el camino más rápido es dejar de tratarlo como un solo sistema. Son cuatro sistemas vistiendo un trench coat:
dispositivo cliente, VPN, ruta de red y sesión Windows.

Primero: ¿está realmente arriba el túnel VPN?

En el gateway: wg show y revisa “latest handshake”.
En el cliente: confirma que tiene una IP VPN (p. ej., 10.44.0.x) y rutas para subredes internas.
Decisión: Si el handshake está desactualizado, arregla la accesibilidad VPN (NAT, keys, UDP bloqueado). No toques Windows todavía.

Segundo: ¿puedes alcanzar el host de salto por IP en 3389?

Desde el gateway o un cliente de prueba en la VPN: nc -vz 10.10.20.10 3389.
Decisión: Si el puerto está cerrado, es estado de firewall o servicio. Si está abierto, sigue adelante.

Tercero: ¿es DNS, autenticación o montaje de sesión?

DNS: dig jump01... y compara con la IP interna esperada.
Auth: revisa logs de Seguridad de Windows para 4624/4625 alrededor de la hora del intento.
Rendimiento de sesión: si el inicio de sesión tuvo éxito pero la interfaz es inútil, sospecha MTU, pérdida de paquetes, carga de perfil, perfiles móviles o scripts GPO.

Cuarto: Si está lento, mide la red—no adivines

Haz ping con DF y paquetes dimensionados para detectar MTU.
Mira contadores de transferencia de WireGuard y errores de interfaz.
Decisión: Si la latencia está bien pero la interfaz va lenta, sospecha contención de CPU/RAM/disco en el servidor (sí, el almacenamiento puede arruinar RDP).

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

1) Síntoma: “RDP funciona en Wi‑Fi de la oficina, falla remotamente”

Causa raíz: Reglas de firewall RDP permiten subredes LAN pero no subredes VPN; o no se empujaron rutas VPN.
Solución: Abarca las reglas de Windows Firewall “Remote Desktop” para incluir 10.44.0.0/24, y asegúrate de que el servidor VPN anuncie rutas LAN a los clientes.

2) Síntoma: “La VPN conecta, pero falla RDP por hostname; la IP funciona”

Causa raíz: DNS no configurado para clientes VPN, o split tunneling envía consultas DNS a resolutores públicos.
Solución: Empuja servidores DNS internos en la configuración VPN; verifica con dig contra el DNS interno y la configuración del resolvedor del cliente.

3) Síntoma: “RDP pide credenciales repetidamente”

Causa raíz: Desajuste NLA, deriva de tiempo afectando Kerberos, o uso de cuentas locales con políticas que bloquean inicio de sesión remoto.
Solución: Requiere NLA, asegura que los clientes lo soportan, arregla sincronización de tiempo (NTP) y usa cuentas de dominio con membresías adecuadas.

4) Síntoma: “RDP conecta pero es terriblemente lento, especialmente al escribir”

Causa raíz: Problemas MTU/fragmentación sobre la VPN, pérdida de paquetes o bufferbloat en uplinks.
Solución: Prueba con pings DF; ajusta MTU de WireGuard; añade QoS/modelado de tráfico sensato; evita hairpinning de VPN cuando sea posible.

5) Síntoma: “Desconexiones aleatorias cada pocos minutos”

Causa raíz: Timeouts NAT y falta de keepalive en clientes móviles; Wi‑Fi inestable; timeouts agresivos de estado de firewall.
Solución: Habilita persistent keepalive de WireGuard para clientes detrás de NAT; investiga comportamiento del firewall/ISP; prefiere cableado cuando sea práctico.

6) Síntoma: “Todos pueden RDP a cualquier lado una vez en VPN”

Causa raíz: Red plana + firewall permisivo + membresía AD amplia.
Solución: Implementa segmentación: clientes VPN solo a hosts de salto; grupos RDP con mínimo privilegio; políticas forward deny-by-default.

7) Síntoma: “Seguridad dice que debemos rotar claves semanalmente, ahora nada funciona”

Causa raíz: Rotación sin automatización; clientes fuera de sincronía; configuraciones de peers obsoletas.
Solución: Automatiza aprovisionamiento/rotación; usa autenticación de corta duración cuando sea posible; versiona configuraciones y despliega con gestión de dispositivos.

Tres mini-historias corporativas (porque las cicatrices enseñan)

Mini-historia 1: El incidente causado por una suposición equivocada

Una empresa mediana desplegó una VPN para “arreglar” el acceso remoto. Hicieron lo básico: un servidor WireGuard, claves de usuario, una subred limpia.
El equipo supuso que porque los usuarios tenían que autenticarse a la VPN, todo lo que estaba detrás era “interno” y por tanto seguro.

Dejaron las reglas de Windows Firewall RDP en su alcance por defecto (“Any”), y su red interna era mayormente plana.
Al helpdesk le gustó: menos tickets. El equipo de seguridad no lo notó porque técnicamente nada era “expuesto a Internet”.

Entonces un portátil de contratista fue comprometido vía un exploit de navegador. El atacante no necesitó escanear Internet público.
Se conectó a la VPN usando el cliente ya configurado del contratista, aterrizó en la subred VPN y empezó a sondear RDP interno.
Unas cuantas contraseñas débiles después, tenía un escritorio con acceso a shares y algunas herramientas de administración.

La reunión postincidente fue silenciosamente brutal. El problema no era WireGuard. El problema era la suposición de que “VPN = confianza”.
La solución fue igualmente poco glamorosa: restringir tráfico VPN‑a‑LAN a hosts de salto, imponer MFA y acotar reglas de firewall RDP a fuentes específicas.
Seguridad obtuvo su contención. Helpdesk obtuvo un nuevo script. Todos obtuvieron un runbook de on-call más largo.

Mini-historia 2: La optimización que salió mal

Otra organización tenía quejas: “RDP está lento.” Miraron gráficas de ancho de banda VPN, vieron picos y decidieron que split tunneling “reduciría la carga.”
Aplicaron el cambio un viernes por la tarde (por supuesto) para que solo 10.10.0.0/16 pasara por la VPN; todo lo demás saliera localmente.

Lunes por la mañana: la mitad de usuarios no podía RDP por hostname. La otra mitad podía conectarse pero recibía prompts de autenticación extraños.
No era aleatorio. Algunas redes domésticas secuestraban DNS. Algunos usuarios tenían resolutores ISP “útiles”. Unos pocos tenían entradas corporativas antiguas en caché.

Peor: un subconjunto de usuarios ahora tenía sesiones RDP mientras su tráfico general evitaba controles corporativos.
Una infección de malware en una red doméstica tenía un camino más limpio a comando y control mientras el dispositivo infectado todavía tenía ruta a la LAN corporativa vía VPN.
Esa es la clase de frase que no quieres escribir en un informe de incidentes.

Revirtieron el split tunneling para la mayoría y lo reintrodujeron solo para un grupo controlado con endpoints gestionados y ACL estrictas.
El rendimiento mejoró después, pero no por el split tunneling. Mejoró porque arreglaron problemas MTU e implementaron QoS en el uplink de oficina.
La “optimización” no estaba mal en teoría. Estaba mal en contexto.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Una empresa regulada ejecutaba acceso remoto mediante VPN + un pequeño pool de hosts de salto Windows.
Cada trimestre hacían algo que parecía papeleo: revisaban membresías de grupo para acceso remoto,
validaban alcances de firewall y testeaban que no hubiera puertos RDP alcanzables externamente.

Durante una revisión, un ingeniero notó que se había añadido una nueva subred para un entorno de laboratorio.
El equipo de routing la había anunciado accidentalmente de forma amplia, y una regla de firewall permisiva significaba que clientes VPN ahora podían alcanzar servidores de laboratorio directamente.
Los servidores de laboratorio, naturalmente, eran “temporales”, “experimentales” y parcheados según un calendario descrito mejor como “aspiracional”.

Lo arreglaron antes de que se pusiera emocionante: ajustaron las reglas forward, actualizaron grupos de direcciones y requirieron acceso al laboratorio vía un host de salto separado con controles extra.
Dos semanas después, salió una vulnerabilidad para la UI de gestión del hypervisor del laboratorio. El laboratorio fue escaneado. No pasó nada.
El mejor incidente es el que nunca llega a ser incidente, y casi siempre lo previene alguien haciendo cosas aburridas a propósito.

Listas de verificación / plan paso a paso

Paso a paso para desplegar VPN + RDP de forma segura

Elige un modelo de acceso remoto: VPN + host de salto para la mayoría; RD Gateway si necesitas acceso por aplicación sin alcance de red completo.
Asigna subredes: una subred de clientes VPN dedicada; no reutilices rangos LAN o te arrepentirás en cafeterías y hoteles.
Construye el gateway VPN: SO endurecido, servicios mínimos, pipeline de parches, gestión de configuración.
Implementa forwarding deny-by-default: solo permitir que clientes VPN alcancen hosts de salto en 3389 (y DNS si es necesario).
Despliega hosts de salto: pool pequeño, baseline endurecido, acceso administrativo restringido, registro habilitado.
Asegura RDP en objetivos: habilita NLA, restringe alcance del firewall, deshabilita cifrados legacy cuando sea posible, mantén SO parcheado.
Añade MFA: en la entrada VPN, y idealmente también en inicio de sesión Windows con acceso condicional o controles equivalentes.
Centraliza logs: logs VPN + logs de seguridad Windows + logs de firewall en un único lugar con retención acorde al riesgo.
Prueba “sin RDP público” continuamente: escaneos externos programados o monitorización desde un punto de control.
Documenta diagnóstico rápido: la ruta de on-call debe tomar minutos, no una expedición arqueológica por Slack.

Lista operacional (semanal/mensual)

Confirmar que 3389 no está abierto en IPs públicas (escaneo desde afuera).
Revisar lista de peers VPN y eliminar usuarios/dispositivos obsoletos.
Revisar membresías de “Remote Desktop Users” y Administradores locales en hosts de salto.
Parchear hosts de salto y gateways VPN según un calendario que exista en la práctica.
Verificar logs puntuales: autenticaciones VPN fallidas, fallos repetidos de RDP, geos de origen inusuales (si aplica).
Probar una conexión remota real desde una red no-oficina.

Preguntas frecuentes

1) ¿Por qué es tan grave exponer RDP a Internet si uso contraseñas fuertes?

Porque RDP es un objetivo de alto valor y es golpeado constantemente por escaneos y stuffing de credenciales.
Las contraseñas fuertes ayudan, pero no eliminan vulnerabilidades del protocolo, malas configuraciones o credenciales robadas.
El RDP más seguro es el que Internet no puede alcanzar.

2) ¿No basta con cambiar el puerto de RDP?

No. Reduce el ruido de los escáneres más vagos, no el riesgo de alguien competente.
Los atacantes escanean todo el rango de puertos o fingerprinting de servicios. No construyas seguridad sobre la esperanza de que se aburran.

3) VPN da la sensación de dar acceso de red completo a los usuarios. ¿Puedo limitarlo?

Sí, y deberías. Forwarding deny-by-default en el gateway VPN más reglas explícitas para hosts de salto es el movimiento estándar.
Si tu producto VPN soporta ACLs por usuario, úsalas. Si no, segmenta por grupos y subredes.

4) ¿Debo usar transporte UDP o TCP para la VPN?

Prefiere UDP cuando sea posible (WireGuard usa UDP). TCP sobre TCP puede amplificar latencia y comportamientos extraños de retransmisión.
Si te fuerzas a TCP por redes cautivas, considera una ruta de acceso alternativa, pero no rediseñes todo por el Wi‑Fi de hotel.

5) ¿Necesito un RD Gateway si ya tengo VPN?

No necesariamente. RD Gateway es útil cuando necesitas acceso RDP sin enrutamiento de red completo, o cuando los entornos cliente bloquean VPNs.
Pero es otro servicio público que operar. Si el despliegue de VPN es factible, VPN + hosts de salto es más simple y suele ser más seguro.

6) ¿Cómo evito que un cliente VPN comprometido escanee mi LAN?

No lo permitas. Implementa reglas de firewall para que clientes VPN solo alcancen destinos y puertos específicos (habitualmente hosts de salto en 3389).
Registra denegaciones. Considera pools VPN administrativos separados. Trata a los clientes como no confiables hasta demostrar lo contrario.

7) RDP es lento solo sobre VPN. ¿Cuál es la causa más común?

Problemas MTU y pérdida de paquetes son contendientes principales. RDP es interactivo; pequeñas demoras se sienten enormes.
Prueba pings DF, ajusta MTU de la VPN y revisa congestión del uplink. También revisa el servidor: contención de disco y carga de perfiles pueden imitar “lentitud de red”.

8) ¿Puedo confiar solo en Windows Firewall?

Puedes, pero serás más feliz si no lo haces. La defensa en profundidad importa: firewall/NAT perimetral, ACLs del gateway VPN y alcances de Windows Firewall.
Windows Firewall es bueno, pero también está a un error de política de “Any”.

9) ¿Qué hago con proveedores/contratistas que necesitan acceso temporal?

Dales acceso a un host de salto dedicado con herramientas restringidas y credenciales limitadas en el tiempo.
Evita darles rutas VPN amplias. Registra sus sesiones. Retira acceso automáticamente cuando termine el contrato (recordatorios en calendario no son automatización).

10) ¿MFA en la VPN es suficiente, o necesito MFA en Windows también?

MFA en la VPN es el mínimo. MFA en Windows (o acceso condicional en el límite de sesión) es mejor, especialmente para usuarios privilegiados.
El objetivo es hacer que credenciales VPN robadas no sean suficientes para alcanzar escritorios sensibles o sesiones administrativas.

Conclusión: próximos pasos que puedes hacer ahora

Si quieres escritorio remoto seguro, deja de pensar en RDP como el producto. El producto es acceso controlado.
La VPN es la puerta principal. El firewall es el pasillo. Los hosts de salto son la recepción. Los registros son las cámaras de seguridad que necesitarás más tarde.

Pasos siguientes que mueven la aguja esta semana:

Escanea tus IPs públicas y verifica que TCP/3389 esté cerrado/filtrado en todas partes.
Restringe la alcanzabilidad de RDP a subredes VPN y, idealmente, solo a hosts de salto.
Activa NLA y confírmalo en registro/política.
Añade MFA al acceso VPN, y limita las rutas VPN a lo que los usuarios realmente necesitan.
Centraliza logs de conexiones VPN y de inicios de sesión RDP en Windows para que puedas responder con evidencia, no con intuiciones.

Segundo chiste, porque te lo ganaste: Internet no “descubre” un puerto RDP expuesto; simplemente recuerda dónde vives.