Remote Access
Guía de VPN IPsec Sitio a Sitio MikroTik
Crea una VPN IPsec sitio a sitio en MikroTik: configura el peer IKEv2, la propuesta, la política y la regla de bypass NAT que hace funcionar el túnel.
Resumen Una VPN IPsec sitio a sitio en MikroTik cifra el tráfico entre dos redes completas —una oficina central y una sucursal, un NOC y un sitio de torre— para que los hosts de cada LAN alcancen la otra como si fuera local. Esta guía configura ambos routers con RouterOS v7: el peer IKEv2, la identidad con clave precompartida, la propuesta de Fase 2, la política del túnel, la regla de bypass NAT que arruina la mayoría de los primeros intentos, y las reglas de firewall y comprobaciones que confirman que el túnel está activo.
¿Qué es una VPN IPsec sitio a sitio en MikroTik?
Una VPN IPsec sitio a sitio en MikroTik es un túnel cifrado permanente entre dos routers que une dos LAN separadas en una única red enrutable en la capa 3, sin que ninguno de los routers exponga un puerto de gestión a internet. A diferencia de las VPN de acceso de clientes como WireGuard u OpenVPN —donde se conecta un único equipo de administración—, un túnel sitio a sitio está siempre activo y va de subred a subred: cada host detrás del Router A alcanza automáticamente cada host permitido detrás del Router B. IPsec es la herramienta adecuada aquí porque es un estándar abierto compatible con prácticamente cualquier fabricante de firewalls y routers, se ejecuta en el kernel de RouterOS con buen rendimiento y en MikroTik viene integrado, sin paquetes adicionales que instalar.
El túnel se construye en dos negociaciones. La Fase 1 (IKE) autentica ambos routers entre sí y establece un canal seguro; la Fase 2 (IPsec) negocia las claves que realmente cifran tu tráfico de datos. Si ambas fases coinciden en cada extremo, el túnel se levanta; si un solo algoritmo no coincide, falla en silencio, y por eso los pasos siguientes mantienen los dos lados simétricos.
Antes de empezar
Necesitas dos routers MikroTik con RouterOS v7, cada uno con una dirección IP pública o un hostname DDNS funcional, y dos subredes LAN que no se solapen. Esta guía usa 192.168.10.0/24 en Site A y 192.168.20.0/24 en Site B. Si ambos sitios usan 192.168.88.0/24, el enrutamiento es imposible: readdresa un lado primero. Como IPsec es muy sensible al desfase de reloj, habilita NTP en ambos routers antes de empezar; si los dos extremos se desincronizan, las asociaciones de seguridad expiran y el túnel se cae una y otra vez.
Gestionar ese requisito previo en más de un puñado de sitios ya es una tarea pesada. Cuando operas una flota, MKController te da una única consola para confirmar la versión de RouterOS y la fuente de reloj de cada router antes de conmutar un túnel, así no tienes que entrar en cada equipo solo para comprobar que está listo.
Paso 1: Crear el perfil IKE y el peer
En Site A, define el perfil de Fase 1 y apunta un peer a la dirección pública de Site B:
/ip ipsec profile add name=to-siteB hash-algorithm=sha256 \ enc-algorithm=aes-256 dh-group=modp2048 lifetime=1d
/ip ipsec peer add name=siteB address=<SITE_B_PUBLIC_IP>/32 \ profile=to-siteB exchange-mode=ike2dh-group=modp2048 es el Grupo 14 de Diffie-Hellman, un valor por defecto moderno y sólido. exchange-mode=ike2 selecciona IKEv2, que es más rápido y robusto que el modo heredado main/IKEv1. Ambos extremos deben usar los mismos valores de perfil y el mismo modo de intercambio.
Paso 2: Añadir la identidad (clave precompartida)
/ip ipsec identity add peer=siteB auth-method=pre-shared-key \ secret="<long-random-shared-secret>"Usa un secreto largo y aleatorio, y guárdalo como guardarías una clave SSH: no en un mensaje de chat. El mismo secreto va en ambos routers.
Paso 3: Definir la propuesta de Fase 2
/ip ipsec proposal add name=to-siteB auth-algorithms=sha256 \ enc-algorithms=aes-256-cbc pfs-group=modp2048Perfect Forward Secrecy (pfs-group) significa que cada renovación de claves usa material criptográfico nuevo, de modo que una clave comprometida nunca expone el tráfico anterior. Igual que en la Fase 1, los algoritmos deben coincidir en ambos extremos.
Paso 4: Crear la política del túnel
La política le indica a RouterOS qué tráfico cifrar: el de la LAN local hacia la LAN remota.
/ip ipsec policy add peer=siteB tunnel=yes \ src-address=192.168.10.0/24 dst-address=192.168.20.0/24 \ proposal=to-siteB action=encrypttunnel=yes es lo que hace que esto sea sitio a sitio en lugar de host a host: los paquetes originales se encapsulan enteros, de modo que las dos LAN se comunican de forma transparente.
Paso 5: Añadir la regla de bypass NAT (el paso que todos olvidan)
Aquí es donde se rompen la mayoría de los primeros intentos. Tu router ya tiene una regla masquerade que reescribe la dirección de origen del tráfico LAN saliente. Si esa regla actúa antes que IPsec, el extremo remoto recibe paquetes cuyo origen ya no coincide con la política y los descarta. Añade una regla accept por encima de masquerade para que el tráfico destinado al túnel se salte el NAT:
/ip firewall nat add chain=srcnat action=accept place-before=0 \ src-address=192.168.10.0/24 dst-address=192.168.20.0/24place-before=0 coloca la regla en lo más alto de la cadena srcnat, lo cual es obligatorio: una regla de bypass situada después de masquerade no hace nada.
Paso 6: Abrir el firewall y verificar
Permite los puertos de IKE y NAT-T más el protocolo ESP en la cadena input para que el túnel pueda establecerse, sobre todo si alguno de los sitios está detrás de otro dispositivo NAT:
/ip firewall filter add chain=input protocol=udp dst-port=500,4500 action=accept/ip firewall filter add chain=input protocol=ipsec-esp action=acceptLuego confirma que el túnel está activo:
/ip ipsec active-peers print/ip ipsec policy printUn túnel sano muestra un peer activo y una política cuyo ph2-state indica established. Un ping rápido desde un host de una LAN a un host de la otra demuestra la conectividad de extremo a extremo.
Replicar la configuración en Site B
Repite cada paso en Site B con las direcciones invertidas: el peer apunta a la IP pública de Site A, y la política y el bypass NAT usan src-address=192.168.20.0/24 y dst-address=192.168.10.0/24. El perfil, la propuesta, el secreto de la identidad y el modo IKEv2 se mantienen idénticos. Cuando ambos lados coinciden, la Fase 1 y la Fase 2 se completan y el túnel se levanta.
Consejos de seguridad y operación
Mantén RouterOS actualizado: versiones recientes han traído correcciones que afectan a la comparación de certificados de peer en IPsec/IKEv2, así que un túnel que funcionaba el trimestre pasado merece una nueva prueba después de cada actualización. Prefiere IKEv2 con PFS antes que los valores por defecto heredados de IKEv1. Cuando puedas, pasa de un secreto compartido a autenticación por certificados a medida que crece el número de túneles, porque una sola clave precompartida filtrada afecta a todos los sitios que la comparten. Y registra el estado del túnel en algún sitio que realmente mires: un enlace sitio a sitio caído es invisible hasta que alguien intenta alcanzar la LAN remota y no puede.
En una flota, un túnel IPsec que se cae en silencio tras una desincronización de reloj o un corte de WAN es exactamente el tipo de fallo que el cliente detecta antes que tú. MKController cierra esa brecha: vigila cada router a través de un túnel saliente seguro que no necesita IP pública ni redirección de puertos en el equipo, mantiene copias de configuración versionadas para que puedas comparar y restaurar un bloque IPsec que funcionaba tras una edición desafortunada, y puede abrir un ticket ante un evento de enlace caído antes de que suene el teléfono. Para la configuración del túnel en sí, nuestra guía sobre NAT en MikroTik explica la regla masquerade que aquí estás evitando, y si lo que quieres es llegar a un único router en lugar de unir dos LAN, consulta gestión remota detrás de CGNAT y nuestro tutorial de gestión remota con WireGuard.
Reúne tus túneles bajo un mismo techo
IPsec une dos sitios de forma limpia, pero un ISP o MSP en crecimiento pronto tiene decenas de túneles, claves y reglas de firewall que mantener sincronizados, y cada edición manual es una oportunidad de quedarte fuera de un sitio remoto. MKController está hecho justo para esa escala: gestión centralizada de la flota, acceso remoto seguro sin puertos expuestos, historial de configuración y copias de seguridad, y despliegues de cambios de firewall y políticas a toda la flota, de modo que una plantilla de túnel se aplica una vez en lugar de reescribirse router por router. Los operadores que trabajan con MikroTik a escala lo usan para convertir una tarde perdida haciendo SSH equipo por equipo en unos pocos clics por cambio.