OpenVPN en Windows: problemas con el controlador TAP y cómo repararlos

octubre 15, 2025 • febrero 3, 2026 • Lectura: 25 min • Views: 12

¿Te fue útil?

Haces clic en “Conectar”. El registro avanza. El intercambio TLS parece correcto. Luego: nada. O peor, se conecta pero no alcanzas nada, el DNS se vuelve loco
y tu portátil se transforma en una isla diminuta en medio de la red corporativa.

Cuando OpenVPN en Windows se porta mal, el controlador TAP suele ser un sospechoso habitual. No siempre culpable, pero a menudo está cerca de la escena con un destornillador.
Esta es la guía de campo que desearía que más equipos tuvieran: cómo se rompe TAP, cómo probarlo y cómo repararlo sin convertir tu máquina en una escena del crimen de redes.

TAP en Windows: qué es y por qué falla

OpenVPN en Windows utiliza tradicionalmente una interfaz de red virtual llamada TAP-Windows. Piénsalo como una NIC por software.
OpenVPN escribe tramas Ethernet en ella y lee tramas desde ella. Windows la trata como un adaptador real: le asigna una IP, establece rutas,
aplica políticas de firewall y, a veces, la “optimiza” metiéndola en un barranco.

Hay dos familias principales de “adaptadores virtuales” que verás en el ecosistema OpenVPN:

TAP: capa 2-ish. Puede transportar tramas Ethernet y se usa para configuraciones estilo dev tap.
También puede emplearse con dev tun en algunas distribuciones empaquetadas, pero TAP no es lo mismo que TUN.
Wintun: un controlador más nuevo orientado a capa 3. Es común en compilaciones recientes de OpenVPN y también lo usan herramientas de WireGuard.
Si estás solucionando problemas específicamente de TAP, no “arregles” sin querer el controlador equivocado y luego preguntes por qué no cambió nada.

Los fallos de TAP tienden a agruparse en unos pocos bloques:

Problemas de instalación/firmado del controlador (especialmente tras actualizaciones de Windows o baselines de seguridad endurecidos).
Problemas de estado del adaptador (deshabilitado, oculto, duplicado, estado de registro obsoleto).
Interferencia en el enlace y controladores de filtrado (seguridad endpoint, agentes DLP, “ayudantes” de aceleración de red).
Aplicación incorrecta de enrutamiento/DNS (la VPN se conecta pero el tráfico no va a donde crees).
Problemas de DHCP o asignación IP (se queda en “Asignando IP”, subred equivocada, sin gateway).

El cambio de mentalidad importante: en Windows, los problemas de VPN a menudo no son problemas de OpenVPN. Son problemas de “el stack de red de Windows se encuentra con
un adaptador virtual y con la pegatina de seguridad corporativa”. No los depuras por intuición. Los depuras con comandos y evidencia.

Guía rápida de diagnóstico

Cuando la producción arde—personal remoto no puede conectar, mesa de ayuda desbordada y estás a dos llamadas de que alguien sugiera “simplemente reiniciar el servidor VPN”—necesitas una secuencia de triaje rápida. Aquí está la guía que uso.

Primero: ¿está el adaptador TAP presente y sano?

Revisa el Administrador de dispositivos (o hazlo por PowerShell): ¿está el adaptador TAP allí?
Si está: ¿funciona (sin Code 10/Code 31) y está habilitado?
Si falta: ¿falló la instalación del controlador o está oculto/obsoleto?

Segundo: ¿está OpenVPN ligado realmente al adaptador correcto?

Confirma las líneas del log de OpenVPN sobre apertura del adaptador y asignación de IP.
Verifica que el nombre de la interfaz y el índice en el SO coincidan con lo que OpenVPN espera.
Busca múltiples instancias de TAP y colisiones de nombres.

Tercero: ¿coinciden el enrutamiento/DNS de Windows con la intención de la VPN?

Tras “conectado”, verifica rutas: ruta por defecto, rutas partidas, métricas.
Revisa servidores DNS por interfaz; a Windows le encanta “ayudar” aquí.
Comprueba el perfil de firewall para la interfaz TAP (Public vs Private importa).

Cuarto: identifica al partido que interfiere

¿Seguridad endpoint instalada recientemente? ¿Controladores de filtrado de red? ¿Software de “aceleración VPN”?
¿Actualización reciente de Windows? ¿Cambios en el firmado de controladores? ¿Core Isolation / Memory Integrity activado?
¿Directiva de Grupo aplicando un baseline de endurecimiento de red?

Si sigues ese orden, evitas la trampa clásica: reconfigurar el servidor VPN para “arreglar” un controlador cliente roto.

Datos e historia interesantes que puedes usar

Dato 1: TAP-Windows se basa en el modelo de controlador NDIS. Cada cambio importante de NDIS (NDIS 5 → 6 y sucesivos) ha alterado cómo se comportan los controladores de filtrado.
Dato 2: El concepto original de “TAP” vino de la idea de un network tap: un dispositivo que conectas para observar/insertar tráfico. El TAP virtual hizo ese concepto programable.
Dato 3: La popularidad de OpenVPN en empresas no fue solo por la cripta; fue porque funcionaba sin cambios de kernel en muchos SO—hasta que los baselines de seguridad se endurecieron.
Dato 4: Windows tiene una larga historia de selección automática “útil” de métricas y registro DNS por interfaz. Las VPN son donde esa ayuda se porta mal.
Dato 5: Muchos fallos de clientes VPN tras actualizaciones de Windows no son bugs de OpenVPN; son problemas de enforcement de firmas y compatibilidad que aparecen luego.
Dato 6: El auge de Wintun sucedió en parte porque las interfaces virtuales más simples de capa 3 reducen las rarezas con bridging y controladores de filtrado.
Dato 7: Una sola máquina puede acumular adaptadores de red “fantasma” con el tiempo—dispositivos ocultos de clientes VPN antiguos—que pueden colisionar con métricas de ruta e índices de interfaz.
Dato 8: Las herramientas endpoint corporativas suelen instalar controladores de filtrado NDIS que se sitúan entre la pila de protocolo y los adaptadores. Si no tratan bien a las NIC virtuales, obtienes fallos entretenidos.

Síntomas que suelen indicar problemas con TAP

El controlador TAP no es sutil cuando falla. Solo es inconsistente sobre cómo falla. Síntomas comunes:

“There are no TAP-Windows adapters on this system” en los logs de OpenVPN GUI.
El Administrador de dispositivos muestra el adaptador TAP con Code 10/Code 31 (el dispositivo no puede iniciarse / fallo de carga del controlador).
OpenVPN se conecta pero no hay flujo de tráfico, a menudo porque no se aplicaron rutas o la métrica eligió el camino equivocado.
Se queda en “Assigning IP” o se conecta y desconecta inmediatamente.
El DNS se rompe solo al conectar la VPN (especialmente en configuraciones de túnel dividido donde solo el DNS interno debería ir por la VPN).
Múltiples adaptadores TAP con nombres similares, y OpenVPN elige el equivocado.
La VPN funciona en Wi‑Fi pero no en Ethernet (o viceversa), típicamente por juegos de métricas o diferencias en controladores de filtrado.
La VPN funciona como admin pero no como usuario, comúnmente un problema de servicio/permisos o política alrededor del acceso al controlador.

Broma #1: El adaptador TAP es como el calendario de una sala de reuniones—cuando se rompe, todos culpan a la persona que lo tocó por última vez, no al sistema que realmente falla.

Tareas prácticas: comandos, salidas y decisiones

A continuación hay tareas prácticas que uso al diagnosticar problemas TAP en Windows. Cada una incluye: un comando, qué significa la salida y la decisión a tomar.
Estos ejemplos asumen que ejecutas PowerShell o CMD en Windows. El prompt en bloques está estandarizado; no lo sobre-analices.

Tarea 1: Confirmar procesos y estado del servicio OpenVPN

cr0x@server:~$ powershell -NoProfile -Command "Get-Process openvpn* -ErrorAction SilentlyContinue | Format-Table Name,Id,Path"
Name     Id Path
----     -- ----
openvpn  4216 C:\Program Files\OpenVPN\bin\openvpn.exe

Qué significa: OpenVPN está en ejecución. Si no devuelve nada, no estás depurando TAP; estás depurando el arranque/problema del servicio.

Decisión: Si OpenVPN no está ejecutándose, revisa logs del servicio y la configuración primero. Si está en ejecución, continúa con las comprobaciones del adaptador.

Tarea 2: Listar adaptadores de red y encontrar TAP

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Sort-Object Status,Name | Format-Table -Auto Name,InterfaceDescription,Status,IfIndex,MacAddress"
Name                  InterfaceDescription                         Status   IfIndex MacAddress
----                  --------------------                         ------   ------ ----------
Ethernet              Intel(R) Ethernet Connection                 Up           6   2C-4D-54-11-22-33
Wi-Fi                 Intel(R) Wi-Fi 6 AX200                       Up           9   7A-1B-2C-3D-4E-5F
TAP-Windows Adapter V9 TAP-Windows Adapter V9                      Disabled    22   00-FF-12-34-56-78

Qué significa: El adaptador TAP existe pero está deshabilitado. Eso es un problema del cliente que se puede reparar.

Decisión: Habilítalo (Tarea 3). Si falta por completo, toca reinstalar (Tarea 9/10).

Tarea 3: Habilitar el adaptador TAP

cr0x@server:~$ powershell -NoProfile -Command "Enable-NetAdapter -Name 'TAP-Windows Adapter V9' -Confirm:\$false; Get-NetAdapter -Name 'TAP-Windows Adapter V9' | Format-Table Name,Status"
Name                   Status
----                   ------
TAP-Windows Adapter V9 Up

Qué significa: Windows puede levantar la interfaz. El controlador es al menos capaz de cargarse.

Decisión: Reintenta la conexión VPN. Si sigue fallando, pasa al estado del controlador (Tarea 4) y a la inspección de logs (Tarea 6).

Tarea 4: Revisar códigos de error del Administrador de dispositivos vía PnP

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class Net | Where-Object { \$_.FriendlyName -like '*TAP*' } | Format-Table Status,Class,FriendlyName,InstanceId -Auto"
Status Class FriendlyName               InstanceId
------ ----- ------------               ----------
OK     Net   TAP-Windows Adapter V9     ROOT\NET\0001

Qué significa: El estado es OK. Si ves Error aquí, eso suele correlacionar con Code 10/31 en el Administrador de dispositivos.

Decisión: Si el estado es Error, no pierdas tiempo en rutas/DNS todavía. Primero arregla el controlador (Tarea 9–11).

Tarea 5: Comprobar detalles del controlador instalado

cr0x@server:~$ powershell -NoProfile -Command "Get-WmiObject Win32_PnPSignedDriver | Where-Object { \$_.DeviceName -like '*TAP-Windows*' } | Select-Object DeviceName,DriverVersion,DriverProviderName,InfName | Format-List"
DeviceName         : TAP-Windows Adapter V9
DriverVersion      : 9.24.2.601
DriverProviderName : OpenVPN, Inc
InfName            : oem42.inf

Qué significa: Puedes identificar qué INF respalda el controlador y si es una versión conocida y compatible con tu build de OpenVPN.

Decisión: Si el proveedor no es OpenVPN (o parece una reempaquetación de un tercero), sospecha y planifica una reinstalación limpia.

Tarea 6: Leer los logs de OpenVPN GUI para selección de adaptador y configuración IP

cr0x@server:~$ powershell -NoProfile -Command "Get-Content -Path \"$env:USERPROFILE\OpenVPN\log\client.log\" -Tail 40"
2025-12-27 10:13:11 OpenVPN 2.6.8 x86_64-w64-mingw32
2025-12-27 10:13:12 TAP-Windows Driver Version 9.24
2025-12-27 10:13:12 Opening Windows TAP-Windows adapter 'TAP-Windows Adapter V9'
2025-12-27 10:13:13 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.33.44.12/255.255.255.0 on interface {A1B2C3D4-E5F6-...}
2025-12-27 10:13:20 Initialization Sequence Completed

Qué significa: OpenVPN encontró el adaptador TAP y le pidió aplicar la configuración IP. Si nunca ves “Opening … adapter”, la detección de TAP falló.

Decisión: Si aparece “Initialization Sequence Completed” pero el tráfico está muerto, pasa a las comprobaciones de enrutamiento/DNS (Tarea 7–8, 12–14).

Tarea 7: Inspeccionar la configuración IP de la interfaz TAP

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPConfiguration -InterfaceAlias 'TAP-Windows Adapter V9' | Format-List"
InterfaceAlias       : TAP-Windows Adapter V9
InterfaceIndex       : 22
IPv4Address          : 10.33.44.12
IPv4DefaultGateway   :
DNSServer            : 10.33.44.53, 10.33.44.54

Qué significa: La interfaz obtuvo una IP y servidores DNS. La ausencia de gateway por defecto es normal en configuraciones de túnel dividido.

Decisión: Si no hay IPv4Address, la asignación IP falló—revisa el push de DHCP, el firewall o problemas de controlador. Si la IP está presente, comprueba las rutas.

Tarea 8: Verificar cambios en la tabla de rutas tras la conexión

cr0x@server:~$ powershell -NoProfile -Command "route print | Select-String -Pattern '0.0.0.0|10\.33\.44\.0|VPN|TAP' -Context 0,1"
          0.0.0.0          0.0.0.0      192.168.1.1     192.168.1.10     25
       10.33.44.0    255.255.255.0        On-link       10.33.44.12     1

Qué significa: Tienes una ruta conectada para la subred VPN vía TAP. La ruta por defecto sigue apuntando al gateway local con métrica 25.

Decisión: Si esperas túnel completo y la ruta por defecto no cambia, la configuración del cliente/push está mal. Si esperas túnel dividido pero faltan rutas internas, corrige el push en el servidor.

Tarea 9: Encontrar y eliminar adaptadores TAP “fantasma” (dispositivos ocultos)

cr0x@server:~$ powershell -NoProfile -Command "set devmgr_show_nonpresent_devices=1; start devmgmt.msc"

Qué significa: Esto lanza el Administrador de dispositivos con la posibilidad de mostrar dispositivos no presentes (aún tienes que activar “Mostrar dispositivos ocultos” en la UI).

Decisión: Si ves múltiples TAP antiguos, desinstala los obsoletos. Demasiados adaptadores virtuales causan la rotación de índices y que “OpenVPN elija la NIC equivocada.”

Tarea 10: Enumerar INFs de controladores instalados y localizar paquetes relacionados con TAP

cr0x@server:~$ powershell -NoProfile -Command "pnputil /enum-drivers | findstr /i \"tap openvpn wintun\""
Published Name : oem42.inf
Original Name  : tap0901.inf
Provider Name  : OpenVPN, Inc
Class Name     : Net

Qué significa: Identificaste el paquete de controlador instalado. El “Published Name” es lo que puedes eliminar si quieres una reinstalación limpia.

Decisión: Si sospechas corrupción, versiones desparejadas o una actualización fallida, elimina el paquete viejo (Tarea 11) y reinstala limpio (Tarea 12).

Tarea 11: Eliminar un paquete de controlador TAP específico

cr0x@server:~$ pnputil /delete-driver oem42.inf /uninstall /force
Microsoft PnP Utility

Driver package deleted successfully.

Qué significa: Windows eliminó el paquete del controlador y desinstaló los dispositivos que lo usaban (si fue posible).

Decisión: Reinicia si se te pide. Luego reinstala el paquete correcto de OpenVPN/TAP. Si la eliminación falla por “en uso”, detén los servicios de OpenVPN y vuelve a intentarlo.

Tarea 12: Reinstalar TAP usando el instalador de OpenVPN en modo silencioso

cr0x@server:~$ "C:\Program Files\OpenVPN\bin\tapctl.exe" create --name "TAP-Windows Adapter V9"
Created a TAP device named 'TAP-Windows Adapter V9'

Qué significa: tapctl es la manera práctica de crear un adaptador nuevo si tu build de OpenVPN lo incluye.

Decisión: Si tapctl no está presente, tu empaquetado es distinto—usa el instalador oficial de OpenVPN y selecciona la instalación del controlador TAP. Evita paquetes de controladores aleatorios.

Tarea 13: Comprobar los event logs de Windows por carga de controladores y errores NDIS

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName System -MaxEvents 200 | Where-Object { \$_.Message -match 'TAP|NDIS|Netwtw|driver' } | Select-Object TimeCreated,Id,ProviderName,LevelDisplayName -First 8 | Format-Table -Auto"
TimeCreated           Id ProviderName            LevelDisplayName
-----------           -- ------------            ----------------
12/27/2025 10:10:02 219 Kernel-PnP              Warning
12/27/2025 10:10:03  12 Service Control Manager Error

Qué significa: Buscas evidencias como “driver failed to load”, “blocked due to signature” o fallos de enlace NDIS.

Decisión: Si ves bloqueos por firma, no intentes “arreglar” con hacks de registro. Necesitas un controlador firmado y compatible y posiblemente un cambio en la configuración de seguridad.

Tarea 14: Inspeccionar enlaces de red y controladores de filtrado en la interfaz TAP

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapterBinding -Name 'TAP-Windows Adapter V9' | Where-Object { \$_.Enabled -eq \$true } | Format-Table ComponentID,DisplayName -Auto"
ComponentID DisplayName
----------- -----------
ms_tcpip    Internet Protocol Version 4 (TCP/IPv4)
ms_tcpip6   Internet Protocol Version 6 (TCP/IPv6)
ms_msclient Client for Microsoft Networks
ms_server   File and Printer Sharing for Microsoft Networks

Qué significa: Puedes ver qué está enlazado a la interfaz. Los filtros de terceros suelen aparecer aquí también.

Decisión: Si ves enlaces de filtros de seguridad agresivos y tu organización lo permite, prueba deshabilitar temporalmente el filtro solo en TAP (no globalmente). Si eso lo arregla, ya tienes al culpable.

Tarea 15: Validar comportamiento DNS por interfaz

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress | Sort-Object InterfaceIndex | Format-Table InterfaceAlias,InterfaceIndex,AddressFamily,ServerAddresses -Auto"
InterfaceAlias          InterfaceIndex AddressFamily ServerAddresses
--------------          -------------- ------------- --------------
Ethernet                6              IPv4          {192.168.1.1}
TAP-Windows Adapter V9  22             IPv4          {10.33.44.53, 10.33.44.54}

Qué significa: Los servidores DNS difieren por interfaz. Eso es normal—hasta que la resolución de nombres vaya por la interfaz equivocada primero.

Decisión: Si los dominios internos resuelven por el DNS equivocado, puede que necesites reglas NRPT (en entornos empresariales) o ajustar opciones de OpenVPN (por ejemplo, block-outside-dns donde esté soportado).

Tarea 16: Confirmar el perfil de firewall asignado a la red TAP

cr0x@server:~$ powershell -NoProfile -Command "Get-NetConnectionProfile | Format-Table InterfaceAlias,NetworkCategory,IPv4Connectivity -Auto"
InterfaceAlias          NetworkCategory IPv4Connectivity
--------------          --------------- ---------------
Ethernet                Private         Internet
TAP-Windows Adapter V9  Public          LocalNetwork

Qué significa: TAP se registró como red Pública. Muchas organizaciones restringen mucho el perfil Público, lo que puede romper tráfico VPN o DNS.

Decisión: En entornos gestionados, corrige vía política (preferible). En una máquina independiente, puedes ajustar el perfil, pero hazlo deliberadamente y documenta el cambio.

Tarea 17: Pruebas rápidas de conectividad (ICMP + TCP)

cr0x@server:~$ powershell -NoProfile -Command "ping 10.33.44.1; Test-NetConnection 10.33.44.1 -Port 443"
Pinging 10.33.44.1 with 32 bytes of data:
Reply from 10.33.44.1: bytes=32 time=18ms TTL=63

ComputerName     : 10.33.44.1
RemoteAddress    : 10.33.44.1
RemotePort       : 443
TcpTestSucceeded : True

Qué significa: El túnel y una ruta a un servicio real funcionan. ICMP por sí solo no es victoria; muchas redes bloquean ICMP.

Decisión: Si ping funciona pero TCP no, investiga firewall o enrutamiento para la VLAN de servicio. Si TCP funciona pero DNS no, céntrate en DNS.

Estrategias de reparación que no crean nuevos problemas

“Reparar TAP” puede significar cualquier cosa desde alternar un adaptador hasta arrancar paquetes de controladores y limpiar el registro. El enfoque correcto depende de lo que esté roto.
Aquí está la secuencia que minimiza daños colaterales.

1) Trata el adaptador TAP como una NIC real

Empieza por lo aburrido: ¿está deshabilitado, en mal estado o compite con clones? Si puedes arreglarlo habilitando el adaptador, haz eso y sigue.
Si lo arreglas eliminando dispositivos fantasma, hazlo a continuación. Reinstalar controladores debe ser una medida tardía, no un reflejo.

2) Prefiere la eliminación limpia del paquete de controladores antes que “instalar encima”

Cuando TAP está roto por versiones desajustadas o una actualización a medias, “reinstalar OpenVPN” a veces deja el paquete de controlador dañado en su sitio.
Windows es cortés en ese sentido. Usa pnputil para enumerar y borrar el INF OEM viejo, luego instala desde cero.

3) No luches contra el firmado de controladores con hacks

Si el problema es la enforcement de firmas o un baseline de seguridad endurecido, no juegues al ratón y al gato con modos de test-signing o deshabilitar integrity checks “solo por un minuto.”
Ese minuto se convierte en un año. Usa un controlador que coincida con tu build de Windows y esté debidamente firmado. Si tu organización usa Memory Integrity / HVCI, valida la compatibilidad.

4) Reconoce cuando TAP es la herramienta equivocada

Si no haces bridging a nivel 2 y tu build de OpenVPN soporta Wintun, migrar desde TAP puede reducir la rotura a largo plazo.
No es una postura moral; es operativa. Menos piezas móviles significa menos tickets a las 2 a.m.

5) Sé estricto con el nombrado y la selección de adaptadores

Tener múltiples adaptadores TAP con nombres similares es cómo nace el teatro del “funciona en mi máquina”. Nombra los adaptadores de forma consistente y refiérete a ellos explícitamente cuando sea posible.
Si gestionas clientes centralmente, estandariza el paquete cliente para que el nombre del adaptador y el comportamiento sean consistentes en la flota.

Cita (idea parafraseada), atribuida: Werner Vogels a menudo impulsa la noción de que “todo falla, todo el tiempo”—los sistemas ganan diseñando para la recuperación, no para la perfección.

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

1) “No se encuentran adaptadores TAP”

Síntoma: El log de OpenVPN indica que no hay adaptadores TAP; el Administrador de dispositivos no muestra ninguno.

Causa raíz: Controlador TAP no instalado, o eliminado por herramientas de seguridad, o instalación bloqueada.

Solución: Enumera controladores con pnputil /enum-drivers, reinstala usando un instalador confiable de OpenVPN o tapctl. Revisa el registro del Sistema por bloqueos por firma.

2) El adaptador TAP existe pero “Code 10” / “el dispositivo no puede iniciarse”

Síntoma: Código de error en el Administrador de dispositivos; el adaptador se alterna pero no arranca correctamente.

Causa raíz: Versión de controlador incompatible, enforcement de firmas o conflictos con filtros NDIS.

Solución: Elimina el paquete con pnputil /delete-driver ... /force, reinicia, reinstala un controlador firmado y compatible. Investiga filtros NDIS de terceros.

3) La VPN “se conecta” pero no funcionan recursos internos

Síntoma: “Initialization Sequence Completed,” pero subredes internas inalcanzables.

Causa raíz: Rutas faltantes (servidor no las empuja, o el cliente no las aplica), métrica de interfaz equivocada o problemas de perfil de firewall.

Solución: Revisa route print y métricas. Valida rutas empujadas en el log de OpenVPN. Confirma la categoría de red TAP y reglas de firewall.

4) DNS falla solo cuando la VPN está conectada

Síntoma: El DNS público funcionaba antes de conectar; tras conectar, la resolución de nombres se bloquea o resuelve mal los nombres internos.

Causa raíz: Asignación de servidores DNS y prioridad por interfaz/NRPT, a veces empeorado por clientes DNS “inteligentes”.

Solución: Inspecciona DNS por interfaz con Get-DnsClientServerAddress. Usa enrutamiento DNS por dominio (NRPT en empresa) o ajusta opciones de OpenVPN.

5) Se queda en “Assigning IP”

Síntoma: OpenVPN se conecta y luego queda colgado aplicando IP.

Causa raíz: El controlador TAP no acepta la configuración estilo DHCP, o el firewall/política local bloquea la ruta de configuración.

Solución: Confirma la línea del log sobre el seteo de IP DHCP; verifica si la interfaz muestra una dirección IPv4. Si no, reinstala el controlador y revisa los event logs por fallos a nivel de controlador.

6) Funciona en Wi‑Fi pero no en Ethernet (o al revés)

Síntoma: La VPN está bien en un tipo de enlace, rota en otro.

Causa raíz: Métricas de ruta y preferencia DNS por interfaz; a veces diferentes filtros de seguridad en NICs físicas distintas.

Solución: Inspecciona métricas/rutas tras conectar. Si es necesario, establece métricas explícitas o ajusta configuración de túnel dividido/completo. Compara enlaces y filtros entre adaptadores.

7) Reinstalar OpenVPN no arregló nada

Síntoma: “Reinstalé dos veces.” TAP sigue roto.

Causa raíz: El paquete de controlador viejo permanece en DriverStore; la reinstalación lo reutiliza.

Solución: Elimina con pnputil por nombre publicado, reinicia y luego instala de nuevo. Verifica proveedor/versión después.

Broma #2: Reinstalar OpenVPN sin borrar el paquete de controlador viejo es como poner neumáticos nuevos a un coche con eje torcido—técnicamente hiciste algo, prácticamente sigues vibrando.

Tres micro-historias corporativas desde el terreno

Micro-historia 1: El incidente causado por una suposición incorrecta

Una compañía mediana desplegó un nuevo baseline de endurecimiento de Windows. No era exótico: enforcement más agresivo de controladores, algunas protecciones de kernel,
y un paquete de actualizaciones de seguridad endpoint. El despliegue fue por fases: unidades de negocio primero, luego IT, luego ingeniería.

El día tres, la cola de helpdesk se llenó de “La VPN se conecta pero nada funciona.” La suposición inicial del equipo de red fue clásica: “El concentrador VPN está sobrecargado.”
Escalaron el tier de servidores, ajustaron cifrados e incluso cambiaron keepalive—porque los logs del servidor OpenVPN parecían ocupados y aquello parecía evidencia.

Mientras tanto, los portátiles afectados tenían algo en común: el controlador TAP estaba presente pero fallaba al iniciar. Code 10 en el Administrador de dispositivos. Los logs de OpenVPN en el cliente
mencionaban el adaptador, pero nunca aplicaron con éxito la configuración IP. La suposición equivocada fue tratarlo como un problema del servidor porque “empezó tras cambios.”

La solución real fue del lado cliente: un paquete TAP firmado y compatible más una excepción de política para una clase específica de controlador bajo el nuevo baseline.
Tras eso, las escaladas de servidor se revertieron. No hicieron daño, pero tampoco solucionaron el problema real. Lección de operaciones: no dejes que la coincidencia temporal te obligue a trabajar en la capa equivocada.

Micro-historia 2: La optimización que salió mal

Una organización global quería mejor rendimiento VPN para grandes sincronizaciones de archivos y operaciones internas de Git. Alguien propuso una “optimización simple”:
ajustar métricas de interfaz para que la interfaz VPN siempre gane, incluso para tráfico público. Túnel completo para todos, todo el tiempo.

Funcionó en laboratorio. En producción, creó un apagón en cámara lenta. Los usuarios podían conectar, pero la navegación web se volvió poco fiable,
y las aplicaciones SaaS desconectaban a los usuarios constantemente. La latencia subió porque el tráfico tomaba una desviación innecesaria por un gateway VPN regionalmente lejano.
Peor: la resolución DNS se volvió inconsistente porque Windows seleccionaba servidores DNS basándose en la interfaz VPN dominante aunque no debería.

El controlador TAP fue culpado porque era la parte visible. Gente reinstaló controladores, borró adaptadores y reinició hasta quedarse sin paciencia.
Pero el controlador TAP hacía exactamente lo que se le indicó. La optimización fue el problema: forzó un comportamiento de enrutamiento que no encajaba con el diseño de red.

La solución fue menos emocionante: volver a túnel dividido con rutas explícitas para subredes internas y aplicar enrutamiento DNS por dominio para namespaces internos.
El rendimiento mejoró donde importaba (interno), y el internet público dejó de tomar un tour panorámico. Lección: las métricas de ruta son un arma cargada—no se las des a “ganancias rápidas.”

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

Otra empresa tenía una política: cada paquete cliente VPN estaba fijado a una build de OpenVPN probada y a una versión concreta del controlador TAP.
Sin actualizaciones automáticas, sin “último es mejor” y definitivamente sin mezclar suites empaquetadas por distintos proveedores. Seguridad aprobó porque las actualizaciones eran planificadas y validadas.

Luego una actualización de Windows pasó que endureció compatibilidad de controladores y rompió varios adaptadores VPN de terceros en la industria.
Los equipos que permitían un zoológico de versiones clientes vieron caos inmediato: fallos distintos por modelo de portátil, por privilegio de usuario, por versión de agente de seguridad.

¿Esta organización? Silencio. Un puñado de casos marginales, pero nada parecido a un outage. Su gestión de flota detectó un pequeño aumento en advertencias relacionadas con TAP en event logs,
y como la versión del controlador era consistente, pudieron probar un controlador de reemplazo, validarlo y desplegarlo.

La práctica “aburrida”—fijar versiones y desplegar controladamente—no ganó premios. Mantuvo a miles de usuarios trabajando.
En operaciones, lo aburrido es una característica. La emoción es lo que obtienes cuando tu proceso de cambios es teatro de improvisación.

Listas de verificación / plan paso a paso

Checklist A: Respuesta inicial (15 minutos, una máquina)

Log de OpenVPN: confirma si abre el adaptador TAP y completa la inicialización.
Presencia del adaptador: Get-NetAdapter y busca TAP. Si falta, ve al camino de reinstalación.
Salud del adaptador: Get-PnpDevice -Class Net para estado de TAP y revisa códigos de error en el Administrador de dispositivos.
Config IP: Get-NetIPConfiguration en TAP; confirma IPv4 y DNS esperados.
Rutas: route print; confirma que existen rutas internas esperadas y que las métricas tienen sentido.
Selección DNS: Get-DnsClientServerAddress; verifica que el DNS interno vaya a donde debe.

Checklist B: Reparación limpia del controlador (segura, repetible)

Detén OpenVPN GUI/servicio para que el controlador no esté “en uso”.
Identifica el paquete TAP instalado vía pnputil /enum-drivers.
Elimina el paquete: pnputil /delete-driver oemXX.inf /uninstall /force.
Reinicia (sí, en serio—el estado NDIS es pegajoso).
Instala la build aprobada de OpenVPN que incluya el paquete correcto, o recrea con tapctl.
Verifica proveedor/versión vía WMI y confirma que el adaptador aparece en Get-NetAdapter.
Conecta y vuelve a comprobar IP/rutas/DNS.

Checklist C: Remediación a nivel de flota (no satures tu helpdesk)

Elige una versión cliente conocida y un controlador TAP conocido; prueba en builds representativos de Windows (incluyendo el nivel de parches más reciente).
Escribe un script de detección: TAP presente, versión del controlador, estado PnP y últimas líneas de logs de OpenVPN.
Despliega en anillos: IT primero, luego un piloto de negocio y finalmente despliegue amplio.
Tener una vía de escape: capacidad para revertir paquete de controlador y versión cliente rápidamente.
Mide: advertencias en event log, fallos de conexión, tiempo-para-conectar, fallos de resolución DNS.

Preguntas frecuentes

1) ¿TAP es lo mismo que TUN?

No. TAP es un concepto de adaptador Ethernet virtual (tramas de capa 2). TUN es un concepto de interfaz IP virtual (paquetes de capa 3).
Las configuraciones de OpenVPN pueden usar dev tun mientras que el empaquetado en Windows todavía involucra componentes TAP en setups antiguos—no asumas que el nombre coincide con la intención de la configuración.

2) ¿Por qué Windows sigue creando múltiples adaptadores TAP?

Instalaciones/actualizaciones fallidas y paquetes clientes diferentes pueden crear adaptadores virtuales adicionales. Dispositivos “no presentes” permanecen ocultos en el sistema.
Por eso la limpieza de adaptadores fantasma importa, especialmente en portátiles de larga vida.

3) ¿Qué suele significar “Code 10” en el adaptador TAP?

Usualmente significa que el controlador no pudo arrancar—comúnmente por problemas de compatibilidad, enforcement de firma o conflictos con controladores de filtrado.
Trátalo como un problema de salud del controlador, no de enrutamiento.

4) ¿Por qué la VPN se conecta pero no alcanzo recursos internos?

Porque “conectado” significa que TLS y el establecimiento del túnel funcionaron. No garantiza que rutas, DNS o políticas de firewall estén correctas.
Revisa route print, métricas de interfaz y servidores DNS por interfaz.

5) ¿Debería deshabilitar IPv6 en el adaptador TAP?

Solo si tienes un modo de fallo específico en IPv6 y entiendes las consecuencias. Deshabilitar IPv6 por defecto es una superstición popular.
Diagnostica primero: ¿estás filtrando DNS sobre IPv6, o tu DNS interno es inalcanzable vía v6? Arregla la causa raíz en vez de amputar protocolos.

6) Reinstalé OpenVPN y el controlador TAP sigue roto. ¿Por qué?

Porque Windows puede reutilizar el paquete del controlador existente desde DriverStore. Usa pnputil para eliminar el INF OEM publicado, reinicia y luego instala desde cero.

7) ¿Cuál es la forma más rápida de saber si es TAP o enrutamiento?

Si OpenVPN no puede abrir el adaptador o el adaptador muestra errores PnP, es TAP/controlador. Si OpenVPN completa la inicialización y la interfaz tiene IP, probablemente sea enrutamiento/DNS/firewall.
La sección “Guía rápida de diagnóstico” está diseñada alrededor de esa división.

8) ¿El software de seguridad endpoint puede romper TAP?

Sí. Muchos productos endpoint añaden controladores de filtrado NDIS. Algunos manejan mal las NIC virtuales, otros bloquean la instalación de controladores y otros cambian políticas de firewall.
No adivines—revisa enlaces y event logs y ejecuta una prueba controlada.

9) ¿Cambiar a Wintun es una “solución” válida para problemas de TAP?

A veces. Si tu entorno no requiere bridging a nivel 2, migrar a Wintun puede reducir la rareza de controladores y controladores de filtrado.
No es mágico; son menos características y menos formas de fallar.

Conclusión: siguientes pasos para mantener la cabeza fría

Si tomas una lección operativa de las fallas de TAP, que sea esta: separa la salud del adaptador de la intención de enrutamiento/DNS.
No “arregles” rutas cuando el controlador no puede arrancar. No reinstales controladores cuando la tabla de rutas está mal. Diagnostica, y luego actúa.

Pasos prácticos siguientes:

Ejecuta la guía rápida en una máquina afectada y anota en qué capa falla: controlador, estado del adaptador, enrutamiento, DNS o perfil de firewall.
Estandariza en una build de OpenVPN conocida y en una versión de controlador TAP (o Wintun) probada; fíjala y despliega por anillos.
Construye un pequeño script de auditoría: adaptador presente, estado PnP, versión del controlador y comprobaciones de ruta/DNS—para que el próximo incidente sea medido, no discutido.
Cuando debas reparar: elimina limpiamente el paquete de controlador viejo, reinicia, reinstala y verifica. Reproducible vence a ingenioso.