OpenVPN “route addition failed” en Windows: soluciones de enrutamiento que realmente funcionan

Guía de diagnóstico rápido

Si estás en una llamada de soporte y alguien dice “el VPN está arriba pero nada funciona”, no te disperses. Haz esto en orden. El objetivo es encontrar el cuello de botella rápido: privilegios, conflictos de rutas, selección de adaptador o controles de política.

1) Identifica la ruta que falla exactamente (no adivines)

• OpenVPN GUI: abre el log y busca route addition failed.
• Anota la red de destino y la máscara (o CIDR), y la puerta de enlace/interfaz que intentó usar.
• Si el log no muestra los detalles de la ruta, aumenta la verbosidad (verb 4 o verb 5) y vuelve a conectar.

2) Comprueba si Windows rechazó el cambio por privilegios

• Si ves “Access is denied” o el código de error 5, no estás elevado o el servicio no se está ejecutando con los derechos necesarios.
• Si ves “The object already exists” o error 183, ya tienes una ruta en conflicto en la tabla.

3) Vuelca la tabla de enrutamiento y busca conflictos y métricas

• Busca una ruta existente al mismo destino, especialmente con una métrica menor.
• Busca múltiples rutas por defecto (0.0.0.0/0) creadas por Wi‑Fi, Ethernet, Hyper‑V, WSL u otro VPN.

4) Valida el estado del adaptador VPN y el índice de interfaz

• Si TAP/Wintun está desconectado, no tiene IP o tiene una métrica rota, los “route add” pueden fallar o ser ignorados.
• Si el servidor empuja rutas para subredes que ya tienes localmente, Windows te “ayudará” llevándote a un agujero negro.

5) Si todo parece normal, sospecha controles de seguridad

• Reglas de Windows Defender Firewall, callouts de WFP desde seguridad endpoint y baselines de “hardening” pueden bloquear cambios de ruta.
• Las herramientas corporativas de “postura VPN” a veces compiten con OpenVPN y reescriben rutas un segundo después.

Esa es la triaje. Ahora lo haremos preciso y repetible.

Qué significa realmente “route addition failed” en Windows

OpenVPN no “encaminar paquetes”. Pide al SO que instale rutas. En Windows, eso significa llamar a la IP Helper API (y amigas), que luego actualiza la tabla de rutas. Si Windows se niega a aceptar la ruta, OpenVPN registra el fallo y sigue adelante —a veces con conectividad parcial que te hace perder horas.

Una adición de ruta puede fallar por unas cuantas razones poco glamurosas:

• Privilegio: añadir rutas requiere privilegios administrativos. El OpenVPN GUI puede estar ejecutándose como usuario normal. El servicio de OpenVPN puede no estar configurado correctamente. O UAC está haciendo lo que hace.
• Conflicto: la ruta exacta (destino + máscara + gateway/interfaz) ya existe, o existe una ruta más específica que hace que la nueva sea inútil.
• Gateway/interfaz inválidos: OpenVPN intenta añadir la ruta por una interfaz que aún no está arriba (temporalidad), no tiene IP o no es la interfaz que Windows cree que es.
• Política y filtrado: los drivers de seguridad endpoint pueden bloquear la modificación de rutas o resetearlas inmediatamente después. Esto es “divertido” porque OpenVPN puede registrar éxito mientras las rutas desaparecen luego.
• Caos de métricas: Windows elige la “mejor” ruta usando primero la longitud del prefijo y luego la métrica. Si las métricas se gestionan mal o son “optimizadas” por humanos, obtienes fallos en split tunnel y tráfico en bucle.

Un modelo mental importante: OpenVPN es solo un instalador de rutas más un túnel. Si Windows no acepta la ruta, el túnel es irrelevante. Tus paquetes seguirán tomando el camino antiguo como si nada hubiera pasado.

Broma #1: El enrutamiento de Windows es como la asignación de asientos en una oficina: todos tienen un plan hasta que el becario trae un nuevo cliente VPN y ocupa la única silla etiquetada “default gateway”.

Hechos e historia que explican el dolor actual

Un poco de contexto ayuda porque la rareza que ves no es aleatoria; es historia en capas.

1. Windows ha preferido durante mucho tiempo las “métricas automáticas” para escoger la “mejor” interfaz, y a menudo las cambia tras eventos de enlace. Bien para consumidores, confuso para split tunneling.
2. La integración original de OpenVPN en Windows dependía mucho de TAP (virtual Ethernet tipo capa‑2). Más tarde, Wintun mejoró rendimiento y redujo dramas de drivers, pero la lógica de rutas sigue siendo controlada por el SO.
3. Las configuraciones antiguas de OpenVPN usaban route-method exe y literalmente llamaban a route.exe. Las builds modernas suelen usar las IP Helper APIs, pero los logs y los modos de fallo aún hacen referencia a la semántica de “route add”.
4. Las decisiones de enrutamiento de Windows son “coincidencia por prefijo más largo” primero. Las métricas son secundarias. Por eso una ruta /24 obsoleta puede anular una nueva ruta por defecto, y jurarás que el VPN “ignora” las configuraciones.
5. El split tunneling se volvió común con SaaS. Cuando las empresas dejaron de forzar todo el tráfico por HQ, las tablas de rutas se complicaron rápido, especialmente en portátiles con múltiples adaptadores virtuales.
6. Los productos de seguridad endpoint suelen enganchar Windows Filtering Platform (WFP). Pueden permitir el túnel VPN pero bloquear cambios de ruta o subredes específicas —así que el túnel está arriba, pero tus CIDR internos están muertos.
7. Las rutas empujadas por OpenVPN son “consultivas”: el servidor empuja, el cliente lo intenta. El SO arbitra. Por eso dos clientes con el mismo perfil pueden comportarse distinto si sus rutas locales difieren.
8. Las imágenes corporativas frecuentemente incluyen Hyper‑V, WSL, Docker o switches virtuales. Cada uno añade rutas y puede robar métricas o añadir rangos RFC1918 solapados.

Una cita para pegar en un post‑it, porque aplica perfectamente al enrutamiento: “Hope is not a strategy.” — General Gordon R. Sullivan.

Modos de fallo comunes: access denied, file exists, not found

“ROUTE: route addition failed” + “Access is denied”

Este es el clásico. No tienes privilegios elevados, o OpenVPN no se está ejecutando en un contexto que pueda modificar la tabla de rutas. A veces es intermitente porque el primer intento falla, pero los siguientes tienen éxito cuando el adaptador sube y desencadena otros caminos de código. No aceptes lo intermitente. Arregla el modelo de privilegios.

“ROUTE: route addition failed” + “The object already exists”

Windows ya tiene una ruta para ese destino. Quizá de otro VPN, quizá de una sesión OpenVPN anterior con rutas persistentes, quizá de una red de adaptador virtual (Hyper‑V/WSL/Docker) usando rangos solapados. OpenVPN intenta añadirla, Windows dice “ya existe”, y OpenVPN lo registra como fallo aunque la ruta existente pueda ser correcta —o desastrosamente incorrecta.

“ROUTE: route addition failed” + “The network path was not found” / gateway incorrecto

Esto suele ser un problema de selección de interfaz: OpenVPN intenta añadir una ruta vía una puerta de enlace que aún no existe, o a través del índice de interfaz equivocado. La sincronización importa en Windows. El adaptador puede estar “conectado” pero no completamente inicializado con IP, DNS y parámetros de enrutamiento.

“Route added successfully” pero el tráfico sigue mal

Esto es comportamiento de métricas o prefijos, no un fallo de añadir ruta. Una ruta más específica (o una métrica menor) gana y envía el tráfico a otro lado. O tu tráfico entra al VPN, pero la ruta de retorno o las reglas de firewall lo bloquean. Tu “arreglo” es dejar de mirar el log de OpenVPN y empezar a interrogar la selección de rutas del SO.

Tareas prácticas: comandos, salidas y decisiones

Quieres tareas que puedas ejecutar, salidas que puedas interpretar y decisiones que puedas tomar sin convertirte en arqueólogo de redes a tiempo parcial. Aquí las tienes. Ejecútalas en el cliente Windows. Usa PowerShell o CMD elevados cuando haga falta.

Task 1: Confirmar que realmente estás elevado (sí, en serio)

cr0x@server:~$ whoami /groups | findstr /i "S-1-5-32-544"
BUILTIN\Administrators Alias S-1-5-32-544 Enabled group, Enabled by default, Group owner

Qué significa: Si no ves el grupo Administrators habilitado, no estás elevado. Abrir OpenVPN GUI normalmente suele ejecutarse sin elevación, incluso si tu usuario es “admin”.

Decisión: Relanza OpenVPN GUI con “Ejecutar como administrador” o usa el servicio de OpenVPN con los privilegios adecuados.

Task 2: Captura la ruta que falla desde el log de OpenVPN

cr0x@server:~$ type "C:\Program Files\OpenVPN\log\client.log" | findstr /i "route addition failed"
2025-12-27 09:11:54 ROUTE: route addition failed using CreateIpForwardEntry: Access is denied.   [status=5 if_index=23]

Qué significa: El status 5 es privilegio. El if_index es la interfaz que Windows intentó usar.

Decisión: Arregla privilegios primero. Si ya estás elevado, sospecha controles endpoint que bloquean modificaciones de rutas.

Task 3: Volcar la tabla de enrutamiento y buscar la subred objetivo

cr0x@server:~$ route print
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.1.1    192.168.1.50     35
        10.20.0.0    255.255.0.0         On-link       10.8.0.2      5
        10.20.0.0    255.255.0.0      192.168.1.1    192.168.1.50     25
===========================================================================

Qué significa: Dos rutas a 10.20.0.0/16. La ruta “On-link” del VPN tiene mejor métrica (5), así que debería ganar. Si la peor gana, probablemente haya un prefijo más específico en otra parte o rutas basadas en políticas.

Decisión: Si la ruta “equivocada” tiene mejor métrica, elimínala o ajusta métricas. Si ambas existen, decide qué interfaz debe poseer esa subred y aplícalo.

Task 4: Confirma que índices y nombres de interfaz coinciden con el log de OpenVPN

cr0x@server:~$ netsh interface ipv4 show interfaces
Idx     Met         MTU          State                Name
---  ----------  ----------  ------------  ---------------------------
  1          75  4294967295  connected     Loopback Pseudo-Interface 1
 11          25        1500  connected     Wi-Fi
 23           5        1500  connected     OpenVPN Wintun

Qué significa: Idx 23 coincide con el log. Bien. Si el log referencia un índice que ya no existe, tienes un adaptador obsoleto o churn de drivers.

Decisión: Si hay discrepancia de índice: elimina adaptadores TAP/Wintun obsoletos y reinstala limpiamente, o actualiza el perfil de OpenVPN para usar el tipo de dispositivo correcto.

Task 5: Verifica que el adaptador VPN tenga IP y el comportamiento esperado de puerta de enlace

cr0x@server:~$ ipconfig /all
Ethernet adapter OpenVPN Wintun:
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : OpenVPN Wintun
   Physical Address. . . . . . . . . : 00-FF-12-34-56-78
   DHCP Enabled. . . . . . . . . . . : No
   IPv4 Address. . . . . . . . . . . : 10.8.0.2(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.255
   Default Gateway . . . . . . . . . : 

Qué significa: Muchas configuraciones de OpenVPN usan un /32 en la interfaz del túnel y no establecen puerta de enlace por defecto allí. Eso es normal. El enrutamiento debería seguir funcionando vía rutas on‑link.

Decisión: Si no hay IP en absoluto, tu túnel no está realmente configurado; arregla eso antes de perseguir rutas.

Task 6: Comprueba rutas RFC1918 solapadas desde redes locales

cr0x@server:~$ route print | findstr /r "10\. 172\.16\. 192\.168\."
        10.0.0.0        255.0.0.0      192.168.1.1    192.168.1.50     25
      192.168.0.0    255.255.0.0         On-link     192.168.1.50    281

Qué significa: Si tu red local ya enruta 10.0.0.0/8 vía tu gateway de casa/oficina, y el VPN también quiere partes de 10/8, estás en “país de solapamiento”. Windows usará el prefijo más específico, pero la ruta local amplia puede romper rutas VPN menos específicas.

Decisión: Prefiere direccionamiento interno no solapado si lo controlas. Si no, empuja rutas más específicas desde OpenVPN (p. ej., /16 o /24 en lugar de /8) y elimina rutas locales amplias cuando sea posible.

Task 7: Eliminar una ruta en conflicto (quirúrgico, no arrasador)

cr0x@server:~$ route delete 10.20.0.0 mask 255.255.0.0 192.168.1.1
 OK!

Qué significa: Eliminaste la ruta que estaba robando tráfico al VPN.

Decisión: Reconecta el VPN y verifica que OpenVPN pueda añadir la ruta prevista. Si la ruta en conflicto reaparece, algo (un servicio, otro VPN, un script, una GPO) la está reinstalando —persigue a ese actor, no el síntoma.

Task 8: Añadir una ruta manualmente para demostrar que el SO la acepta

cr0x@server:~$ route add 10.20.0.0 mask 255.255.0.0 10.8.0.1 metric 5
 OK!

Qué significa: Windows aceptó la ruta. Si OpenVPN aún no puede añadirla, probablemente tengas un problema de privilegios/contexto (GUI vs servicio) o de sincronización.

Decisión: Si el add manual funciona solo en shells elevados, OpenVPN debe ejecutarse elevado o como servicio. Si el add manual falla incluso elevado, sospecha WFP/política de seguridad o un gateway inválido.

Task 9: Confirma la selección real de ruta para una IP objetivo

cr0x@server:~$ powershell -Command "Get-NetRoute -DestinationPrefix 10.20.5.10/32 | Sort-Object -Property RouteMetric | Format-Table -AutoSize"
DestinationPrefix NextHop     InterfaceAlias  RouteMetric PolicyStore
----------------- -------     --------------  ----------- -----------
10.20.5.10/32     10.8.0.1    OpenVPN Wintun  5           ActiveStore

Qué significa: Esto muestra qué ruta usará Windows para ese destino específico (o al menos los candidatos). Una ruta host /32 es decisiva.

Decisión: Si la ruta apunta a Wi‑Fi/Ethernet en lugar del VPN, tienes un conflicto de prefijo/métrica. Arregla la ruta en conflicto o añade una ruta más específica vía VPN.

Task 10: Comprueba si Windows gestiona mal las métricas automáticamente

cr0x@server:~$ powershell -Command "Get-NetIPInterface -AddressFamily IPv4 | Sort-Object -Property InterfaceMetric | Format-Table -AutoSize"
ifIndex InterfaceAlias        NlMtu(Bytes) InterfaceMetric Dhcp     ConnectionState
------- --------------        ------------ --------------- ----     ---------------
23      OpenVPN Wintun        1500         5               Disabled Connected
11      Wi-Fi                 1500         25              Enabled  Connected

Qué significa: Métrica menor gana cuando las longitudes de prefijo empatan. Métrica del VPN menor que la de Wi‑Fi suele ser lo que quieres para full‑tunnel, y a menudo también para split‑tunnel si confías en métricas para defaults.

Decisión: Si la métrica del VPN es mayor que la del Wi‑Fi y esperas que el tráfico por defecto vaya por el VPN, fija una métrica menor en la interfaz VPN o empuja una ruta por defecto explícita vía VPN.

Task 11: Deshabilitar métricas automáticas en una interfaz específica (cambio controlado)

cr0x@server:~$ powershell -Command "Set-NetIPInterface -InterfaceAlias 'OpenVPN Wintun' -AutomaticMetric Disabled -InterfaceMetric 5"

Qué significa: Fijaste la métrica. Esto elimina una fuente de aleatoriedad “funcionó ayer”.

Decisión: Haz esto solo si controlas la base del portátil o estás escribiendo un playbook de soporte. Las métricas como ajuste por usuario son frágiles; derivarán con renombrados de adaptadores y reconstrucciones.

Task 12: Confirma el contexto del proceso OpenVPN (GUI vs servicio)

cr0x@server:~$ sc query OpenVPNService
SERVICE_NAME: OpenVPNService
        TYPE               : 10  WIN32_OWN_PROCESS
        STATE              : 4  RUNNING

Qué significa: Si el servicio se está ejecutando, las rutas pueden ser instaladas por el servicio incluso si la GUI no está elevada (depende de tu build/config). Si está detenido, la GUI debe estar elevada para añadir rutas.

Decisión: Estandariza: ejecuta como servicio para consistencia, o exige “Ejecutar como administrador” para la GUI. Mezclarlos es donde nacen los tickets.

Task 13: Verifica el comportamiento DNS cuando las rutas están bien pero las apps fallan

cr0x@server:~$ nslookup internal-app.corp
Server:  UnKnown
Address:  192.168.1.1

*** internal-app.corp can't find internal-app.corp: Non-existent domain

Qué significa: Estás consultando tu DNS local (router doméstico) en lugar del DNS corporativo. El enrutamiento puede estar perfecto; la resolución de nombres te sabotea.

Decisión: Corrige las opciones DNS empujadas, usa block-outside-dns donde corresponda, o establece DNS de interfaz para el adaptador VPN vía política.

Task 14: Detecta si otro cliente VPN está instalado e interfiriendo

cr0x@server:~$ powershell -Command "Get-NetAdapter | Select-Object Name,InterfaceDescription,Status | Format-Table -AutoSize"
Name             InterfaceDescription                      Status
----             --------------------                      ------
Wi-Fi            Intel(R) Wi-Fi 6 AX200 160MHz             Up
OpenVPN Wintun   OpenVPN Wintun                            Up
CorpVPN          Acme SecureConnect Virtual Adapter        Up

Qué significa: Dos adaptadores VPN arriba al mismo tiempo no son “más seguro”. Es ruleta de rutas.

Decisión: Elige un VPN. Deshabilita o desconecta el otro antes de conectar OpenVPN, a menos que soportes explícitamente túneles encadenados (la mayoría de organizaciones no lo hacen, y Windows realmente no).

Task 15: Prueba la ruta de paquetes con traceroute (cuando el enrutamiento te engaña)

cr0x@server:~$ tracert -d 10.20.5.10

Tracing route to 10.20.5.10 over a maximum of 30 hops

  1     2 ms     1 ms     2 ms  10.8.0.1
  2    15 ms    14 ms    15 ms  10.20.0.1
  3    18 ms    17 ms    18 ms  10.20.5.10

Trace complete.

Qué significa: Si el salto 1 es tu router doméstico (192.168.1.1) en vez de la gateway del VPN (a menudo 10.8.0.1 o similar), tu tráfico no está entrando en el túnel.

Decisión: Arregla la selección de rutas. Si el traceroute entra al VPN pero muere después, el problema está en el servidor (enrutamiento/firewall), no en el añadido de rutas en Windows.

Task 16: Revisa los eventos de Windows para drivers o filtros (cambios de ruta bloqueados)

cr0x@server:~$ powershell -Command "Get-WinEvent -LogName System -MaxEvents 30 | Where-Object {$_.Message -match 'Wintun|TAP|filter|WFP'} | Select-Object TimeCreated,Id,ProviderName,Message | Format-List"
TimeCreated : 12/27/2025 9:12:10 AM
Id          : 5007
ProviderName: Microsoft-Windows-Windows Firewall With Advanced Security
Message     : Windows Firewall settings were changed.

Qué significa: No es una prueba concluyente por sí sola, pero los cambios en el momento de la conexión pueden correlacionarse con fallos de ruta o caídas de tráfico. Los agentes de seguridad suelen alternar perfiles de firewall cuando sube un VPN.

Decisión: Si ves eventos consistentes al conectar, coordina con los propietarios de las herramientas de seguridad. Tu “problema de red” puede ser un motor de políticas haciendo su trabajo mal.

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

Síntoma: “route addition failed: Access is denied”

Causa raíz: OpenVPN GUI no está elevado; el servicio no corre; tokens UAC; o seguridad endpoint bloqueando escrituras de rutas.

Solución: Ejecuta OpenVPN GUI como administrador o ejecuta OpenVPN como servicio de Windows con permisos adecuados. Si ya está elevado, prueba un route add manual; si eso también falla, escala a seguridad endpoint/WFP.

Síntoma: “route addition failed: The object already exists”

Causa raíz: Ruta existente al mismo prefijo desde otro VPN, ruta persistente, o una red de adaptador virtual (Hyper‑V/WSL/Docker) usando rangos solapados.

Solución: Elimina la ruta en conflicto; detén al actor que la vuelve a añadir; evita subredes internas solapadas; empuja rutas más específicas; deshabilita el segundo adaptador VPN.

Síntoma: VPN conecta, pero solo algunas subredes internas funcionan

Causa raíz: Conflictos de split tunneling. Un subconjunto de rutas falló al instalarse, a menudo aquellas que se solapan con redes locales o las que se empujaron antes de que el adaptador se estabilizara.

Solución: Aumenta la verbosidad del log para ver qué prefijos específicos fallaron. Añade un route-delay o asegúrate de que el adaptador esté listo. Elimina rutas locales solapadas o cambia los prefijos empujados.

Síntoma: La ruta está presente, pero el tráfico todavía sale por Wi‑Fi

Causa raíz: Reglas de métrica y prefijo: existe una ruta más específica en otra parte, o el enrutamiento basado en políticas de otro software gana.

Solución: Usa Get-NetRoute para la IP destino exacta, no solo para la subred. Elimina la ruta más específica en conflicto, o añade una ruta /32 explícita vía VPN para endpoints críticos.

Síntoma: Los nombres internos no resuelven, pero ping por IP funciona

Causa raíz: DNS no empujado o no aplicado. Windows sigue usando servidores DNS locales; faltan políticas de split‑DNS.

Solución: Empuja servidor DNS y opciones de dominio desde el VPN; aplica block-outside-dns donde esté soportado; valida la selección de DNS con nslookup.

Síntoma: Todo funciona 30–90 segundos, luego falla

Causa raíz: Otro agente reescribe rutas después de que el VPN conecta: “optimización de red”, chequeo de postura, software de roaming Wi‑Fi u otro cliente VPN reparando sus rutas.

Solución: Observa la tabla de rutas con el tiempo; identifica el proceso/servicio; deshabilita el agente en competencia o establece una política de rutas determinista (rutas propiedad del servicio, métricas fijadas).

Síntoma: “Cannot find device” / errores de índice de interfaz en el log

Causa raíz: Adaptadores TAP/Wintun obsoletos, reinstalación de drivers, actualización de Windows que reordena índices de interfaz.

Solución: Elimina adaptadores no usados, reinstala el driver correcto y estandariza en Wintun cuando sea posible para reducir la deriva de TAP legado.

Broma #2: Si “arreglaste” el enrutamiento deshabilitando todos los adaptadores hasta que funcionara, felicidades: reinventaste la gestión de cambios, pero con más pánico.

Tres microhistorias corporativas de la vida en producción

Microhistoria 1: El incidente causado por una suposición errónea

La compañía tenía una historia cómoda: “OpenVPN empuja rutas; los clientes obedecen; listo.” Esa suposición funcionaba en portátiles de desarrolladores y falló en los de ejecutivos —los que tenían un agente de seguridad con hooks en kernel y amor por “defaults protectores”.

El síntoma era clásico: VPN conectado, algunas apps internas funcionaban, cualquier cosa en una subred particular hacía timeout. El ingeniero on‑call (que ya había visto suficientes tickets de VPN como para envejecer una década) fue directo a la tabla de rutas y encontró que la ruta /16 empujada faltaba. OpenVPN registró route addition failed con status 5 en esas máquinas.

La suposición equivocada: “Status 5 significa que el usuario no ejecutó como admin.” Eran administradores. Estaban elevados. El route add manual también falló. Ahí el equipo dejó de culpar a los humanos y empezó a culpar a la plataforma.

Correlacionaron fallos de rutas en tiempo de conexión con actualizaciones de políticas del agente de seguridad y encontraron una regla que impedía modificar rutas hacia “rangos privados no explícitamente aprobados”. La política buscaba evitar que malware reruteara tráfico local. También impedía que los clientes VPN hicieran su trabajo a menos que registraran sus rutas en una allowlist específica del proveedor.

La resolución fue aburrida: coordinar con seguridad, añadir las subredes VPN a la allowlist y documentar que OpenVPN necesita capacidad de escritura de rutas. La lección no fue “la seguridad es mala”. Fue que el enrutamiento de Windows no es un patio privado: hay otros inquilinos ahí.

Microhistoria 2: La “optimización” que salió mal

Un equipo de red quería Internet más rápido sobre el VPN. Pasaron de full‑tunnel a split‑tunnel y empujaron solo unas pocas rutas internas. Luego se ambicionaron y “limpiaron” empujando una ruta amplia: 10.0.0.0/8. “Una ruta es más fácil que veinte”, dijeron. No estaban equivocados. Tampoco estaban en lo correcto.

Los usuarios empezaron a quejarse de que, en ciertos hoteles, nada interno funcionaba. En casa iba bien. En la oficina iba bien. En el hotel: muerte. Los logs de VPN mostraban fallos al añadir 10/8. Windows decía que la ruta ya existía.

El detalle faltante: esas redes de hotel también usaban 10/8 internamente. El gateway Wi‑Fi local instaló una ruta 10/8 y Windows la trató como cualquiera. La 10/8 empujada por OpenVPN colisionó. A veces Windows mantenía la local. A veces aceptaba la del VPN pero las métricas favorecían el camino equivocado. De cualquier forma, el split tunneling se volvió una moneda al aire.

La solución fue revertir la “optimización”: dejar de empujar 10/8. Empujar solo los prefijos corporativos reales (más específicos /16 y /24). Sí, son más rutas. También es lo que querías desde el principio. Añadieron además una comprobación en la documentación de incorporación: si tu red local se solapa, espera problemas —y no culpes al usuario.

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

Otra organización tenía una política monótona: todos los clientes VPN en Windows se ejecutan como servicios, no como procesos GUI en espacio de usuario. Todos se quejaban porque sonaba “enterprise”. Luego llegó una actualización de Windows y cambió cómo se comportaban los tokens UAC en un subconjunto de dispositivos con ciertos baselines de hardening.

Los equipos que dependían de “Ejecutar como administrador” empezaron a ver fallos al añadir rutas. Sus SOPs quedaron obsoletos. La gente hizo la danza habitual: reinstalar OpenVPN, reiniciar la pila de red, reboot, maldecir el portátil, repetir.

La org con VPN basado en servicio apenas lo notó. El servicio de OpenVPN corrió con privilegios consistentes e instaló rutas de forma determinista. Su incidente fue una no‑incidencia: un puñado de usuarios tuvo problemas de drivers, pero no hubo fallos de route add.

La práctica salvadora no era glamorosa. Era estandarización: un método de instalación, un contexto de ejecución, logs consistentes y privilegios previsibles. Cuando Windows cambia bajo tus pies —y lo hará— quieres menos piezas móviles, no más folklore.

Listas de verificación / plan paso a paso

Paso a paso: Arreglar fallos de adición de rutas en una sola máquina Windows

1. Obtén la ruta que falla con exactitud desde el log de OpenVPN (destino, máscara, gateway, índice de interfaz y código de estado).
2. Confirma elevación (whoami /groups). Si no estás elevado, detente y arregla el contexto de ejecución.
3. Confirma índice/nombre del adaptador con netsh interface ipv4 show interfaces. Si el log referencia un índice muerto, limpia adaptadores obsoletos.
4. Vuelca rutas (route print) y encuentra conflictos para ese prefijo. Decide qué ruta debe poseerlo.
5. Elimina rutas en conflicto de forma quirúrgica. Reconecta el VPN. Verifica que la ruta aparezca y se mantenga.
6. Verifica la selección real de ruta para una IP interna específica usando Get-NetRoute o tracert.
7. Valida DNS con nslookup para asegurarte de que usas el resolvedor previsto.
8. Observa el churn de rutas (cambios en la tabla de rutas después de conectar). Si las rutas revierten, identifica el servicio/software en competencia.

Checklist: Qué estandarizar en la flota (para que esto deje de repetirse)

• Modelo de ejecución: elegir OpenVPN basado en servicio o GUI elevada; no mezclar a la ligera.
• Estrategia de adaptadores: estandarizar en Wintun donde sea soportado; eliminar el desorden TAP legado.
• Plan de direcciones: evitar empujar rangos privados amplios que colisionen con redes domésticas/hoteles.
• Política de rutas: empujar rutas explícitas y específicas; evitar “una gran ruta” a menos que controles el entorno cliente estrictamente.
• Métricas: definir qué gana (VPN vs LAN) y reforzar métricas cuando sea necesario; documentar el porqué.
• Coordinación de seguridad: asegurar que los controles endpoint permiten la instalación de rutas para tus subredes VPN.
• Logging: almacenar logs cliente en una ubicación conocida; configurar verbosidad suficiente para troubleshooting sin convertir logs en novelas.

Paso a paso: Cuando el problema está realmente en el servidor

1. Si traceroute muestra que el salto 1 es la gateway del VPN pero el tráfico muere después, deja de cambiar rutas en Windows.
2. Confirma que el servidor empuja las rutas correctas y que los routers internos enrutan de vuelta al túnel.
3. Revisa reglas de firewall en el concentrador VPN y en routers internos para el pool de clientes VPN.
4. Valida que las redes internas sepan cómo alcanzar la subred de clientes VPN (o que el NAT esté configurado intencionadamente).

Preguntas frecuentes

1) ¿Por qué OpenVPN dice “route addition failed” pero el VPN aún se conecta?

Porque el establecimiento del túnel y la instalación de rutas son pasos separados. TLS puede tener éxito, el adaptador puede subir, y aun así fallar los añadidos de ruta. La interfaz muestra “conectado”, tus paquetes no están de acuerdo.

2) ¿Es “The object already exists” realmente un problema?

A veces sí, a veces no. Si la ruta existente apunta a la interfaz/puerta de enlace correcta, podrías estar bien. Si apunta a Wi‑Fi u otro VPN, obtendrás fallo parcial o total. Siempre verifica la interfaz y la métrica de la ruta existente.

3) ¿Necesito TAP o Wintun?

La mayoría de despliegues modernos en Windows deberían preferir Wintun salvo que haya un requisito legado específico. TAP arrastra más bagaje histórico. Pero cambiar el driver no arreglará mágicamente conflictos de rutas o problemas de privilegios; solo reduce la inestabilidad relacionada con drivers.

4) ¿Por qué las rutas fallan solo en algunas redes Wi‑Fi?

Espacio IP privado solapado y rutas locales “útiles”. Hoteles, cafés y algunas redes guest empresariales usan ampliamente 10/8. Si tu VPN empuja rangos amplios, colisionas y Windows elige un ganador que no votaste.

5) ¿Cómo sé qué interfaz usará Windows para una IP interna?

No mires la tabla de rutas y adivines. Consulta el destino específico con Get-NetRoute para esa IP (o usa tracert y mira el salto 1). Eso te dirá la selección real del camino.

6) ¿La seguridad endpoint puede bloquear realmente la adición de rutas?

Sí. Callouts de WFP y políticas de hardening pueden denegar o revertir cambios de ruta. El síntoma parece “OpenVPN roto”, pero la causa raíz es “escrituras de rutas no permitidas” o “rutas reescritas después de conectar”.

7) ¿Debería usar rutas persistentes para hacerlo estable?

Sólo si controlas el endpoint y sabes por qué lo necesitas. Las rutas persistentes pueden sobrevivir sesiones VPN y causar extraños fallos posteriores del tipo “¿por qué el tráfico entra en un túnel muerto?”. Prefiere rutas deterministas en tiempo de conexión gestionadas por el servicio VPN.

8) Mi ruta existe, pero las apps internas aún fallan. ¿Qué sigue?

Revisa DNS primero, luego firewall. Si haces ping por IP y funciona pero no por nombre, es DNS. Si resuelves nombres pero TCP falla, mira reglas de firewall y la ruta de retorno en el servidor. El enrutamiento es necesario, no suficiente.

9) ¿Cambiar métricas de interfaz es una buena solución a largo plazo?

PUEDE serlo, pero es afilado. Fijar métricas funciona mejor cuando se despliega vía política y se valida en distintos modelos de hardware. Como ajuste puntual de usuario es frágil: los nombres e índices de adaptador cambian y tu “arreglo” se convierte en una historia de fantasmas.

Conclusión: siguientes pasos que funcionan

“Route addition failed” no es un bug misterioso de OpenVPN. Es Windows negándose a un cambio de ruta por una razón: privilegio, conflicto, disponibilidad de interfaz o política. La solución que funciona es la que corresponde al modo de fallo.

Haz esto a continuación:

1. Captura la ruta que falla con exactitud y el código de estado de Windows desde el log de OpenVPN.
2. Demuestra la selección de ruta para una IP interna rota usando Get-NetRoute o tracert.
3. Elimina conflictos (rutas solapadas, adaptadores VPN dobles, rutas persistentes obsoletas).
4. Estandariza el modelo de privilegios: VPN como servicio es aburrido y correcto, y lo aburrido está subvalorado en producción.
5. Coordina con las herramientas de seguridad si los route add manuales fallan incluso con elevación.

Si adoptas un solo hábito: deja de tratar “conectado” como señal de éxito. Trata a la tabla de rutas como la fuente de la verdad. No es glamoroso, pero tampoco lo es pasar la mañana en un ticket de VPN que podrías haber cerrado en cinco minutos.