El interruptor de seguridad sigue bloqueando el tráfico tras desconectar la VPN

El túnel desapareció, el icono de red parece normal y nada se carga. Desconectaste la VPN, la desinstalaste o reiniciaste, y el bloqueo que debía protegerte durante una caída sigue en pie. La ventana del cliente no puede explicarlo, porque el cliente no es lo que te bloquea: la decisión se escribió en el kernel en tu nombre y no se dejó nada para eliminarla. En Windows ese estado vive en la Plataforma de filtrado de Windows; en Linux es un conjunto de reglas en iptables o nftables, a menudo con una instantánea que se reproduce al arrancar. Lo que sigue es el orden que uso: leer el estado, eliminar el objeto más estrecho que explica el fallo y luego encontrar lo que sea que lo vuelva a poner.

Un interruptor de seguridad es estado del kernel, no un ajuste

Los clientes de escritorio implementan el bloqueo añadiendo filtros que deniegan el tráfico fuera del túnel. En Windows son filtros WFP en las capas de redirección de conexión y de transporte, y algunos son persistentes: se registran en el almacén de directivas de Base Filtering Engine y se restauran cuando la máquina arranca, antes de que se ejecute ningún software VPN. Los clientes difieren en cuándo limpian. Algunos eliminan los filtros al desconectar, otros solo en una salida limpia y otros solo cuando primero se apaga el interruptor. Desinstala mientras el bloqueo está activo, o mata el proceso y los filtros se quedan.

El equivalente en Linux es una regla de descarte o rechazo en la ruta de salida, a veces una regla de reenvío, a veces una política de cadena modificada. Esas reglas sobreviven al proceso que las añadió porque son estado del kernel: mata el cliente, hazlo fallar o corta la energía, y el kernel sigue descartando paquetes sin que quede nada para deshacerlo. Un paquete de persistencia añade una segunda capa de permanencia al tomar una instantánea del conjunto de reglas actual y restaurarla al arrancar, de modo que el siguiente inicio comienza con el bloqueo ya instalado.

Lee el estado de WFP antes de borrar nada

Windows incluye las herramientas que necesitas. Ejecuta un símbolo del sistema elevado y vuelca el estado de la plataforma; el volcado aparece como wfpstate.xml en el directorio de trabajo.

netsh wfp show state
netsh wfp show filters
Get-Service bfe

Busca en el XML el nombre del proveedor que se fue, una acción Block y la capa. Los filtros en la redirección de conexión y el transporte son los que rompen el tráfico ordinario; un filtro en una capa de aceptación de recepción normalmente no es tu causa. Si Base Filtering Engine no se ejecuta en absoluto, busca en otro sitio, porque nada más puede aplicar esos filtros.

Comprueba también la vista ordinaria del cortafuegos, porque la mayoría de la gente solo inspecciona una de las dos:

netsh advfirewall show allprofiles
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

Cuando los perfiles integrados están activados y ninguna regla coincide con el tráfico que falla, el bloqueo viene de un proveedor externo y no del cortafuegos de Windows. Esa distinción decide qué herramienta usarás para la reparación.

Lee las reglas de Linux en la sintaxis con la que vas a borrar

iptables -S imprime las reglas en la misma forma que se usa para añadirlas, lo que hace que la salida sea directamente reutilizable para un borrado. iptables -L -v -n añade contadores de paquetes, y esos contadores te dicen si una regla coincide realmente con tus peticiones fallidas o simplemente está en la cadena.

sudo iptables -S
sudo ip6tables -S
sudo iptables -t nat -S

Lee las políticas de las cadenas, no solo las reglas: -P OUTPUT DROP bloquea el tráfico incluso cuando ninguna regla coincide. Inspecciona IPv6 por separado, porque un cliente que instala ambas familias puede dejar el bloqueo de IPv6 en su sitio después de que las reglas de IPv4 hayan desaparecido, y el síntoma depende entonces de qué familia prefiere una aplicación. Donde se usa nftables, ejecuta también nft list ruleset; las dos herramientas conviven mediante una capa de compatibilidad, y un listado no muestra necesariamente todas las reglas que pueden descartar un paquete.

Elimina el objeto más estrecho que explica el fallo

En Windows el primer paso sigue siendo la propia vía de eliminación del proveedor: vuelve a ejecutar el instalador y usa reparar o desinstalar, o ejecuta la herramienta de limpieza si el proveedor publica una. Los servicios y tareas programadas sobrantes son habituales, y una tarea que inicia el cliente al iniciar sesión reinstala sus filtros en el siguiente arranque. Una desinstalación que falla al leer la clave de registro del cliente normalmente significa que un servicio o una tarea aún la retiene, no que el registro esté dañado.

Get-ScheduledTask | Where-Object TaskName -like '*vpn*'
Get-Service | Where-Object DisplayName -like '*vpn*'

Los filtros persistentes son el último recurso. Viven bajo HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, un valor por filtro con clave GUID. Exporta primero la clave, anota los GUID que elimines, borra solo los valores que pertenecen al cliente que se fue y reinicia para que el motor reconstruya su estado. No borres toda la clave ni desactives Base Filtering Engine: el cortafuegos de Windows y Defender dependen de él, y cambiarías una caída por otra peor.

reg export "HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent" C:\temp\bfe-backup.reg

En Linux, toma la línea que imprime iptables -S y sustituye -A por -D. Borrar la única regla que has identificado es mejor que vaciar una cadena, porque deja tu propia política intacta.

sudo iptables -D OUTPUT -p udp -j REJECT

Si el descarte vive en una cadena definida por el usuario, borra primero el salto a esa cadena y quita la cadena con -X después. Poner la política de una cadena en ACCEPT mientras las reglas de descarte siguen presentes solo ayuda a los paquetes que llegan a la decisión de política. Vaciar todas las tablas es el último recurso: también elimina reglas que añadiste por otros motivos, y con ufw activado deja al servicio creyendo que posee cadenas que ya no existen.

Encuentra al propietario que lo vuelve a poner

Después de la reparación inmediata, busca cualquier cosa que pudiera restaurar el estado. En Linux, comprueba si hay una unidad de persistencia habilitada, si el cliente tiene un ajuste de restauración del cortafuegos al iniciar sesión y si existe un archivo de reglas guardado bajo /etc. En Windows, revisa de nuevo las entradas de inicio, los servicios y las tareas programadas, luego reinicia y vuelve a leer el estado con los mismos comandos que antes.

Si el bloqueo vuelve, el borrado no era la solución; lo era el propietario. Anota qué cliente o servicio lo instala y desactiva la función allí, en lugar de pelearte con ella en la capa del cortafuegos tras cada desconexión.

Verifica con tráfico real, no con un solo ping

Prueba una consulta de nombre, una conexión TCP y una sesión de navegador nueva, luego reinicia y repite las mismas tres comprobaciones. Un ping que funciona mientras HTTPS falla apunta a un filtro de la capa de transporte y no a la red, y un bloqueo que reaparece solo tras el reinicio apunta a un propietario que aún no has encontrado.

Guarda las pruebas: la clave BFE exportada o la salida de iptables -S capturada antes del cambio. Antes de darlo por arreglado, confirma la capa de la que eliminaste el objeto, el propietario que podría reinstalarlo, el estado tras un reinicio limpio y que la navegación ordinaria funciona sin ningún proceso VPN en marcha. La página del manual iptables(8) tiene la sintaxis exacta de borrado y de política si automatizas la limpieza con un script.