Clientes VPN bloqueados por el perfil Público del Firewall de Windows

Su túnel está activo, la puerta de enlace responde al ping y el recurso compartido sigue agotando el tiempo de espera. Esa combinación rara vez es un problema de enrutamiento: Windows ha colocado la subred del adaptador VPN en el perfil Público, y toda regla de permiso escrita para Privado o Dominio nunca se aplicó. Me he encontrado con esto en portátiles que llegan a la oficina sin problema y en servidores RRAS que atienden a todos los demás clientes, y la reparación es breve en cuanto se identifica el perfil en juego. Este es el orden en el que trabajo, con la comprobación que le indica cuándo detenerse antes del paso siguiente.

Averigüe en qué perfil llega realmente el tráfico

El Firewall de Windows no tiene un modo global único. Cada interfaz conectada lleva una categoría, y los paquetes entrantes se filtran según la categoría de la interfaz por la que llegan, de modo que el perfil del adaptador VPN decide a qué puede acceder un cliente tunelizado, no el adaptador Wi-Fi o Ethernet que está al lado. Lea ambos datos antes de tocar nada:

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory, IPv4Connectivity
Get-NetFirewallProfile -Name Public | Select-Object Name, Enabled, DefaultInboundAction

En una instalación estándar de OpenVPN o WireGuard, el adaptador VPN aparece como una red no identificada y cae en Público, el valor predeterminado para cualquier red que Windows no sepa clasificar: ningún controlador de dominio respondió a través de ella y ningún perfil de puerta de enlace coincidió. El nombre de la interfaz es irrelevante aquí, así que llamar al adaptador «VPN» o «Corp» no cambia nada. DomainAuthenticated requiere un equipo unido al dominio , que pueda alcanzar realmente un controlador de dominio por esa interfaz; un túnel dividido que solo lleva una subred no cumplirá el requisito.

Si la regla que necesita ya está limitada al grupo de VPN y ya se aplica a la categoría que acaba de leer, deténgase aquí: el filtrado no es su capa, y el siguiente lugar donde mirar es la configuración del servicio. Esa comprobación lleva diez segundos y ahorra una hora de edición de reglas. Los nombres de las categorías y lo que cubre cada una están documentados en la referencia de Get-NetConnectionProfile.

Confirme el filtrado, no el enrutamiento, antes de editar reglas

El ping es una prueba débil. ICMP puede pasar aunque el puerto del servicio se descarte, y un host puede responder desde la LAN mientras rechaza la misma petición por el túnel. Pruebe el puerto que necesita el cliente, desde el cliente:

Test-NetConnection 10.8.0.1 -Port 445
Test-NetConnection 10.8.0.1 -Port 3389 -InformationLevel Detailed

Si la prueba de puerto falla, separe las dos capas. Un fallo de túnel o de ruta suele manifestarse como ninguna respuesta desde la dirección de puerta de enlace, mientras que un descarte del firewall muestra una puerta de enlace que responde y un puerto de servicio que no. En un servidor Windows que publica el grupo mediante RRAS, ejecute la misma prueba desde un cliente y lea el perfil del propio servidor: la interfaz RAS puede estar en una categoría cuyas reglas de entrada nunca mencionan el rango de clientes, y por eso el equipo atiende su LAN y rechaza a todos los clientes tunelizados.

Si el resultado sigue siendo ambiguo, registre los descartes del perfil en juego y léalos:

Set-NetFirewallProfile -Name Public -LogBlocked True `
  -LogFileName "$env:systemroot\system32\LogFiles\Firewall\pfirewall.log"

Las entradas que nombran la dirección y el puerto del cliente con DROP son concluyentes, y además indican qué regla faltaba. Un registro vacío mientras el SYN del cliente nunca aparece apunta aguas arriba del host, así que vuelva al túnel, a la regla NAT o a la ruta del grupo antes de tocar otro objeto del firewall.

Limite una regla de entrada al grupo de clientes

La reparación es una sola regla de permiso de entrada cuya dirección remota es el grupo, no el mundo entero. Desde una sesión elevada:

New-NetFirewallRule -DisplayName "VPN clients - SMB 445" `
  -Direction Inbound -Action Allow -Protocol TCP -LocalPort 445 `
  -RemoteAddress 10.8.0.0/24 -Profile Public

Cuando el servicio es un único binario, prefiera una regla limitada al programa con -Program en lugar de una lista de puertos; así la excepción queda limitada tanto al proceso como al rango de origen.

La elección del perfil es donde se comete el mismo error en la dirección opuesta. -Profile Public basta cuando el adaptador es Público y sigue siéndolo. -Profile Any es defendible cuando el servicio debe funcionar sin importar cómo clasifique Windows el adaptador, pero solo mientras se mantenga el ámbito remoto. Lo que nunca es defendible es -RemoteAddress Any en el perfil Público: esa regla sigue al portátil en cada red de cafetería y hotel a la que se conecta y abre el puerto a cualquiera que comparta esa subred.

Anote el grupo junto a la regla. -RemoteAddress 10.8.0.0/24 deja de coincidir en silencio el día que se renumera el grupo de VPN, y el fallo se parece exactamente al error original, por lo que cuesta otra tarde. Nombre las reglas por el servicio y el rango de origen, manténgalas juntas con -Group, y vuelva a leerlas cada vez que cambie la definición del grupo. Un inventario de reglas que se pueda auditar en una sola pantalla supera a una regla correcta que nadie encuentra.

Cambie la categoría solo cuando la categoría sea la decisión

Cambiar la interfaz a Privado también funciona, pero es el valor predeterminado equivocado. El perfil Privado incluye una larga lista de reglas de permiso integradas, que cubren el uso compartido de archivos e impresoras, la detección de redes, el escritorio remoto y más según la línea base, así que reclasificar el adaptador VPN las habilita todas a la vez para cada cliente del túnel. Una regla limitada concede un servicio a un rango. En un portátil que también se conecta a redes no confiables, esa diferencia no es cosmética.

Hay casos en los que la clasificación es realmente errónea: un túnel permanente o de sitio a sitio que transporta una subred de oficina es infraestructura de confianza, y marcar ese adaptador como Privado es una decisión de diseño legítima, tomada una vez por política y no por incidencia. Cuando lo haga, hágalo de forma explícita:

Set-NetConnectionProfile -InterfaceAlias "OpenVPN TAP-Windows6" -NetworkCategory Private

En un dispositivo administrado, compruebe primero si una directiva de grupo o una línea base de MDM posee la configuración. Si es así, el cambio local se deshace en la siguiente actualización y gpresult /h nombrará la directiva que la posee; corríjalo allí, no en el equipo.

Verifique desde ambos extremos y deje rastro

Compruebe el flujo que notificó el usuario, desde el cliente, después del cambio:

Test-NetConnection 10.8.0.1 -Port 445
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallAddressFilter | Select-Object RemoteAddress
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallPortFilter | Select-Object Protocol, LocalPort

Cierre entonces el bucle con lo que se romperá la semana que viene. Reinicie el host y vuelva a probar, porque una regla limitada al perfil equivocado sigue funcionando hasta que el adaptador vuelve en otra categoría. Pruebe desde un segundo cliente, ya que un cliente que conserva una concesión obsoleta puede ocultar un desajuste del grupo. Cuente las reglas que agregó frente a las que eliminó, porque las excepciones superpuestas son la forma en que una corrección de dos líneas se convierte en una política de filtrado que nadie puede revisar.

Antes de darlo por terminado:

• El perfil nombrado en la regla es el de la interfaz por la que llega el tráfico.
• El ámbito remoto es el grupo de VPN, y ese grupo coincide con lo que el servidor entrega realmente.
• Ninguna regla que haya agregado usa -RemoteAddress Any en el perfil Público.
• No se desactivó nada para que la prueba pasara, y cualquier cambio de categoría registra quién lo aprobó.