Punto de acceso de Windows no funciona: el servicio que suele estar muerto

¿Te fue útil?

El síntoma: activas Hotspot móvil en Windows y o bien no se inicia, se inicia y se detiene instantáneamente, o “funciona” pero todos los clientes tienen Sin internet. Mientras tanto estás en una llamada, en un hotel o conectando un dispositivo de laboratorio que solo habla Wi‑Fi. Aquí Windows te recuerda que no es un router, solo finge serlo.

La causa habitual: un servicio abandonado llamado Compartir conexión a Internet (ICS) y sus compañeros—NAT, reglas de firewall, enlaces de adaptadores y la pila de adaptador virtual Wi‑Fi Direct—que se estropean por actualizaciones, VPN, herramientas “optimizadoras” o políticas corporativas bienintencionadas.

Guía de diagnóstico rápido

Si tienes prisa, no vagues por los interruptores de Configuración como si fuera una casa encantada. Quieres responder tres preguntas en orden: ¿Puede la pila Wi‑Fi alojar? ¿Está vivo ICS/NAT? ¿Se reenvía realmente el tráfico?

1) Primero: confirma que el mecanismo del hotspot está disponible

  • Comprueba si existen adaptadores virtuales Wi‑Fi Direct y si están habilitados.
  • Comprueba si el equipo tiene un adaptador Wi‑Fi funcional (suena obvio; a menudo no lo es).

2) Segundo: revisa el servicio que suele matarlo

  • ¿Está en ejecución el servicio Internet Connection Sharing (ICS)?
  • ¿Está en ejecución Windows Firewall (MpsSvc)? (ICS depende de él).
  • ¿Está en ejecución WLAN AutoConfig (Wlansvc)?

3) Tercero: demuestra que el enrutamiento/NAT y DNS funcionan de extremo a extremo

  • ¿Tiene el adaptador de hotspot una dirección IPv4 privada (normalmente 192.168.137.1)?
  • ¿Reciben los clientes DHCP, puerta de enlace predeterminada y DNS?
  • En el host, ¿puedes ver NAT configurada y contadores de tráfico moviéndose?

Hazlo en ese orden. De lo contrario “arreglarás” DNS cuando el adaptador nunca se creó, o reiniciarás la pila de red cuando un único servicio esté Deshabilitado por política.

Qué es realmente el hotspot de Windows (y qué no es)

El Hotspot móvil de Windows es una pequeña pila de suplantación de router:

  • Capa Wi‑Fi Direct / SoftAP crea una interfaz de punto de acceso virtual.
  • ICS (SharedAccess) une ese adaptador virtual a la conexión ascendente, ejecuta comportamiento tipo DHCP y configura el uso compartido.
  • NAT traduce el tráfico de tu subred privada del hotspot hacia la interfaz ascendente.
  • Reglas de firewall permiten los flujos correctos. Si los servicios de firewall están rotos, ICS tiende a fallar de maneras interesantes.
  • Manejo de DNS suele ser “suficientemente bueno” hasta que aparecen VPNs y agentes de endpoint corporativos con sus propias ideas.

Lo que no es: un equipo router completo. Tiene dependencias frágiles, cambia comportamiento entre versiones de Windows y tiende a asumir que tu pila de red no está siendo “gestionada” por software de terceros.

Verdad operacional: si tratas el hotspot de Windows como un puente de emergencia de último recurso y no como un componente estratégico de red, serás mucho más feliz. Cuando debes depender de él, necesitas un triaje rápido y correcciones reproducibles—de ahí esta guía.

Una idea para tener a la vista, parafraseada y atribuida a John Allspaw: La fiabilidad viene de cómo respondes a la falla, no de fingir que la falla no ocurrirá.

Datos históricos e contexto interesante (porque Windows no inventó NAT ayer)

  1. ICS precede a la interfaz “Hotspot móvil”. Internet Connection Sharing existe desde la era de Windows XP, mucho antes de que el moderno interruptor de la app Configuración lo hiciera parecer simple.
  2. Hosted Network vs Wi‑Fi Direct: las versiones antiguas de Windows usaban capacidades de “Hosted Network”; las más nuevas se han desplazado mayormente a implementaciones Wi‑Fi Direct/SoftAP según el soporte del driver.
  3. 192.168.137.0/24 es la subred clásica de ICS. Cuando ves 192.168.137.1 en un adaptador virtual, normalmente estás viendo a ICS aplicando su configuración por defecto.
  4. ICS y el firewall están acoplados. Rompe el servicio Windows Firewall, y ICS a menudo no arranca o no reenvía tráfico correctamente.
  5. Las VPN corporativas cambiaron las reglas. Políticas de túnel dividido, DNS forzado y drivers filtro NDIS tienen la costumbre de “ayudar” a tu hotspot hacia la no‑funcionalidad.
  6. Hyper‑V y la virtualización pueden complicar los enlaces de adaptadores. Los switches virtuales y drivers de puente pueden reordenar o renombrar interfaces, confundiendo la configuración de compartición.
  7. La gestión de energía es un asesino silencioso. Los adaptadores Wi‑Fi en portátiles reciben órdenes para “ahorrar energía”, lo cual es adorable hasta que intentas que actúen como punto de acceso.
  8. Las actualizaciones de Windows pueden restablecer los tipos de inicio de servicio. No es común, pero sí lo bastante frecuente como para estar en todos los playbooks de incidentes.

Broma #1 (corta, relevante): El hotspot de Windows es como un proyector de sala de reuniones: funciona perfectamente hasta que alguien lo necesita.

El servicio que suele estar muerto: ICS (SharedAccess)

Si tu hotspot se inicia y luego se detiene, o nunca se inicia, o muestra “Sin internet” para los clientes mientras tu portátil está bien, asume que SharedAccess está detenido, deshabilitado o incapaz de enlazar con el adaptador correcto.

ICS es más que un interruptor de servicio. Es un motor de configuración que:

  • decide qué interfaz es “pública” (ascendente) y cuál es “privada” (hotspot),
  • asigna una subred privada y asigna al adaptador del hotspot una IP,
  • habilita el comportamiento NAT,
  • abre huecos en el firewall para permitir el reenvío y el comportamiento tipo DHCP,
  • puede confundirse por múltiples ascendentes (Wi‑Fi + Ethernet + VPN + celular).

Lo que más lo mata:

  • Tipo de inicio del servicio establecido en Disabled (por política, “debloat” o endurecimiento de seguridad realizado sin comprender dependencias).
  • Servicio de firewall no en ejecución (o un producto de firewall de terceros que lo desinstaló a medias).
  • Cliente VPN que instala drivers filtro NDIS que cambian el enrutamiento y DNS de formas que ICS no puede reconciliar.
  • Driver Wi‑Fi que no soporta las funciones SoftAP/Wi‑Fi Direct requeridas, o el adaptador virtual está oculto/deshabilitado.
  • Corrupción de la pila de red tras actualizaciones, cambios de driver o software “optimizador” agresivo.

Tareas prácticas: comandos, salidas, decisiones (12+)

Estas son las tareas que realmente ejecuto cuando me responsabilizan de poner un hotspot en funcionamiento en un entorno casi productivo (laboratorios, puentes de incidentes, dispositivos de campo). Cada tarea incluye: un comando, qué significa la salida y qué decisión tomar después.

Task 1: Check ICS service state (SharedAccess)

cr0x@server:~$ powershell -NoProfile -Command "Get-Service -Name SharedAccess | Format-List Status,StartType,Name,DisplayName"
Status      : Stopped
StartType   : Disabled
Name        : SharedAccess
DisplayName : Internet Connection Sharing (ICS)

Significado: ICS está detenido y deshabilitado. El hotspot normalmente fallará al iniciar, o se iniciará y luego se detendrá.

Decisión: Establece el tipo de inicio en Manual/Automatic y arráncalo. También averigua qué lo deshabilitó (política, línea base de seguridad, “debloat”).

Task 2: Enable and start ICS

cr0x@server:~$ powershell -NoProfile -Command "Set-Service -Name SharedAccess -StartupType Manual; Start-Service -Name SharedAccess; Get-Service SharedAccess"
Status   Name               DisplayName
------   ----               -----------
Running  SharedAccess       Internet Connection Sharing (ICS)

Significado: ICS ahora se está ejecutando.

Decisión: Intenta habilitar Hotspot móvil de nuevo. Si aún falla, comprueba el servicio de firewall y WLAN AutoConfig a continuación.

Task 3: Verify Windows Firewall service (MpsSvc)

cr0x@server:~$ powershell -NoProfile -Command "Get-Service -Name MpsSvc | Format-List Status,StartType"
Status    : Stopped
StartType : Disabled

Significado: El servicio de firewall está deshabilitado/detenido. ICS comúnmente depende de él y puede fallar incluso si SharedAccess está “Running”.

Decisión: Vuelve a habilitar MpsSvc, luego reinicia SharedAccess.

Task 4: Re-enable Firewall service and restart ICS

cr0x@server:~$ powershell -NoProfile -Command "Set-Service -Name MpsSvc -StartupType Automatic; Start-Service MpsSvc; Restart-Service SharedAccess; Get-Service MpsSvc,SharedAccess | Format-Table Name,Status,StartType"
Name        Status  StartType
----        ------  ---------
MpsSvc      Running Automatic
SharedAccess Running Manual

Significado: Las dependencias clave están arriba.

Decisión: Si el hotspot aún no puede iniciarse, pasa a las comprobaciones de adaptador/driver.

Task 5: Check WLAN AutoConfig (Wlansvc)

cr0x@server:~$ powershell -NoProfile -Command "Get-Service Wlansvc | Format-List Status,StartType"
Status    : Running
StartType : Automatic

Significado: El servicio de configuración Wi‑Fi está sano.

Decisión: Si el hotspot sigue roto, inspecciona adaptadores e interfaces virtuales Wi‑Fi Direct.

Task 6: List network adapters and find the hotspot virtual adapter

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Sort-Object Status,Name | Format-Table Name,InterfaceDescription,Status,LinkSpeed"
Name                         InterfaceDescription                                  Status     LinkSpeed
----                         --------------------                                  ------     ---------
Ethernet                     Intel(R) Ethernet Connection                          Up         1 Gbps
Wi-Fi                        Intel(R) Wi-Fi 6 AX201 160MHz                         Up         866.7 Mbps
Local Area Connection* 10    Microsoft Wi-Fi Direct Virtual Adapter                 Disconnected 0 bps
Local Area Connection* 11    Microsoft Wi-Fi Direct Virtual Adapter #2              Disconnected 0 bps

Significado: Existen adaptadores virtuales Wi‑Fi Direct. Eso es una buena señal: Windows tiene algo que puede usar para alojar.

Decisión: Si estos faltan por completo, probablemente estés tratando con soporte de driver, dispositivos ocultos deshabilitados o restricciones de directiva de grupo.

Task 7: Check whether the hotspot adapter got the expected ICS IP

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPConfiguration | Where-Object {$_.InterfaceAlias -like 'Local Area Connection*'} | Format-List InterfaceAlias,IPv4Address,IPv4DefaultGateway,DnsServer"
InterfaceAlias    : Local Area Connection* 10
IPv4Address       : 192.168.137.1
IPv4DefaultGateway:
DnsServer         :

Significado: El lado privado está configurado (192.168.137.1). Gateway/DNS en blanco es normal en la interfaz privada.

Decisión: Si no hay 192.168.137.1 (o no hay IPv4 en absoluto), ICS no configuró la interfaz—vuelve a centrarte en SharedAccess, MpsSvc y los registros de eventos.

Task 8: Check NAT configuration (on modern Windows builds)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetNat | Format-Table Name,InternalIPInterfaceAddressPrefix,ExternalIPInterfaceAddressPrefix,Active"
Name                             InternalIPInterfaceAddressPrefix ExternalIPInterfaceAddressPrefix Active
----                             ------------------------------- -------------------------------- ------
SharedAccess_NAT                 192.168.137.0/24                0.0.0.0/0                        True

Significado: Existe NAT y está activa para la subred ICS.

Decisión: Si no existe objeto NAT, ICS puede no estar aplicando correctamente. Reinicia SharedAccess; si aún falta, restablece la red y vuelve a comprobar las dependencias.

Task 9: Confirm routing table isn’t pointing clients into a black hole

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -AddressFamily IPv4 | Sort-Object -Property RouteMetric | Select-Object -First 8 | Format-Table DestinationPrefix,NextHop,InterfaceAlias,RouteMetric"
DestinationPrefix  NextHop        InterfaceAlias RouteMetric
-----------------  ------        -------------- -----------
0.0.0.0/0          192.0.2.1      Wi-Fi          25
192.168.137.0/24   0.0.0.0        Local Area Connection* 10 256
192.168.1.0/24     0.0.0.0        Wi-Fi          281

Significado: La ruta por defecto va por Wi‑Fi. La subred del hotspot está conectada directamente.

Decisión: Si la ruta por defecto apunta a una interfaz VPN cuando esperabas Wi‑Fi/Ethernet, puede que tengas una VPN de túnel forzado. Los clientes del hotspot pueden perder internet a menos que la política permita túnel dividido.

Task 10: Look at IP addressing on the upstream interface

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPConfiguration -InterfaceAlias 'Wi-Fi' | Format-List InterfaceAlias,IPv4Address,IPv4DefaultGateway,DnsServer"
InterfaceAlias     : Wi-Fi
IPv4Address        : 192.168.1.50
IPv4DefaultGateway : 192.168.1.1
DnsServer          : {192.168.1.1}

Significado: El ascendente parece sano.

Decisión: Si el DNS ascendente es un resolutor corporativo accesible solo mediante VPN, los clientes pueden mostrar “conectado, sin internet”. Decide si cambiar DNS en los clientes, desconectar la VPN o ajustar el túnel dividido.

Task 11: Check event logs for SharedAccess/ICS failures

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName System -MaxEvents 80 | Where-Object {$_.ProviderName -match 'SharedAccess|Service Control Manager'} | Select-Object -First 8 | Format-Table TimeCreated,ProviderName,Id,LevelDisplayName,Message -Wrap"
TimeCreated           ProviderName              Id  LevelDisplayName Message
-----------           ------------              --  ---------------- ------
2/5/2026 9:18:10 AM  Service Control Manager   7000 Error            The Internet Connection Sharing (ICS) service failed to start due to the following error: The service cannot be started, either because it is disabled or because it has no enabled devices associated with it.

Significado: Clásico: servicio deshabilitado o dependencia de adaptador ausente/deshabilitada.

Decisión: Verifica la presencia/habilitación del adaptador; verifica los tipos de inicio de servicio; elimina políticas “debloat”; luego reinicia.

Task 12: Validate Wi‑Fi driver support (Hosted network status hint)

cr0x@server:~$ netsh wlan show drivers
Interface name: Wi-Fi

    Driver                    : Intel(R) Wi-Fi 6 AX201 160MHz
    Vendor                    : Intel Corporation
    Provider                  : Intel
    Date                      : 1/10/2026
    Version                   : 23.20.0.4
    Radio types supported     : 802.11b 802.11g 802.11n 802.11ac 802.11ax
    Hosted network supported  : No
    Wireless Display Supported: Yes (Graphics Driver: Yes, Wi-Fi Driver: Yes)

Significado: “Hosted network supported: No” no mata automáticamente Hotspot móvil en versiones nuevas (Wi‑Fi Direct puede seguir funcionando), pero es una señal de advertencia: las capacidades del driver son limitadas o cambiadas.

Decisión: Si el hotspot no arranca y Hosted Network es No, prioriza actualizar drivers, drivers OEM o usar otro adaptador (Wi‑Fi USB que soporte SoftAP).

Task 13: Reset the network stack (the controlled burn)

cr0x@server:~$ powershell -NoProfile -Command "netsh int ip reset; netsh winsock reset"
Resetting Global, OK!
Resetting Interface, OK!
Restart the computer to complete this action.
Successfully reset the Winsock Catalog.
You must restart the computer in order to complete the reset.

Significado: Has reiniciado TCP/IP y Winsock. Esto puede limpiar LSP/filters corruptos y estados de interfaz malos.

Decisión: Reinicia. Luego vuelve a comprobar estados de servicio y presencia de adaptadores. Si esto es una máquina corporativa, espera que clientes VPN y agentes de endpoint se reafirmen después del reinicio.

Task 14: Check for “helpful” VPN routes and DNS changes

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table InterfaceAlias,ServerAddresses"
InterfaceAlias                 ServerAddresses
--------------                 --------------
Wi-Fi                          {10.10.10.53, 10.10.10.54}
Local Area Connection* 10      {}
Ethernet                       {}

Significado: El DNS ascendente de Wi‑Fi está establecido en resolutores corporativos (probablemente vía VPN o perfil). Si esos resolutores solo son accesibles por una interfaz VPN, los clientes del hotspot no podrán resolver nombres.

Decisión: Desconecta la VPN, habilita túnel dividido (si está permitido) o vuelve a establecer el DNS ascendente al DNS local/ISP mientras uses el hotspot.

Task 15: Verify firewall profiles (Public/Private) aren’t sabotaging sharing

cr0x@server:~$ powershell -NoProfile -Command "Get-NetConnectionProfile | Format-Table Name,InterfaceAlias,NetworkCategory,IPv4Connectivity"
Name           InterfaceAlias NetworkCategory IPv4Connectivity
----           -------------- -------------- ---------------
CorpWiFi       Wi-Fi          Public         Internet
Unidentified   Local Area Connection* 10 Private        NoTraffic

Significado: El ascendente es Público; el lado del hotspot es Privado (bien). Si ambos son Públicos con reglas de firewall estrictas, el reenvío puede estar bloqueado según la política.

Decisión: Si la política lo permite, establece el lado del hotspot como Privado. Si no está permitido, necesitarás otro enfoque (router de viaje, tethering del teléfono) en vez de pelear con la política.

Broma #2 (corta, relevante): Algunos clientes VPN tratan “compartir internet” como un incidente de seguridad. No están equivocados; solo son inconvenientes.

Modos de fallo por síntoma (lo que te está diciendo)

Síntoma A: El interruptor de Hotspot móvil se activa y luego se apaga inmediatamente

Este es el patrón clásico de “la dependencia murió”. La interfaz de Windows es optimista; la capa de servicios no lo es.

  • Más probable: SharedAccess detenido/deshabilitado; MpsSvc deshabilitado; adaptador ausente; driver incapaz de crear la interfaz Wi‑Fi Direct.
  • También común: firewall/VPN de terceros que ha insertado drivers filtro y ha dejado la pila inconsistente.

Síntoma B: El hotspot se enciende, los clientes se conectan, pero no hay internet

Normalmente esto no es “Wi‑Fi”. Es enrutamiento, NAT o DNS.

  • Probable: falta NAT o no está ligada; la ruta ascendente pasa por VPN; resolutores DNS inaccesibles; el cliente recibió una dirección APIPA (169.254.x.x) por fallo de DHCP.
  • Menos probable: portal cautivo ascendente no completado (Wi‑Fi de hotel), así que el host tiene internet por sesiones en caché pero los clientes nuevos no.

Síntoma C: Error “No podemos configurar el hotspot móvil”

Ese mensaje es Windows declinando cortésmente decirte qué componente interno falló. Usa registros de eventos y comprobaciones de servicios para hacerlo hablar.

Síntoma D: El hotspot funciona tras reiniciar, luego falla cuando se conecta la VPN

Eso es una pelea de enrutamiento/DNS. La VPN gana, el hotspot pierde y tú tienes que mediar con herramientas que probablemente no deberías necesitar.

Síntoma E: Opción de hotspot ausente por completo

O bien el dispositivo no tiene un adaptador/driver Wi‑Fi compatible, o está bloqueado por política (MDM/GPO), o estás en una edición/compilación de Windows con restricciones. Soporte de drivers y política corporativa son los dos primeros sospechosos.

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

Estos son los reincidentes que veo en flotas reales. Las soluciones son específicas porque el consejo vago es como terminar reinstalando Windows a las 2 a.m.

1) El hotspot no arranca en absoluto

Síntoma: El interruptor se enciende y luego se apaga; error sobre fallo de configuración.

Causa raíz: servicio SharedAccess deshabilitado o fallando al arrancar; a veces por política o scripts “debloat”.

Solución: Establece SharedAccess en Manual; arráncalo; verifica que MpsSvc esté Running; luego reintenta.

2) Los clientes se conectan pero obtienen “Sin internet”

Síntoma: Wi‑Fi muestra conectado; la navegación falla; timeouts de DNS.

Causa raíz: VPN de túnel forzado establecida como ruta por defecto; DNS apunta a resolutores accesibles solo por VPN; objeto NAT ausente.

Solución: Desconecta la VPN (o permite túnel dividido); restaura el DNS ascendente; confirma que Get-NetNat muestra SharedAccess_NAT activo.

3) Los clientes obtienen direcciones 169.254.x.x

Síntoma: El cliente tiene dirección APIPA; no puede alcanzar 192.168.137.1.

Causa raíz: el comportamiento DHCP de ICS no funciona porque SharedAccess no aplica la configuración, o las reglas de firewall lo bloquean.

Solución: Asegura que SharedAccess y MpsSvc estén en ejecución; restablece la red; luego verifica que el adaptador del hotspot obtenga 192.168.137.1.

4) El hotspot funciona solo en 2.4 GHz (o solo en 5 GHz) y desaparece aleatoriamente

Síntoma: Algunos clientes no ven el SSID; otros se conectan bien.

Causa raíz: problemas de dominio regulatorio/canal; limitaciones del driver; confusión por band steering; chipsets cliente que no soportan ciertos canales.

Solución: Fuerza una banda distinta en la configuración del hotspot si está disponible; actualiza drivers Wi‑Fi; evita canales DFS usando 2.4 GHz para compatibilidad.

5) “Deshabilité Windows Firewall para probar” y ahora está peor

Síntoma: Apagaste el firewall y el hotspot murió por completo.

Causa raíz: Deshabilitar el servicio (MpsSvc) en lugar de solo un perfil rompe las expectativas de ICS.

Solución: Vuelve a habilitar el servicio MpsSvc, ponlo en Automatic, arráncalo; deja que los perfiles los controle la política si es necesario.

6) El hotspot funcionaba; tras actualizar el driver dejó de hacerlo

Síntoma: Adaptador virtual ausente; la opción de hotspot presente pero falla.

Causa raíz: El paquete de drivers cambió las capacidades Wi‑Fi Direct/SoftAP o creó un dispositivo que está deshabilitado/oculto.

Solución: Revertir el driver; instalar el driver OEM; comprobar adaptadores Wi‑Fi Direct en Get-NetAdapter.

7) La política corporativa bloquea ICS

Síntoma: SharedAccess se fuerza a Disabled después de cada reinicio; interruptor de hotspot ausente o falla consistentemente.

Causa raíz: MDM/GPO bloqueo por línea base de seguridad para evitar el puenteo de redes.

Solución: No luches con la política en los endpoints. Solicita una excepción o usa un router de viaje / tethering de teléfono aprobado.

8) “Restablecer red” lo arregló una vez, luego volvió a fallar

Síntoma: Funciona tras reset/reinicio; falla después de que el cliente VPN/agent de seguridad actualiza.

Causa raíz: Un driver filtro NDIS de terceros o una política reintroduce la configuración que rompe.

Solución: Identifica el componente culpable (VPN, firewall de endpoint) y coordina con IT; trata el restablecimiento de red como una solución temporal.

Tres mini‑historias del mundo corporativo (anonimizadas, plausibles, técnicamente correctas)

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

Un equipo de campo necesitaba actualizar firmware en un lote de sensores de laboratorio en la ubicación de un cliente donde el Wi‑Fi de invitados bloqueaba dispositivos pares. El plan era simple: el portátil del ingeniero crea un hotspot, los sensores se conectan, el firmware se empuja localmente, y listo. El ingeniero lo había hecho cien veces en casa.

En sitio, el interruptor del hotspot se activó y se apagó inmediatamente. El equipo asumió “la tarjeta Wi‑Fi está muerta” y solicitó por mensajería un dongle Wi‑Fi USB para la noche siguiente. Mientras tanto, los sensores quedaron inactivos y el gerente de proyecto empezó a redactar el tipo de correo que parece una actualización de currículum.

El problema real fue más tonto: una línea base de endurecimiento del endpoint había puesto SharedAccess en Disabled meses antes durante una limpieza de seguridad. Nadie lo relacionó con Mobile hotspot porque la interfaz no dice “ICS está deshabilitado por política”. Simplemente se encoge de hombros.

La solución fue una excepción de política aplicada a un grupo específico de dispositivos, además de una entrada en el runbook: antes de viajar, comprobar el estado de SharedAccess/MpsSvc. El dongle USB llegó al día siguiente de todos modos—todavía en su envoltorio, como un monumento a las suposiciones.

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

Un equipo de TI corporativo decidió “acelerar el arranque” deshabilitando servicios que “nadie usa”. Usaron un script sacado de internet—siempre un inicio prometedor—y lo desplegaron a un subconjunto de portátiles como piloto.

Todo parecía bien hasta que un ingeniero de ventas necesitó compartir Ethernet de hotel con un dispositivo de demostración. El hotspot falló. Luego otro ingeniero tuvo el mismo problema al montar una red rápida de laboratorio en una sala de conferencias. Ambas escaladas llegaron a la misma cola de soporte en pocas horas.

La lista de culpables fue predecible: SharedAccess deshabilitado; MpsSvc puesto en Manual y no arrancando; un par de servicios de red auxiliares retrasados. La “optimización” ahorró una fracción de segundo en el arranque y costó varias horas‑persona y daño reputacional. El piloto se revirtió.

La mejora duradera no fue “nunca optimizar”. Fue: si vas a cambiar líneas base de servicios, mantiene un mapa de dependencias y prueba flujos de trabajo reales––incluyendo hotspot/ICS, VPN y escenarios de conexión a dock. Las ganancias de rendimiento que rompen flujos de trabajo críticos no son ganancias; son un incidente con mejor marca.

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

Una empresa regulada tenía una postura estricta: no se permiten puentes hotspot ad hoc desde dispositivos corporativos a menos que estén aprobados explícitamente. Eso es normal. Lo que lo hizo operativo fue que las excepciones se manejaban como ingeniería, no como favores.

Un equipo de laboratorio solicitó acceso hotspot para un pequeño conjunto de dispositivos usados en una sala de pruebas blindada sin drops LAN. Seguridad aceptó, pero exigió protecciones: solo ciertos portátiles, solo en horario de laboratorio y con registro. TI creó un pequeño paquete de configuración que puso SharedAccess en Manual (no Disabled), aseguró que MpsSvc fuera Automatic y validó versiones de drivers para el modelo de adaptador Wi‑Fi aprobado.

Meses después, una actualización de Windows cambió el comportamiento de red en algunas máquinas. Los portátiles del laboratorio no se vinieron abajo porque el paquete de configuración se ejecutaba en cada check‑in y reparaba la deriva. El laboratorio tenía una lista de verificación, y el SRE de turno tenía estados conocidos buenos con los que comparar.

Era aburrido. También funcionó. La mayoría de victorias de fiabilidad parecen “no pasó nada”, que es el mayor cumplido que los sistemas de producción pueden darte.

Listas de verificación / plan paso a paso

Checklist 1: Hacer que el hotspot funcione en una máquina Windows personal normal

  1. Reinicia una vez (sí, de verdad). Si lo arregla, procede de todos modos—las victorias intermitentes son cómo los problemas vuelven.
  2. Comprueba SharedAccess para que no esté Disabled; arráncalo.
  3. Comprueba MpsSvc que esté Running y en Automatic.
  4. Comprueba Wlansvc que esté Running y en Automatic.
  5. Verifica que existan adaptadores virtuales Wi‑Fi Direct (Get-NetAdapter; busca Microsoft Wi‑Fi Direct Virtual Adapter).
  6. Habilita el hotspot en Configuración y observa si permanece habilitado durante 30 segundos.
  7. Verifica la IP del adaptador del hotspot es 192.168.137.1 (u otro rango privado si está personalizado).
  8. Conecta un cliente; confirma que recibe una dirección 192.168.137.x y puerta de enlace 192.168.137.1.
  9. Desde el cliente prueba ping a 192.168.137.1, luego resolución DNS, luego HTTP a un sitio conocido.

Checklist 2: Enfoque para dispositivo corporativo (consciente de políticas)

  1. Asume que la política bloquea ICS hasta que se demuestre lo contrario. Comprueba el StartType de SharedAccess; si está forzado a Disabled, detén y escala adecuadamente.
  2. Desconecta la VPN para la prueba (a menos que la política requiera VPN siempre encendida; si es así, acepta que el hotspot puede ser intencionadamente imposible).
  3. Confirma que el producto de firewall del endpoint no deshabilita el servicio MpsSvc. Si lo hace, necesitas configuración del proveedor/IT, no un truco local.
  4. Revisa los registros de eventos por errores del Service Control Manager alrededor de SharedAccess y MpsSvc.
  5. No “arregles” desinstalando software de seguridad. Eso limita tu carrera.
  6. Si es crítico para el negocio: usa un router de viaje aprobado o tethering de teléfono; trata el hotspot de Windows como no garantizado bajo controles corporativos.

Checklist 3: Triaje de “hotspot sin internet”

  1. Confirma que el host tiene internet en la interfaz ascendente.
  2. Confirma que el cliente tiene IP, gateway y DNS.
  3. En el host, confirma que existe NAT (Get-NetNat) y que el adaptador del hotspot tiene 192.168.137.1.
  4. Si el cliente puede hacer ping a 192.168.137.1 pero no resolver nombres, es alcance DNS (a menudo VPN).
  5. Si el cliente puede resolver nombres pero no alcanzar IPs, es NAT/enrutamiento/firewall.
  6. Si el cliente no obtiene IP, es ICS/servicio/reglas de firewall.

Preguntas frecuentes

1) ¿Por qué el hotspot de Windows depende de ICS?

Porque compartir hotspot es esencialmente “compartir esta conexión ascendente con esa interfaz privada”, que es exactamente para lo que se creó ICS. La interfaz se volvió moderna; la plomería se quedó familiar.

2) Si SharedAccess está en ejecución, ¿por qué sigue fallando el hotspot?

Ejecutándose no es lo mismo que funcionando. ICS puede estar en ejecución pero incapaz de enlazar con los adaptadores correctos, bloqueado por política de firewall, sin configuración NAT o tropezando con drivers filtro de VPN. Comprueba MpsSvc, presencia de adaptadores y registros de eventos.

3) ¿Por qué los clientes se conectan pero muestran “Sin internet”?

Normalmente DNS o enrutamiento. El cliente puede hablar con el AP, pero la resolución de nombres apunta a servidores DNS inalcanzables (común con VPN), o NAT no está traduciendo el tráfico hacia la interfaz ascendente.

4) ¿Qué significa 192.168.137.1?

Es la IP privada por defecto que Windows asigna a la interfaz compartida (hotspot) cuando ICS aplica la configuración. Verla es una señal fuerte de que ICS realmente aplicó configuración.

5) ¿Puedo cambiar la subred ICS de 192.168.137.0/24?

A veces sí, pero no es un control amigable y el comportamiento varía por versión. Si entras en conflicto con una red 192.168.137.0/24 existente, la solución pragmática es evitar esa red ascendente o usar un router dedicado que permita elegir subredes limpiamente.

6) ¿Por qué dejó de funcionar después de instalar una VPN?

Los clientes VPN suelen instalar drivers filtro de red, imponer ajustes DNS y reescribir rutas. Eso puede romper el reenvío NAT o hacer que el DNS sea inalcanzable para los clientes del hotspot. Si la política lo permite, prueba desconectando la VPN.

7) ¿“Hosted network supported: No” significa que el hotspot no puede funcionar?

No siempre. Algunas implementaciones modernas del hotspot dependen de Wi‑Fi Direct en vez de la antigua función Hosted Network. Pero si tienes fallos y ves Hosted Network unsupported, las limitaciones del driver se vuelven un sospechoso principal.

8) ¿Deshabilitar Windows Firewall es una buena medida de prueba?

Apagar un perfil de firewall puede ser informativo. Deshabilitar el servicio (MpsSvc) suele ser destructivo para ICS/hotspot. Mantén el servicio en ejecución.

9) ¿Por qué el hotspot funciona tras reiniciar pero falla más tarde?

Algo reconfigura la pila de red después del arranque: VPN que se conecta automáticamente, actualización de política del firewall de endpoint, gestión de energía del driver o cambio de estado del adaptador tras salir de suspensión. Rastrea qué cambia entre “funciona” y “no funciona”.

10) ¿Cuál es la solución alternativa más fiable cuando el hotspot de Windows es inestable?

Un pequeño router de viaje o tethering de teléfono. No es glamuroso, pero es hardware de red diseñado para eso en lugar de un SO de escritorio fingiendo ser uno.

Próximos pasos (haz esto, no aquello)

Cuando falla el hotspot de Windows, no empieces por reinstalar drivers o hacer clic en interruptores hasta que tu ratón se desgaste. Comienza con la verdad aburrida: SharedAccess (ICS) y MpsSvc son los cadáveres habituales. Reanímalos, confirma que el adaptador del hotspot obtiene su IP privada, luego demuestra que NAT y DNS funcionan.

Haz esto:

  • Comprueba los estados y tipos de inicio de SharedAccess, MpsSvc, Wlansvc.
  • Verifica que existan adaptadores virtuales Wi‑Fi Direct.
  • Confirma 192.168.137.1 (o tu IP privada configurada) en el adaptador del hotspot.
  • Revisa NAT y enrutamiento; sospecha de la VPN cuando los clientes ven “Sin internet”.
  • Usa los registros de eventos para reemplazar conjeturas por evidencia.

Evita esto:

  • Deshabilitar el servicio de Firewall “a ver si ayuda”. Por lo general perjudica.
  • Scripts “optimizadores” aleatorios que deshabilitan servicios sin mapa de dependencias.
  • Peleas locales contra política corporativa. Si ICS está bloqueado por diseño, escala o usa hardware aprobado.

Si quieres una regla operativa: trata el hotspot de Windows como un grafo de dependencias, no como un botón. El botón es la parte menos interesante.

← Anterior
El «backup» de OneDrive no es una copia de seguridad: cómo hacerlo correctamente
Siguiente →
Preparativos para el fin de vida de Windows 10: Qué hacer antes de entrar en pánico

Deja un comentario