En este contexto aparece SMB sobre QUIC, una especie de “VPN SMB” moderna que encapsula el protocolo clásico de compartición de archivos de Windows dentro de QUIC, con cifrado TLS 1.3 y mejor tolerancia a redes poco fiables, cambiando por completo la forma en la que accedemos a los recursos compartidos desde Internet. A lo largo de este artículo vas a ver, con bastante nivel de detalle, cómo funciona, qué necesitas para montarlo, cómo gestionarlo y cómo reforzar todavía más la seguridad de tu entorno.
Qué es SMB sobre QUIC y por qué cambia las reglas del juego
SMB sobre QUIC es la evolución del transporte de SMB que reemplaza el clásico TCP 445 por QUIC sobre UDP 443. En lugar de exponer el puerto SMB de toda la vida a Internet, se establece un túnel seguro con TLS 1.3 encima de QUIC, de forma que todos los paquetes van siempre cifrados y autenticados desde el primer momento.
El protocolo QUIC, estandarizado por el IETF, ofrece ventajas muy claras frente a TCP: el cifrado es obligatorio en todos los paquetes, el protocolo de enlace usa TLS 1.3 autenticado, permite flujos paralelos fiables y no fiables en la misma conexión, envía datos de aplicación en 0-RTT para reducir la latencia inicial, mejora el control de congestión y la recuperación de pérdidas, y soporta cambios de IP o de puerto sin tirar la sesión.
Cuando usamos SMB dentro de este túnel QUIC, el tráfico SMB -incluyendo autenticación, autorización y datos- nunca queda expuesto en claro a la red subyacente. El cliente ve un recurso compartido SMB estándar, con multicanal, firma, compresión, alta disponibilidad, leasing de directorio y resto de características habituales, pero todo viaja encapsulado y cifrado a través del puerto UDP 443, mucho más amigable con firewalls y redes públicas.
En la práctica, SMB sobre QUIC proporciona una VPN específica para archivos pensada para teletrabajadores, dispositivos móviles, sucursales y organizaciones con requisitos de seguridad elevados. El usuario trabaja exactamente igual que si estuviera en la red interna, pero sin montar una VPN generalista y sin abrir el puerto 445 al exterior.
Un punto importante: SMB sobre QUIC no se activa solo. Es el administrador quien debe habilitarlo en el servidor de archivos. Los clientes de SMB en Windows siguen usando TCP de forma predeterminada y solo intentan QUIC si el acceso TCP falla primero, o si se fuerza explícitamente el transporte con comandos como NET USE /TRANSPORT:QUIC o New-SmbMapping -TransportType QUIC.
Requisitos previos para desplegar SMB sobre QUIC
Antes de activar nada, hay que revisar los requisitos básicos de infraestructura. No es especialmente complicado, pero sí conviene tenerlo claro para evitar errores tontos en producción.
Para el servidor SMB, necesitas que ejecute alguna edición que soporte QUIC, como Windows Server 2022 Datacenter: Azure Edition o posteriores, y que esté configurado como servidor de archivos perimetral o similar. También se puede usar en escenarios de Azure Local y en futuras versiones como Windows Server 2025.
En el lado del cliente, se requiere Windows 11 en ediciones orientadas a empresa, ya que las capacidades SMB sobre QUIC están pensadas para entornos corporativos. El dispositivo debe poder resolver el nombre público del servidor a través de DNS o, en su defecto, tenerlo definido en su archivo HOSTS.
A nivel de identidad, el escenario recomendado es que servidor SMB y cliente estén unidos a un dominio de Active Directory. El servidor tiene que poder contactar al menos con un controlador de dominio para la autenticación, aunque estos controladores no necesitan acceso a Internet. También se soportan configuraciones en grupo de trabajo con cuentas locales y NTLM, así como servidores unidos a Microsoft Entra en IaaS de Azure, pero con ciertas limitaciones en operaciones de seguridad remotas.
En cuanto a conectividad, el servidor debe ser accesible desde Internet por su interfaz pública, con una regla de firewall que permita tráfico entrante UDP/443. Es crucial no exponer el puerto TCP 445 desde Internet; si necesitas puertos alternativos, Microsoft permite cambiar la configuración de puertos SMB, pero la filosofía general es: UDP 443 sí, TCP 445 no.
Para el plano de seguridad, se requiere una infraestructura de clave pública (PKI) que emita certificados válidos para el servidor QUIC. Puede ser Active Directory Certificate Services o una entidad externa de confianza (DigiCert, GlobalSign, Let’s Encrypt con el perfil adecuado, etc.). Y, por supuesto, el administrador que va a configurar SMB sobre QUIC debe tener privilegios administrativos sobre el servidor.
Instalación y preparación del certificado de servidor
El núcleo de la seguridad en SMB sobre QUIC es el certificado TLS del servidor. Sin un certificado bien emitido y bien instalado, el túnel QUIC no se establece correctamente y el cliente no confiará en la conexión.
Ese certificado debe cumplir varios requisitos técnicos concretos: uso de clave de firma digital, propósito de autenticación de servidor (EKU 1.3.6.1.5.5.7.3.1), algoritmo de firma al menos SHA256RSA, hash SHA256 o superior y clave pública preferiblemente ECDSA_P256 (aunque se admite RSA con un mínimo de 2048 bits). Además, debe contener en el Subject Alternative Name (SAN) todas las entradas DNS completas que se utilizarán para acceder al servidor SMB.
El certificado ha de incluir la clave privada asociada y estar emitido por una entidad que los clientes consideren de confianza. El campo CN del emisor puede ser flexible, pero la cadena de confianza tiene que ser válida y completa. En entornos con una CA corporativa de Microsoft, lo habitual es crear una plantilla específica para SMB sobre QUIC y permitir que los administradores indiquen los nombres DNS cuando solicitan el certificado.
En escenarios con CA de Microsoft Enterprise, el proceso típico implica abrir MMC en el servidor, agregar el complemento de certificados para la cuenta de equipo y, en el almacén Personal, lanzar una solicitud de nuevo certificado. Se escoge la directiva de inscripción de Active Directory, se selecciona la plantilla apropiada y se rellenan los campos de Asunto y SAN con los nombres DNS que usarán los clientes.
Una vez finalizada la inscripción, el certificado aparecerá en el almacén de equipo local. A partir de ese momento, ya se puede usar tanto en SMB sobre QUIC como en funciones complementarias como el proxy de KDC si se decide implementar más adelante.
Configuración de SMB sobre QUIC en el servidor
Una vez tienes el certificado listo, llega el momento de activar y configurar SMB sobre QUIC. Microsoft permite hacerlo tanto desde Windows Admin Center (WAC) como desde PowerShell, según preferencias y versión del sistema.
Al habilitar la característica, el servidor asocia el certificado TLS seleccionado al endpoint QUIC que escuchará en UDP 443. Desde ese momento, los clientes capaces de usar SMB sobre QUIC podrán establecer un túnel cifrado hacia el servidor siempre que resuelvan el nombre DNS del certificado y puedan llegar al puerto 443/UDP.
En Windows Admin Center suele haber un botón de “Configurar” o similar para SMB sobre QUIC. Sin embargo, hay casos reportados en los que el botón no responde, normalmente por versiones desactualizadas de WAC, extensiones rotas o requisitos no cumplidos (por ejemplo, que la máquina no sea Azure Edition, que falten roles o que el certificado no sea válido). En estos casos, lo recomendable es revisar versiones, comprobar que el servidor cumple los requisitos y, si hace falta, pasar a la configuración vía PowerShell.
Además de la configuración básica, es posible aplicar políticas de acceso para limitar qué clientes pueden usar QUIC, combinarlo con Azure Automanage para gestionar certificados y supervisar el estado de la configuración, y enlazarlo con otras funcionalidades avanzadas como el control de acceso de clientes y el proxy de KDC.
Conexión de clientes a recursos compartidos SMB sobre QUIC
Para el usuario final, la idea es que el acceso sea lo más transparente y familiar posible, como si estuviera dentro de la red corporativa. No obstante, hay varios puntos de configuración que conviene revisar.
Lo primero es unir el dispositivo Windows 11 al dominio (si es el caso) y asegurarse de que los nombres DNS del servidor definidos en el SAN del certificado corresponden con entradas válidas en DNS o en el archivo HOSTS. Desde fuera de la red interna, el cliente ya no verá las IP privadas, así que se debe usar el nombre externo publicado, o, como alternativa, utilizar OneDrive para compartir archivos en escenarios donde no sea viable publicar SMB.
A la hora de probar, conviene mover el equipo a una red externa donde no exista acceso directo al dominio ni a las IP internas. De esta forma se comprueba que el acceso se hace realmente a través de QUIC y no por el camino clásico de LAN.
Desde el Explorador de archivos de Windows se puede teclear la ruta UNC al recurso compartido, como \\fsedge1.contoso.com\ventas, y confirmar que se accede sin problema. Si se quiere forzar explícitamente el uso de QUIC, se recurre a comandos como NET USE /TRANSPORT:QUIC o New-SmbMapping -TransportType QUIC, indicando la ruta UNC deseada.
Por ejemplo, un comando de mapeo puede intentar primero TCP y, en caso de fallo, pasar a QUIC, o bien limitarse exclusivamente a QUIC. Con New-SmbMapping también es sencillo asignar letras de unidad a recursos remotos, algo muy cómodo para el usuario que viene de trabajar con unidades de red clásicas.
Auditoría y administración de SMB a través de QUIC
Una vez que SMB sobre QUIC está operativo, es fundamental tener visibilidad sobre quién se conecta, cómo y desde dónde. Para ello, Microsoft ha incorporado capacidades de auditoría tanto en el lado cliente como en el servidor.
En Windows 11 (a partir de la versión 24H2), el cliente SMB incorpora eventos específicos para el transporte QUIC. El Visor de eventos permite consultar estos registros en la ruta Registros de aplicaciones y servicios\Microsoft\Windows\SMBClient\Conectividad, donde se generan eventos como el ID 30832 relacionados con conexiones SMB sobre QUIC.
En el servidor SMB, se puede activar una auditoría más detallada ejecutando Set-SmbServerConfiguration -AuditClientCertificateAccess $true. A partir de ese momento, en los registros Registros de aplicaciones y servicios\Microsoft\Windows\SMBServer\Audit aparecen eventos que informan del acceso permitido o denegado, incluyendo datos del certificado del cliente (asunto, emisor, número de serie, hash SHA1 y SHA256) y las reglas de control de acceso que se han aplicado.
Estos eventos incorporan un identificador de conexión que facilita correlacionar lo que se ve en el cliente con lo que se registra en el servidor, simplificando mucho las tareas de troubleshooting cuando algo falla o se quiere revisar un comportamiento sospechoso.
Uso opcional de Proxy de KDC para mantener Kerberos
Por diseño, cuando un cliente se conecta desde Internet a un servidor SMB sobre QUIC, normalmente no tiene acceso directo a los controladores de dominio de Active Directory. En ese escenario, la autenticación tiende a recurrir a NTLMv2, con el servidor de archivos autenticándose en nombre del cliente, siempre dentro del túnel QUIC cifrado con TLS 1.3.
Aunque NTLMv2 va protegido dentro del túnel y no sale a la red en claro, las buenas prácticas de seguridad recomiendan seguir utilizando Kerberos siempre que sea posible y no crear nuevas dependencias de NTLMv2. Aquí entra en juego el proxy de KDC (KDC Proxy), que reenvía las solicitudes de tickets Kerberos en nombre del usuario mediante un canal HTTPS compatible con Internet.
Para configurarlo, en el servidor de archivos se crean primero las reservas de URL HTTP para el servicio de proxy con NETSH, se ajustan los valores de registro del servicio KPSSVC para permitir el tipo de autenticación deseado y se vincula la huella digital del certificado de SMB sobre QUIC al endpoint HTTPS 0.0.0.0:443 con Add-NetIPHttpsCertBinding.
También hay que agregar nombres alternativos del servidor SMB sobre QUIC como SPN en Active Directory, por ejemplo mediante NETDOM, para que el servidor pueda representar correctamente la identidad de servicio en Kerberos. Finalmente, se establece el servicio de proxy KDC con inicio automático y se arranca.
En el lado del cliente, se configura una directiva de grupo en Configuración del equipo\Plantillas administrativas\Sistema\Kerberos\Especificar servidores proxy KDC para clientes Kerberos, donde se mapea el dominio interno (por ejemplo corp.contoso.com) con la URL HTTPS externa del servidor QUIC (por ejemplo https fsedge1.contoso.com:443:kdcproxy /). Así el cliente sabe que, si un usuario de ese dominio se conecta a un servidor de archivos publicado externamente, debe usar el proxy KDC para obtener los tickets.
Gestión del ciclo de vida del certificado en SMB sobre QUIC
Los certificados no viven para siempre, y en el caso de SMB sobre QUIC, cada renovación trae consigo una nueva huella digital. Aunque se utilicen mecanismos de renovación automática con Active Directory Certificate Services, el hecho de que cambie la huella implica que hay que actualizar la asignación del certificado en la configuración de QUIC.
Cuando el certificado está a punto de caducar o se renueva, hay que volver a seleccionar el certificado en Windows Admin Center para la configuración existente, o ejecutar el cmdlet PowerShell Set-SMBServerCertificateMapping apuntando a la nueva huella. Si se olvida este paso, la conectividad SMB sobre QUIC puede interrumpirse de forma inesperada.
Para evitar sustos, Microsoft recomienda apoyar esta gestión en herramientas como Azure Automanage para Windows Server, que supervisa el estado de los certificados y avisa (o incluso corrige) antes de que se produzca una caída del servicio. En entornos de alta disponibilidad y acceso remoto crítico, esto marca la diferencia.
Control de acceso de clientes con certificados
Más allá de la simple autenticación, SMB sobre QUIC también puede aplicar control de acceso basado en certificados de cliente. Es una capa adicional de seguridad que restringe qué dispositivos pueden establecer un túnel QUIC con el servidor, incluso aunque conozcan las credenciales.
El funcionamiento es el siguiente: el servidor exige que el cliente presente una cadena de certificados válida y de confianza. A partir de esa cadena, se comprueba una lista de control de acceso que puede contener entradas de permiso o bloqueo, tanto para certificados concretos (identificados por su hash SHA256) como para emisores completos (CAs intermedias o raíz).
Para que esto funcione, primero se activa la exigencia de autenticación de cliente con Set-SmbServerCertificateMapping -RequireClientAuthentication $true. A continuación, se empiezan a registrar certificados de cliente permitidos o bloqueados mediante cmdlets como Grant-SmbClientAccessToServer, Revoke-SmbClientAccessToServer, Block-SmbClientAccessToServer y Unblock-SmbClientAccessToServer.
Este modelo permite, por ejemplo, autorizar a toda una CA corporativa y, al mismo tiempo, negar acceso a un certificado concreto que se considera comprometido. O al revés: bloquear una CA entera pero autorizar un certificado individual muy específico. Las reglas de denegación prevalecen sobre las de permiso, lo que ayuda a acotar riesgos.
Desde el punto de vista del cliente, basta con tener instalado en su almacén local un certificado emitido para autenticación de cliente (EKU 1.3.6.1.5.5.7.3.2) por una CA en la que confíe el servidor. El administrador puede recoger la huella o el Subject del certificado desde PowerShell (Get-ChildItem Cert:\LocalMachine\My, filtros por Subject, etc.) y usarlo posteriormente para configurar la lista de acceso en el servidor.
Pruebas de conectividad y depuración de problemas
Una buena práctica al implantar SMB sobre QUIC es seguir una serie de pruebas controladas antes de abrirlo a toda la organización. De esa manera se detectan a tiempo problemas de certificados, DNS o firewalls y, cuando sea necesario, consultar guías para resolver problemas de acceso a archivos.
Desde el cliente puedes empezar con un mapeo explícito usando NET USE \\servidor\recurso /TRANSPORT:QUIC o New-SmbMapping -RemotePath \\servidor\recurso -TransportType QUIC. Si en lugar de conectar recibes un mensaje de que el servidor ha denegado el acceso, probablemente la asignación de certificados y la recepción del túnel QUIC están funcionando, pero falta configurar el control de acceso de clientes o revisar permisos.
En paralelo, es importante revisar los registros de eventos de conectividad del cliente y audit del servidor comentados antes. Verás allí tanto los intentos exitosos como los fallidos, con información detallada de la cadena de certificados y de las reglas que se han aplicado en cada caso.
También conviene comprobar desde el servidor que las reglas del firewall permiten UDP 443 de entrada y TCP 443 para escenarios donde se utilice proxy de KDC u otros servicios HTTPS asociados, y que no se ha dejado expuesto TCP 445 a Internet por error.
Buenas prácticas de segmentación y aislamiento de tráfico SMB
Aunque SMB sobre QUIC protege de forma muy robusta el tráfico de archivos a través de Internet, sigue siendo recomendable aplicar técnicas de segmentación y aislamiento para reducir la superficie de ataque entre dispositivos de la red.
Una directriz básica es bloquear el puerto TCP 445 entrante desde Internet en los firewalls perimetrales. Si necesitas exponer recursos de archivos en el perímetro, la opción segura es publicarlos mediante SMB sobre QUIC en UDP 443, no abriendo directamente SMB clásico.
En sentido inverso, bloquear el puerto TCP 445 saliente hacia Internet evita que equipos internos envíen datos SMB a servidores externos no controlados. Solo en escenarios muy concretos como Azure Files u Office 365 puede ser necesario permitir este tráfico, y aún así se recomienda canalizarlo mediante VPNs o reglas muy estrictas por rangos IP.
En redes con muchos equipos, merece la pena hacer un inventario del uso real de SMB, analizando qué servidores realmente necesitan SMB entrante, qué clientes requieren compartir y desde qué subredes se accede a cada uno. Para ello pueden utilizarse herramientas como Get-FileShareInfo, así como habilitar auditorías de “File Share” durante un tiempo acotado para observar qué recursos están en uso.
A partir de este análisis, se pueden diseñar reglas de firewall de entrada y salida mucho más ajustadas, que bloqueen el SMB innecesario y limiten los movimientos laterales de un posible atacante dentro de la red.
Refuerzo con Firewall de Windows Defender e IPsec
El Firewall de Windows Defender con seguridad avanzada actúa como segunda línea de defensa alrededor del tráfico SMB. Se pueden crear reglas para bloquear conexiones entrantes y salientes por defecto, permitiendo únicamente las excepciones necesarias para controladores de dominio, servidores de archivos y servicios críticos.
Una estrategia habitual es definir reglas de salida que impidan el uso de SMB hacia cualquier destino salvo una lista de permitidos basada en IPs o nombres, con la acción “Permitir la conexión si es segura”. Esta opción se puede personalizar para usar autenticación Kerberos y encapsulación nula en IPsec, lo que obliga a que solo equipos y usuarios de dominio autorizados puedan aprovechar esas excepciones.
Para que este enfoque funcione, es imprescindible crear reglas de seguridad de conexión en todos los equipos implicados, de forma que las excepciones del firewall se fundamenten en IPsec. De lo contrario, el bloqueo podría terminar siendo arbitrario o inconsistente.
En versiones recientes como Windows 11 24H2 y Windows Server 2025, Microsoft ha ajustado las reglas de firewall integradas para dejar de abrir automáticamente los puertos NetBIOS (137-139) cuando se crean recursos compartidos SMB2 o superiores, reflejando una política más estricta y alineada con los despliegues modernos.
En entornos donde ya no se depende de SMB1, es muy recomendable cerrar estos puertos heredados. Solo en casos de compatibilidad excepcional se deberían reabrir manualmente, preferentemente limitando el alcance mediante reglas muy concretas.
Deshabilitar el servidor SMB donde no sea necesario
Muchos clientes de Windows y algunos servidores en la red no necesitan en realidad el servicio de servidor SMB activo, ya que nunca comparten archivos hacia otros equipos. Mantener el servicio habilitado sin motivo solo amplía la superficie de ataque.
Antes de desactivarlo, conviene revisar si hay aplicaciones o procesos que dependan de él. Una vez verificado, se puede deshabilitar el servicio de servidor SMB en equipos seleccionados, por ejemplo con preferencias de directiva de grupo que apliquen esta configuración de forma masiva y controlada.
Esta medida, combinada con SMB sobre QUIC para el acceso remoto y reglas de firewall bien ajustadas, ayuda a construir una arquitectura de compartición de archivos mucho más robusta, donde solo los nodos que deben exponer SMB lo hacen, y de la forma más segura posible.
SMB sobre QUIC permite ofrecer a usuarios remotos, sucursales y dispositivos móviles un acceso a archivos cifrado, resistente a redes inestables y sin necesidad de VPN tradicionales, mientras que las herramientas de certificados, control de acceso de clientes, proxy de KDC, firewall y segmentación de red proporcionan el andamiaje necesario para que esta “VPN SMB” funcione de manera fiable y con garantías de seguridad en entornos reales.
