Cómo configurar una VPN de confianza en tu router con OpenVPN

Configurar una VPN de confianza directamente en tu router usando OpenVPN es una de las mejores formas de proteger toda tu red doméstica o de oficina sin tener que andar instalando aplicaciones en cada dispositivo. Desde el portátil del trabajo hasta el móvil, la Smart TV o un servidor NAS, todos se pueden beneficiar del mismo túnel cifrado con una sola configuración bien hecha.

Al mismo tiempo, esta configuración suele generar más de un quebradero de cabeza con IP públicas, CG-NAT, puertos, certificados y diferencias entre fabricantes (TP-Link, ASUS, Teltonika, Omada, etc.). En esta guía vas a encontrar una explicación detallada, unificando lo que hacen las principales marcas y ampliándolo con buenas prácticas, para que puedas montar un servidor OpenVPN estable y seguro en tu router sin dejarte nada importante por el camino.

Qué es una VPN y por qué montarla en el router con OpenVPN

Una VPN (red privada virtual) crea un túnel cifrado entre tu dispositivo y un servidor remoto. Ese túnel protege los datos que viajan por Internet frente a escuchas, robo de información o manipulaciones, y además permite que dispositivos que están físicamente en sitios distintos se comporten como si estuvieran dentro de la misma red local.

Cuando ese servidor VPN está dentro de tu propio router, consigues que todos los equipos conectados a la red local puedan ser accesibles de forma segura desde fuera (trabajar desde casa, acceder a cámaras, domótica, servidores internos, etc.), y además puedes hacer que el tráfico de tus dispositivos remotos salga a Internet a través de tu conexión doméstica.

OpenVPN es uno de los protocolos VPN más usados por su buen equilibrio entre seguridad, flexibilidad y compatibilidad. Routers de marcas como TP-Link, ASUS, Teltonika o ecosistemas como Omada lo integran de serie en modo servidor y cliente, así que es la opción natural cuando quieres controlar tú mismo la VPN en vez de depender de un servicio externo.

Requisitos básicos antes de crear tu servidor OpenVPN en el router

Antes de tocar nada en la configuración VPN conviene revisar algunos requisitos imprescindibles para que el servidor sea accesible desde Internet y funcione sin cortes.

En primer lugar, el router que quieres usar debe soportar servidor OpenVPN de forma nativa. Modelos TP-Link, ASUS o Teltonika lo incluyen, pero siempre es recomendable mirar la ficha técnica o el manual del fabricante para asegurarlo. En el entorno Omada (ER605, otros routers y el controlador OC200/OMADA software) también existe la opción de “Servidor VPN – OpenVPN”.

En segundo lugar, tu conexión a Internet necesita una IP pública accesible en la interfaz WAN del router que hace de servidor. Esto significa que tu operador (ISP) no debe tenerte detrás de un CG-NAT sin opción a abrir puertos. Si recibes una IP privada en la WAN (algo típico en ciertos operadores móviles o servicios como algunos radios de enlace), tendrás que solicitar una IP pública o estática al ISP, o no podrás recibir conexiones entrantes hacia la VPN.

Además, conviene que el router tenga el firmware actualizado a la última versión estable, ya que muchos fabricantes corrigen fallos de seguridad o problemas con OpenVPN en estas actualizaciones. ASUS, por ejemplo, recomienda actualizar el firmware antes de habilitar el servidor VPN, y proporciona guías específicas tanto para actualizar vía app como por WebGUI.

Por último, siempre ayuda tener la hora del sistema sincronizada con Internet (NTP activo y funcionando). Muchos routers lo hacen de forma automática, pero si el reloj interno está muy desfasado, los certificados de OpenVPN pueden dar problemas de validez.

IP pública, CG-NAT y DNS dinámico: la parte que suele romper la VPN

Uno de los motivos más habituales por los que un túnel OpenVPN no se conecta desde el exterior es que el router servidor no es realmente alcanzable desde Internet o el cliente está intentando llegar a una IP equivocada.

En configuraciones simples, con un único router conectado directamente al proveedor de Internet, basta con que la interfaz WAN tenga una IP pública y que el puerto que uses para OpenVPN esté abierto en el firewall del propio router. En estos casos, el archivo de configuración .ovpn que exporta el router suele incluir automáticamente esa IP WAN pública como “remote”.

El problema aparece cuando el ISP te asigna una IP privada mediante CG-NAT. Es lo que sucede con ciertos proveedores de radioenlace, algunas conexiones móviles o servicios concretos como Comporium u otros similares. En esos casos, el router ve en su WAN una IP del tipo 10.x.x.x, 172.16.x.x o 192.168.x.x, y aunque tú abras puertos, el tráfico nunca llegará porque el operador no reenvía esas conexiones. Aquí no hay truco: hay que hablar con el ISP y pedir una IP pública (idealmente estática) o un servicio específico que permita abrir puertos.

Otra situación frecuente es tener un router neutro o VPN detrás de un gateway del operador, como ocurre con los equipos de AT&T (BGW320-500) o con algunos routers de fibra que no permiten modo puente completo. En ese escenario, si el servidor OpenVPN está en el router secundario (por ejemplo, un TP-Link ER605 u otro router Omada), hay dos caminos típicos:

• IP Passthrough / Bridge parcial: el gateway del operador pasa la IP pública directamente al router neutro. El servidor OpenVPN del router neutro verá la IP pública en su WAN y todo será más sencillo.
• Reenvío de puertos (port forwarding / servidor virtual): el gateway mantiene su propia IP WAN pública, y reenvía el puerto de OpenVPN hacia la IP privada del router neutro.

Si usas IP Passthrough y el archivo .ovpn que exporta el sistema Omada sigue mostrando una IP privada del gateway como servidor, tendrás que modificar a mano la línea “remote” en el .ovpn para poner la IP pública real o un nombre DNS dinámico apuntando a ella.

Y aquí entra en juego el DNS dinámico (DDNS). Muchos routers TP-Link y ASUS recomiendan, antes de habilitar el servidor OpenVPN, activar un servicio DDNS (del propio fabricante o externo). De esta forma, aunque tu IP pública cambie, el archivo .ovpn puede usar un nombre (por ejemplo, tunel-casa.asuscomm.com) en lugar de una IP fija, y mientras el DDNS se actualice, los clientes podrán conectar sin problema.

Elección de protocolo, puerto y red de la VPN

Una vez tienes claro que tu router es alcanzable desde Internet, toca definir los parámetros básicos del servidor OpenVPN, comunes en la mayoría de fabricantes.

Lo primero es escoger el protocolo de transporte para la VPN: UDP o TCP. OpenVPN funciona muy bien con UDP, que suele ser la opción recomendada por rendimiento y menor latencia. Sin embargo, algunos entornos con firewalls estrictos sólo permiten tráfico TCP en ciertos puertos, por lo que, si tienes problemas de conexión, puedes probar a cambiar a TCP en el puerto 443 o similar para camuflar la VPN como si fuera tráfico HTTPS.

El siguiente ajuste clave es el puerto del servidor. OpenVPN utiliza por defecto el 1194/UDP, pero casi todos los routers dejan personalizarlo. Es buena idea elegir un número de puerto entre 1024 y 65535 para evitar colisiones con servicios habituales. En ASUS, por ejemplo, puedes marcar un valor como 2000, y en TP-Link se exige también que el puerto esté dentro de ese rango. Si tu entorno implica reenvíos en un router superior (como en redes con dos routers), tendrás que apuntar el mismo puerto interno hacia el router que aloja el servidor.

Otro punto importante es la subred de la VPN. OpenVPN asigna a los clientes direcciones IP de un rango distinto al de tu LAN. En las opciones suele aparecer “Subred/Máscara VPN” o “Grupo de direcciones IP”. Por ejemplo, podrías usar 10.8.0.0/24 para la VPN y mantener 192.168.1.0/24 para tu red local. El servidor “alquila” IPs de esa subred VPN a los clientes cuando se conectan.

Por último, debes decidir qué tipo de acceso tendrán los clientes cuando entren en la VPN. En casi todos los routers aparece algo similar a:

• Sólo red local / Sólo red doméstica: el dispositivo remoto sólo podrá acceder a la LAN que está detrás del router servidor (NAS, PCs, cámaras, etc.), pero seguirá usando su conexión a Internet local para salir a la web.
• Internet y red local / Internet y red doméstica: todo el tráfico del cliente pasa por la VPN; navega por Internet usando la conexión del router servidor y también ve la LAN remota.

Esta elección define si estás montando una VPN principalmente para acceso remoto a recursos internos o también para enrutar el tráfico de Internet (por privacidad o para salir desde tu IP doméstica).

Certificados, claves y seguridad del servidor OpenVPN

La seguridad de OpenVPN se apoya en un sistema de certificados, claves y cifrado. La mayoría de routers simplifican esta parte generando todos los elementos automáticamente, pero conviene entender lo que estás tocando.

En muchos modelos, al activar por primera vez el servidor OpenVPN aparece un botón de “Generar” certificado/clave. Esa acción crea la autoridad de certificación interna, el certificado del servidor y las claves necesarias para que los clientes se autentiquen de forma segura. Si borras la configuración, cambias parámetros avanzados o quieres renovar certificados, puedes volver a pulsar el botón para recrearlos.

En routers ASUS, además, se muestra una opción de “Encriptación RSA”, donde se puede seleccionar la longitud de la clave, habitualmente 1024 bits en configuraciones antiguas. Hoy en día, si el firmware lo permite, es preferible utilizar al menos 2048 bits para un nivel de seguridad más actual, aunque esto puede variar según el modelo y la versión del firmware. ASUS también ofrece una sección de “Detalles VPN > Configuración avanzada” donde se pueden modificar manualmente las claves y certificados, algo útil si quieres importar una CA externa o reutilizar certificados al sustituir el router.

Los fabricantes suelen advertir que cada vez que cambias ciertos parámetros del servidor (por ejemplo, cifrados, puertos o claves) es necesario volver a exportar el archivo de configuración .ovpn, ya que el cliente necesita tener siempre la versión actualizada de certificados y ajustes.

En entornos como Omada, además de los certificados, puedes reforzar la seguridad definiendo usuarios de VPN con usuario y contraseña propios, distintos a las credenciales del router. Esto añade una capa extra: aunque alguien obtenga el archivo .ovpn, necesitará las credenciales válidas para autenticarse.

Cómo configurar el servidor OpenVPN según el fabricante del router

La interfaz cambia bastante entre marcas, pero la idea es la misma: habilitar el servidor OpenVPN, ajustar los parámetros básicos y exportar la configuración. Vamos a repasar los matices más destacados de cada uno de los entornos comentados.

Routers TP-Link con servidor OpenVPN

En muchos routers TP-Link domésticos o profesionales, la configuración se hace desde la interfaz web yendo a “Avanzado > Servidor VPN > OpenVPN”. Allí se habilita el servidor y se ajustan el protocolo (UDP/TCP), el puerto, la subred VPN y el tipo de acceso del cliente (solo red doméstica o Internet + red doméstica).

Antes de activar el servidor, TP-Link recomienda configurar un servicio DNS dinámico o asignar una IP estática a la WAN y verificar que la hora esté sincronizada. Además, en algunas situaciones con ISP que usan CG-NAT, como ciertos radios de enlace o proveedores concretos, es directamente imposible usar OpenVPN hasta que consigas una IP pública. El asistente suele exigir también la generación inicial de certificados mediante el botón “Generar”.

Una vez seleccionado el tipo de servicio, puerto y subred de la VPN, sólo queda guardar la configuración, generar el certificado (si procede) y pulsar “Exportar” para descargar el archivo .ovpn que luego usarán los clientes. Ese archivo ya incluye, en la mayoría de casos, la dirección de acceso (IP o dominio DDNS), los certificados y todos los parámetros necesarios.

En redes con varios routers TP-Link (por ejemplo, un router módem y un router adicional donde corre OpenVPN), se añade un paso extra: en el router que está conectado al ISP (router1) hay que configurar un servidor virtual o reenvío de puertos hacia el router2 donde reside el servidor OpenVPN. El puerto interno de ese reenvío debe coincidir con el puerto de la VPN configurado en el router2, y se define un “puerto externo” que será el que el cliente usará al conectarse.

Después, es necesario editar manualmente el archivo .ovpn con un editor de texto (por ejemplo, Bloc de notas en Windows) para cambiar la dirección remota a la IP WAN del router1 y el puerto al “puerto externo” que acabas de configurar. Tras guardar esos cambios, los clientes ya podrán conectarse desde Internet hacia el router2 atravesando el router1 sin problemas.

Routers ASUS con servidor OpenVPN

ASUS integra el servidor OpenVPN en su firmware ASUSWRT y ofrece dos tipos de interfaz según la versión de firmware: una para versiones posteriores a 3.0.0.4.388.xxxx y otra para versiones anteriores, aunque los pasos conceptuales son muy similares.

Para empezar, se accede a la GUI web del router introduciendo la IP LAN o la URL http://www.asusrouter.com, se inicia sesión con usuario y contraseña del router y se va a la sección “VPN > Servidor VPN > OpenVPN”. Allí se activa la opción “Habilitar servidor OpenVPN” o se marca el botón correspondiente.

En la configuración general se definen el puerto del servidor, la encriptación RSA, el alcance de la VPN (sólo red local o Internet y red local) y las cuentas de cliente. De fábrica, muchos ASUS usan las mismas credenciales de administración del router como usuario/contraseña del cliente OpenVPN, pero es mucho más sensato crear cuentas nuevas específicas para la VPN desde la propia sección de configuración.

Una vez ajustados los parámetros, se pulsa “Apply all settings” o “Aplicar” para guardar. El router tarda un poco en inicializar el servidor OpenVPN y generar el archivo de configuración. Cuando termina, se ofrece la opción de exportar un archivo “client.ovpn” que contiene la configuración lista para ser usada en la utilidad OpenVPN del cliente.

ASUS también incluye opciones avanzadas para exportar e importar certificados, de forma que si cambias de router puedas mantener la misma certificación del servidor, y un apartado donde modificar manualmente el contenido de claves y certificados. Esto es útil en entornos avanzados con infraestructura PKI propia.

Routers Teltonika y topologías TAP/TUN

En el caso de Teltonika, la documentación se centra mucho en escenarios entre routers, con un servidor central y múltiples clientes, algo muy típico en entornos industriales o de telemetría (SCADA, autómatas, etc.).

Un punto que destacan es el uso del método de autenticación TLS en vez de “static key” cuando necesitas más de un cliente. Con TLS, cada cliente tiene su certificado y es más sencillo revocar accesos o añadir nuevos equipos. Además, señalan que, por defecto, los clientes no pueden comunicarse entre sí, sólo con el servidor; esta separación puede ser deseable por seguridad si cada cliente pertenece a un usuario distinto. Si se quiere una red “abierta” donde los clientes se vean entre ellos, hay que activar explícitamente la opción de permitir comunicación entre clientes en el router servidor.

A nivel lógico, Teltonika diferencia entre VPN TAP (bridged, capa 2) y VPN TUN (routed, capa 3). Con TAP, todos los dispositivos incluidos en la VPN comparten el mismo rango IP que la LAN y los interfaces de red de los routers (LAN) están también en ese rango; es muy transparente y útil para dispositivos que no permiten configurar gateway por defecto. Con TUN, en cambio, la VPN funciona a nivel de capa 3, cada red mantiene su propio rango y se encamina el tráfico mediante rutas, lo que suele ser más eficiente y escalable.

Un ejemplo típico que muestran es colocar el router servidor de la VPN detrás de un router de banda ancha con IP fija. El servidor Teltonika conecta su puerto WAN (RJ45) a la LAN del router de acceso a Internet. El router de banda ancha, a su vez, debe reenviar el puerto de OpenVPN hacia el servidor Teltonika, y los clientes se conectan usando la IP pública (o dominio) del router de acceso a Internet.

Entorno Omada (TP-Link ER605, OC200 y servidor OpenVPN)

En el ecosistema Omada (por ejemplo, con un router TP-Link ER605 y un controlador OC200), el flujo habitual para una VPN “Cliente a Sitio” con OpenVPN pasa por varias pantallas en el controlador.

Primero, en “Configuración > VPN” se crea una nueva política de VPN del tipo “Servidor VPN – OpenVPN”, dándole un nombre descriptivo, marcándola como habilitada y seleccionando el propósito “Cliente a Sitio”. Aquí se elige también el modo de túnel (dividido o completo), el protocolo (TCP/UDP), el puerto de servicio (por defecto 1194), el modo de autenticación (local) y el tipo de red local a la que podrán acceder los clientes (especificando el rango, por ejemplo 192.168.1.0/24). Además, se pueden definir servidores DNS para los clientes (por ejemplo, 8.8.8.8 y 8.8.4.4).

Después se pasa a “Configuración > VPN > Usuarios de VPN” para crear cuentas específicas de OpenVPN, donde eliges nombre de usuario, contraseña, protocolo (OpenVPN) y asocias ese usuario al servidor que acabas de definir.

Una vez creado todo esto, en la lista de políticas de VPN puedes exportar el archivo .ovpn correspondiente a ese servidor. Ese fichero incluirá la configuración completa, certificados y, normalmente, la dirección del servidor.

Si el router está detrás de otro dispositivo (como el BGW320-500 de AT&T), puede ocurrir que, al exportar el .ovpn, aparezca como dirección del servidor una IP privada en vez de la pública. En este caso toca editar el archivo y reemplazar la IP privada por la IP pública real, o por un dominio DDNS que resuelva a esa IP. También hay que asegurarse de que el gateway de AT&T reenvíe el puerto de OpenVPN al ER605, o configurar IP Passthrough según las guías del fabricante.

En algunas situaciones, la aplicación OpenVPN Connect puede fallar mientras que el cliente “Community” funciona mejor. Hay usuarios que han tenido que añadir manualmente parámetros en el .ovpn, como ajustar los cifrados con una línea “data-ciphers AES-128-CBC” o añadir opciones como “mute-replay-warnings” para evitar alertas molestas, siempre adaptándose a lo que el servidor soporte.

Configuración del cliente OpenVPN en dispositivos remotos

Una vez listo el servidor y exportado el archivo .ovpn, la otra mitad del trabajo consiste en instalar y configurar el cliente OpenVPN en los dispositivos que vayan a conectarse de forma remota.

En ordenadores Windows, macOS y Linux, el proceso típico es descargar el OpenVPN Community Client desde la web oficial de OpenVPN. Tras la instalación, se copia el archivo .ovpn proporcionado por el router a la carpeta de configuración del cliente, que suele ser “C:\\Program Files\\OpenVPN\\config” en Windows o “/etc/openvpn/” en muchos sistemas Linux y algunas instalaciones de macOS (dependiendo de si se usa interfaz gráfica u otro front-end).

Después, se inicia la utilidad de cliente OpenVPN, se importa o selecciona el perfil .ovpn y se pulsa para conectar. Si el servidor requiere usuario y contraseña adicionales (como en Omada o en ciertas configuraciones ASUS avanzadas), el cliente los pedirá en el momento de establecer el túnel.

En dispositivos móviles (Android o iOS), hay que instalar una app compatible con OpenVPN desde Google Play o App Store. Normalmente se importa el archivo .ovpn directamente desde el almacenamiento del dispositivo, desde un correo o nube. Algunos proveedores recomiendan evitar OpenVPN Connect en entornos específicos y optar por clientes alternativos o por la versión “Community” si da problemas con ciertos parámetros modernos de cifrado.

Si la conexión falla, lo primero es revisar que el puerto de la VPN está accesible desde Internet (puedes probar con herramientas de comprobación de puertos), que el “remote” del .ovpn apunta a la IP o dominio correctos y que no hay CG-NAT sin resolver. Luego conviene mirar los logs del cliente para ver si el error es de resolución, de tiempo de espera, de autenticación o de cifrado.

Buenas prácticas, problemas típicos y cómo evitar caer en ellos

Montar un servidor OpenVPN estable en un router implica cuidar algunos detalles que, si se pasan por alto, generan errores difíciles de diagnosticar, sobre todo cuando hay varios equipos en cadena (gateway del operador + router neutro + controlador, etc.).

Una recomendación recurrente de todos los fabricantes es no reutilizar usuario y contraseña de administración del router como credenciales del cliente VPN. Aunque a veces vengan así por defecto, es mejor crear usuarios específicos con permisos sólo para la VPN, de forma que un compromiso del cliente no implique acceso total al router.

Además, cuando sustituyes el router o borras la configuración, tiene mucho sentido exportar previamente los certificados actuales (si la interfaz lo permite) para luego importarlos de nuevo y evitar tener que redistribuir perfiles .ovpn a todos los usuarios. ASUS, por ejemplo, permite exportar la certificación actual del servidor y luego importarla en un router nuevo.

En cuanto al cifrado, conviene mantener parámetros actualizados (algoritmos y tamaño de claves) y no quedarse anclado en valores heredados del pasado si el firmware ofrece opciones más robustas. Al mismo tiempo, si actualizas el cifrado en el servidor, tendrás que regenerar o reexportar las configuraciones y, en algunos casos, añadir o ajustar parámetros en el cliente (como las líneas relacionadas con data-ciphers en versiones recientes de OpenVPN).

Otro clásico son los conflictos de red: si tu subred local es la misma que la de la VPN o coincide con la LAN desde la que se conecta el cliente, puedes encontrarte con rutas extrañas o tráfico que no sabe por dónde ir. Por eso se recomienda usar un rango separado para la VPN (10.8.0.0/24, por ejemplo) y, si tuvieras varias sedes enlazadas, asegurarte de que cada una tenga un rango LAN distinto.

Cuando hay dos o más routers en el esquema, como en la típica red con router del ISP más un router avanzado o un router VPN, la regla de oro es que sólo uno de ellos haga de servidor OpenVPN y que el otro se limite a reenviar puertos o a pasar la IP pública. También es importante no mezclar demasiado los roles (por ejemplo, no configurar a la vez en un mismo router un servidor y un cliente OpenVPN del mismo tipo si el firmware no lo soporta, algo que ASUS advierte explícitamente).

Si tras seguir todos los pasos sigues sin poder conectar desde fuera de tu red WiFi doméstica, es muy posible que el bloqueo venga de la parte del operador (CG-NAT o restricciones de puerto). En ese caso, contactar con el ISP y explicar que necesitas una IP pública (o que se desactive CG-NAT) suele ser el paso definitivo que muchos tutoriales pasan por alto pero que marca la diferencia.

Con todo esto bien configurado, un servidor OpenVPN en tu router se convierte en una herramienta muy potente: te permite acceder de forma segura a tus equipos desde cualquier lugar, integrar sedes remotas como si fueran una sola red y mantener el control total sobre tus datos sin depender de servicios de terceros, lo que para muchos usuarios avanzados y pequeñas empresas es justamente lo que estaban buscando.