Por qué el portal cautivo bloquea tu VPN y cómo volver a iniciar sesión

En una red abierta, tu punto de acceso no entrega paquetes a internet sin más. Un punto de política aguas arriba comprueba si tu dispositivo ya está autorizado, y hasta que lo esté, casi todo se descarta. Tu cliente VPN lee ese silencio como un servidor muerto. Rara vez lo dice: WireGuard reintenta un saludo dentro del vacío, OpenVPN informa de un tiempo de espera de conexión, e IKEv2 vuelve con el error 809 sobre un servidor remoto que no responde.

Qué controla realmente el portal

Un portal cautivo son dos cosas pegadas: un punto de decisión de política y un redireccionador. Cuando tu dispositivo se asocia y obtiene una concesión DHCP, la red te coloca en un estado previo a la autorización.

Ese estado es un conjunto de reglas de cortafuegos. Normalmente permite DNS y permite HTTP o HTTPS hacia una lista corta de hosts del portal, y descarta todo lo demás. La lista permitida es el jardín amurallado, y casi nunca incluye un extremo de VPN.

Ninguno de esos descartes es amable. Los paquetes dirigidos a un servidor VPN se descartan en lugar de rechazarse, así que el cliente no recibe ni ICMP unreachable ni un reset de TCP, solo la ausencia de respuesta. Según el fabricante, el redireccionador puede responder al puerto 80 con una redirección a la página de inicio de sesión mientras el puerto 443 se descarta o se intercepta. Las redirecciones son fáciles de detectar porque llevan una respuesta HTTP simple; la interceptación en el 443 necesita un certificado en el que tu navegador se negará a confiar.

La autorización en sí suele estar ligada a la dirección MAC del dispositivo, a veces a la IP concedida, y vive en una tabla de sesiones con un temporizador. Iniciar sesión crea una entrada. La regla de cortafuegos que deja pasar tu tráfico solo existe mientras existe esa entrada, y por eso todo el problema vuelve más tarde sin que cambie nada por tu parte.

Por qué el saludo de la VPN muere antes de empezar

Cada protocolo tiene su propio transporte, y el cortafuegos previo a la autorización rompe cada uno de forma distinta. IKEv2 en Windows e iOS va sobre UDP 500 y UDP 4500; un descarte en esos puertos se manifiesta como 809, o como un fallo de estilo de resolución de nombres en clientes que informan de las etapas por separado. OpenVPN sobre UDP 1194 se queda en estado de conexión hasta que expira su tiempo de espera. OpenVPN sobre TCP 443 es el caso interesante, porque el portal puede completar el saludo TCP y luego responder con su página de redirección, así que ves un error TLS en lugar de un tiempo de espera.

WireGuard muestra el mecanismo con más claridad. Es solo UDP por diseño, sin alternativa TCP, así que un cortafuegos que descarta UDP desconocido elimina el transporte por completo. El cliente sigue enviando inicios de saludo con un retroceso creciente e informa de un saludo que nunca se completa. Nada en ese mensaje menciona el Wi-Fi, y nada en él sugiere que debas abrir un navegador.

Las plataformas intentan notar el estado antes que tu VPN. Windows solicita una URL conocida para decidir si muestra su notificación de inicio de sesión, Android pide un extremo que debería responder 204 No Content, y los dispositivos Apple abren una pequeña ventana de red cautiva. Esas sondas funcionan porque el portal responde con una redirección en lugar del cuerpo esperado. El mismo comportamiento explica cómo un portal puede parecer perfectamente sano mientras tu túnel está muerto: la sonda y el túnel se juzgan con reglas distintas.

Qué reinicia realmente una caducidad de sesión

Los locales caducan sesiones por motivos ajenos a tu cuenta de VPN: un tiempo de inactividad, una duración máxima de sesión, una nueva concesión DHCP o una reasociación a otro punto de acceso. Cuando salta el temporizador, la entrada de la tabla de sesiones desaparece y el conjunto de reglas previo a la autorización vuelve exactamente como estaba en el registro.

Un túnel establecido a menudo sobrevive lo suficiente para parecer sano. Los mensajes de mantenimiento siguen saliendo, y si el cliente lo nota depende de cómo trate el tráfico sin respuesta, así que la luz de estado puede quedarse verde un rato después de que el camino desaparezca. Luego el túnel cae y cada intento de reconexión falla en los mismos puertos bloqueados.

En ese punto, el error del cliente te dice en qué etapa estás, si lo lees con atención:

Un detalle engaña a la gente: cuando la sesión está ligada a una dirección MAC, recargar la página de inicio de sesión puede no ayudar. Tienes que romper la asociación y unirte de nuevo para que el portal vea un nuevo intento de autorización en lugar de uno caducado.

Primero inicia sesión, después levanta el túnel

El orden que funciona es: autoriza el dispositivo, demuestra el camino, arranca la VPN, demuestra el túnel y luego restaura tu bloqueo habitual. Ese último paso importa porque el estado temporal que necesitas para llegar al portal es exactamente el estado que un interruptor de seguridad existe para impedir.

Un cliente de escritorio con la opción de bloquear fuera del túnel tiene que pausarse para que cargue la página del portal, y deberías mantener cerradas las aplicaciones sensibles durante esa ventana fuera del túnel; es el único intervalo en el que el tráfico local sale sin protección. Un dispositivo gestionado siempre encendido debería usar el procedimiento que publicó su propietario en lugar de que tú elimines la política. Si el portal muestra un aviso de certificado, detente: aceptarlo encamina tu sesión por el proxy de interceptación del local, y ese proxy puede leer todo lo que envías. En Android, el bloqueo con VPN siempre activa bloquea el tráfico antes de que el túnel esté levantado, y algunas compilaciones no pueden eximir el flujo del portal; si la tuya no puede, usa el acceso alternativo del local u otro dispositivo en lugar de dejar el bloqueo desactivado. Las reglas de Apple bajo demanda pueden escribirse para rechazar el túnel hasta que una sonda tenga éxito, que es el comportamiento que quieres en redes de hotel.

Verifica en orden con las herramientas que ya tienes. Antes del túnel, ejecuta la sonda con las cabeceras y el cuerpo ambos visibles, y observa si tu transporte VPN recibe alguna respuesta:

curl -sS -D - http://captive.apple.com/hotspot-detect.html -o -
sudo tcpdump -ni any 'udp port 500 or udp port 4500 or udp port 1194'

Antes de la autorización, un portal normal da una de dos respuestas: un 302 cuyo Location apunta a la página de inicio de sesión, o un 200 con un cuerpo HTML que es la página del portal. Anota cuál recibiste. Una redirección no es un fallo antes de iniciar sesión; es el portal diciéndote adónde ir. Después de que el portal informe de éxito, repite el comando y espera un 200 cuyo cuerpo sea la palabra literal Success. Esa cadena es lo que hace significativa la sonda. Si el host responde con normalidad antes de que hayas iniciado sesión, en esta red no hay portal de interceptación. En la captura, un descarte previo a la autorización son paquetes salientes de los que no vuelve nada, mientras que un camino que funciona muestra una respuesta al mismo flujo en cosa de un segundo. Conéctate y luego repite la captura.

Si el túnel sigue fallando después de que el portal diga sí

El éxito del inicio de sesión no es lo mismo que un transporte permitido. Muchos locales permiten el portal y la navegación normal mientras bloquean UDP por completo, lo que deja WireGuard y OpenVPN sobre UDP rotos y TCP 443 funcionando. Si TCP 443 pasa y UDP no, eso es política del local y no un cliente que hayas configurado mal, así que cambia de transporte o acepta el límite y sigue. Si una reconexión sigue fallando después de eso, guarda el error exacto; nombra la etapa en la que estás atascado.

Otros fallos viven en el dispositivo. Una sesión aún ligada a una MAC antigua, un segundo adaptador Wi-Fi con su propia concesión, o un cliente que ha memorizado la excepción de certificado del portal pueden seguir fallando tras una reautorización limpia. Rompe la asociación, vuelve a autorizar y reintenta una vez antes de tocar la configuración del cliente. RFC 8952 vale la pena leerlo si quieres la arquitectura que hay detrás de los componentes que estás vigilando.

Si el propio portal se niega a autorizar, el problema es de la cuenta o de la asignación del dispositivo y ninguna configuración de VPN lo arreglará. Cambiar el país de salida de la VPN no reinicia el estado de acceso local del local; esa tabla está ligada a tu dispositivo, no al servidor que elijas. Pregunta al operador del local y dale tiempo, porque la tabla de sesiones es lo que mirará.

Antes de tu próximo viaje, anota tres cosas: la página del portal como paso cero, el paso de pausar el bloqueo para cada dispositivo que lleves, y una alternativa de transporte que hayas probado de verdad. Cuando un túnel que funcionaba hace diez minutos vuelva a pararse, trátalo como una autorización caducada y vuelve a comprobar el portal antes de tocar el perfil de la VPN.