IPsec MikroTik: VPN IKEv2 de acceso remoto en RouterOS

Tu equipo dejó de estar todo en la oficina hace rato. Ingenieros que entran al core desde su casa, operadores de NOC que necesitan llegar a un router en un sitio remoto, contratistas que consumen un servicio interno sin exponerlo a internet. La pregunta no es si vas a dar acceso remoto, sino cómo lo haces sin abrir Winbox al mundo ni depender de un túnel frágil que se cae cada vez que cambia la IP del cliente. Para eso, IPsec MikroTik con IKEv2 es una de las respuestas más sólidas que tienes sobre RouterOS: cifrado estándar, reconexión rápida ante cambios de red y clientes nativos en Windows, macOS, iOS y Android sin instalar software de terceros.

En este artículo desarmamos cómo se arma un acceso remoto tipo road warrior con IKEv2 y mode-config en RouterOS v7, qué menús intervienen, cómo encajan las piezas de fase 1 y fase 2, y los detalles de firewall que suelen dejar el túnel "arriba pero sin tráfico". Todo apoyado en la configuración real de RouterOS, no en recetas de memoria.

Por qué IKEv2 y no L2TP/IPsec o PPTP

Durante años el acceso remoto sobre MikroTik se resolvió con L2TP/IPsec. Funciona, pero arrastra doble encapsulamiento, más overhead y un comportamiento pobre cuando el cliente cambia de red (del Wi-Fi de la casa a los datos móviles, por ejemplo). IKEv2 puro, en cambio, negocia el túnel directamente con el protocolo IKE versión 2 y trae MOBIKE, que le permite al cliente migrar de una interfaz a otra sin renegociar toda la conexión. Para un ingeniero que se mueve entre redes, eso significa que la sesión sobrevive al cambio en lugar de morir.

La comparación rápida, dejando fuera PPTP (que ya no es una opción seria por su cifrado roto):

Aspecto	L2TP/IPsec	IKEv2 (mode-config)
Encapsulamiento	Doble (L2TP dentro de IPsec)	IPsec directo, más liviano
Roaming de red	Renegocia toda la sesión	MOBIKE, migra sin cortar
Cliente nativo	Sí, pero con más pasos	Sí, con perfil/certificado
Asignación de IP y rutas	Vía PPP	Vía mode-config del propio IPsec

La clave del acceso remoto moderno con IPsec MikroTik es mode-config: el router actúa de responder, autentica al cliente y le entrega una IP interna, DNS y las subredes que puede alcanzar, igual que un DHCP pero dentro del túnel cifrado.

Las piezas de IPsec en RouterOS: fase 1 y fase 2

Antes de escribir comandos conviene tener claro qué hace cada menú de /ip/ipsec, porque IPsec no es "una" configuración sino varias piezas que se referencian entre sí:

• profile — parámetros de la fase 1 (IKE): grupo Diffie-Hellman, algoritmo de cifrado, hash y tiempos de vida. Es cómo se establece el canal seguro inicial.
• proposal — parámetros de la fase 2 (IPsec SA): qué algoritmos protegen el tráfico real de datos, con opción de PFS (Perfect Forward Secrecy).
• peer — con quién hablas y con qué exchange-mode. Para acceso remoto se fija exchange-mode=ike2.
• identity — cómo se autentica ese peer: pre-shared key, certificado (rsa) o EAP con usuario y contraseña.
• mode-config — el pool de IPs, DNS y subredes que se le entregan al cliente remoto.
• policy y policy/group — qué tráfico entra al túnel. Para road warrior se usa una plantilla (template=yes) y generate-policy crea las políticas dinámicas por cliente.

Entender esta separación evita el error más común: tocar la proposal cuando el problema está en el profile, o al revés. Si la fase 1 no levanta, ni siquiera llegas a negociar la fase 2.

Configuración de acceso remoto IKEv2 con IPsec MikroTik

Veamos un road warrior con autenticación EAP (usuario/contraseña sobre un certificado del servidor), que es el esquema más cómodo para dar acceso a varias personas. El router es el responder; los clientes son iniciadores. Asumimos que ya tienes un certificado de servidor emitido y confiable en /certificate.

/ip/ipsec/profile
add name=ike2-ra dh-group=modp2048 enc-algorithm=aes-256 hash-algorithm=sha256

/ip/ipsec/proposal
add name=ike2-ra enc-algorithms=aes-256-cbc,aes-128-cbc pfs-group=modp2048

/ip/pool
add name=ipsec-pool ranges=10.20.20.10-10.20.20.100

/ip/ipsec/mode-config
add name=ra-cfg address-pool=ipsec-pool address-prefix-length=32 \
    split-include=10.0.0.0/24 static-dns=10.0.0.1 system-dns=no

/ip/ipsec/policy/group
add name=ra-group

/ip/ipsec/policy
add group=ra-group template=yes proposal=ike2-ra \
    dst-address=10.20.20.0/24 src-address=0.0.0.0/0

/ip/ipsec/peer
add name=ike2-ra exchange-mode=ike2 passive=yes profile=ike2-ra

/ip/ipsec/identity
add peer=ike2-ra auth-method=eap eap-methods=eap-mschapv2 \
    generate-policy=port-strict mode-config=ra-cfg \
    policy-template-group=ra-group certificate=server-cert

Qué está pasando aquí, línea por concepto:

• mode-config entrega IPs del pool 10.20.20.0/24, publica el DNS interno y, vía split-include, le dice al cliente que solo enrute hacia 10.0.0.0/24 por el túnel (split tunneling). Si quisieras forzar todo el tráfico del cliente por el túnel, usarías split-include=0.0.0.0/0.
• peer con passive=yes deja al router esperando conexiones entrantes en exchange-mode=ike2, el rol correcto para un servidor de acceso remoto.
• identity con auth-method=eap y eap-methods=eap-mschapv2 autentica a cada usuario con credenciales; generate-policy=port-strict crea las políticas dinámicas por cliente a partir de la plantilla del grupo.

Los usuarios EAP se dan de alta en la base local del router o, mejor a escala, delegando la autenticación a un servidor RADIUS (el servicio ipsec de RADIUS existe justamente para esto). Verificar el estado es directo:

/ip/ipsec/active-peers/print
/ip/ipsec/installed-sa/print

Si active-peers muestra el peer establecido pero installed-sa no lista SAs instaladas, el problema casi siempre está en la fase 2: una proposal que no calza o una política que no se generó.

El firewall: donde el túnel "sube pero no pasa tráfico"

Este es el punto que más consultas genera. IPsec en RouterOS no crea una interfaz lógica que puedas usar en las listas de interfaces; el tráfico se procesa por políticas IPsec dentro del flujo de paquetes. Por eso hay dos cosas no negociables en el firewall de RouterOS:

• Abrir los puertos de IKE en la cadena input: UDP/500 y UDP/4500 (este último para NAT-T, indispensable cuando el cliente está detrás de NAT), más el protocolo IPsec-ESP.
• Sacar el tráfico IPsec del FastTrack. La configuración por defecto trae una regla deshabilitada justo para esto; hay que habilitarla siempre que uses túneles IPsec.

/ip/firewall/filter
add chain=input action=accept protocol=udp port=500,4500 \
    comment="IKE / NAT-T"
add chain=input action=accept protocol=ipsec-esp \
    comment="IPsec ESP"
add chain=forward action=accept ipsec-policy=in,ipsec \
    comment="accept all that matches IPSec policy" place-before=0

La regla ipsec-policy=in,ipsec es la que deja pasar el tráfico ya desencriptado que matchea una política IPsec, y debe ubicarse antes de la regla de FastTrack. Si el paquete cifrado cae en FastTrack, salta el procesamiento de políticas y el túnel queda "arriba" sin cursar tráfico útil. En redes IPv6 esta consideración no aplica, porque no soporta FastTrack.

Un detalle operativo: si tus clientes remotos deben salir a internet a través del router (full tunnel), recuerda que el tráfico que ya viaja dentro del túnel no debe volver a pasar por el masquerade del WAN sin una excepción por política IPsec, o romperás el retorno. Cuando el diseño mezcla acceso remoto con túneles site-to-site y CGNAT, el orden de las reglas deja de ser trivial.

Errores frecuentes al desplegar IPsec MikroTik

• Proposals que no calzan. Cliente y servidor deben coincidir en algoritmos de fase 2. Un iOS moderno rechaza cifrados débiles; si dejas solo 3DES, no negocia. Ofrece AES-256/AES-128 con SHA-256.
• Identidad mal acotada. Con generate-policy mal configurado, un cliente puede generar políticas que pisan a otro. port-strict es más seguro que port-override para acceso remoto multiusuario.
• DNS y split-include olvidados. El túnel levanta, pero el usuario no resuelve nombres internos ni alcanza la subred esperada porque el mode-config no publicó DNS ni las rutas correctas.
• Certificado del servidor no confiable. En EAP, el cliente valida el certificado del router. Si no está firmado por una CA que el cliente confíe (o importada), la conexión falla en la validación, no en IPsec.

Ninguno de estos es un bug de RouterOS: son piezas que hay que alinear entre el diseño del túnel, el firewall y el cliente. Si administras un core donde el acceso remoto convive con túneles site-to-site, WireGuard y VPN de sucursales, vale la pena estandarizar los perfiles y proposals para no terminar con veinte variantes imposibles de auditar.

Cuándo conviene una revisión de ingeniería

Un acceso remoto IKEv2 para tres ingenieros lo levantas en una tarde. El problema aparece cuando escala: decenas de usuarios con RADIUS, integración con la política de firewall existente, coexistencia con CGNAT, segmentación por perfil de usuario, rotación de certificados y una CA propia bien administrada. Ahí la diferencia entre "funciona" y "es operable y auditable" la marca el diseño. Un túnel que autentica bien pero deja rutas de más, o un firewall que expone Winbox mientras cree que solo abrió IKE, es tan riesgoso como no tener VPN.

En MikroTik Chile diseñamos e implementamos acceso remoto y VPN sobre RouterOS pensando en operación real: autenticación centralizada, políticas de firewall coherentes, segmentación y documentación para que tu NOC pueda mantenerlo sin depender de quien lo configuró. Si estás por montar o revisar tu esquema de acceso remoto, conversemos sobre tu caso en una consultoría técnica. De ingeniero a ingeniero, revisamos tu topología y te decimos qué endurecer antes de exponerlo.