Cómo Configurar VPN WireGuard en MikroTik: Tutorial Paso a Paso

WireGuard llegó al RouterOS en la versión 7.1 y rápidamente se convirtió en el protocolo VPN preferido para interconectar routers MikroTik. Es más rápido que OpenVPN, más simple que IPSec, usa criptografía moderna (ChaCha20, Curve25519, BLAKE2) y funciona incluso en redes inestables.

En este tutorial, configurarás un túnel VPN WireGuard site-to-site entre dos routers MikroTik — un escenario clásico para interconectar sede con sucursal o acceso remoto a la red de un cliente.

Requisitos previos

• RouterOS 7.1 o superior en ambos routers
• Al menos uno de los routers con IP pública accesible (o usa un relay — explicado al final)
• Acceso root/admin en ambos
• Puertos UDP liberados en el firewall (por defecto WireGuard: 13231, pero puede ser cualquier puerto)

Arquitectura del túnel

En el ejemplo de este tutorial:

• Router A (Servidor/Hub): IP público 203.0.113.1 — porta WireGuard 13231
• Router B (Cliente/Spoke): detrás de CGNAT o IP dinámico — inicia la conexión
• Red del Router A: 192.168.1.0/24
• Red del Router B: 192.168.2.0/24
• Direcciones del túnel: 10.0.0.1/30 (A) e 10.0.0.2/30 (B)

Configuración paso a paso

# En el Router A — crear interfaz WireGuard
# El RouterOS genera automáticamente el par de claves
/interface wireguard add \
  name=wg-site \
  listen-port=13231

# Ver la clave pública generada
/interface wireguard print
# Anota el valor de "public-key" — lo necesitarás en el Router B

# En el Router B — crear interfaz WireGuard
/interface wireguard add \
  name=wg-site \
  listen-port=13231

# Anota la clave pública del Router B también
/interface wireguard print

# En el Router A
/ip address add \
  address=10.0.0.1/30 \
  interface=wg-site

# En el Router B
/ip address add \
  address=10.0.0.2/30 \
  interface=wg-site

# En el Router A — agregar Router B como peer
/interface wireguard peers add \
  interface=wg-site \
  public-key="CHAVE_PUBLICA_DO_ROTEADOR_B" \
  allowed-address=10.0.0.2/32,192.168.2.0/24 \
  persistent-keepalive=25

# En el Router B — agregar Router A como peer
/interface wireguard peers add \
  interface=wg-site \
  public-key="CHAVE_PUBLICA_DO_ROTEADOR_A" \
  endpoint-address=203.0.113.1 \
  endpoint-port=13231 \
  allowed-address=10.0.0.1/32,192.168.1.0/24 \
  persistent-keepalive=25

# En el Router A — ruta hacia la red del Router B
/ip route add \
  dst-address=192.168.2.0/24 \
  gateway=10.0.0.2

# En el Router B — ruta hacia la red del Router A
/ip route add \
  dst-address=192.168.1.0/24 \
  gateway=10.0.0.1

# En el Router A (el que recibe conexiones)
/ip firewall filter add \
  chain=input \
  protocol=udp \
  dst-port=13231 \
  action=accept \
  comment="WireGuard VPN" \
  place-before=0

Verificar que el túnel está funcionando

# Verificar estado del peer — "last-handshake" debe aparecer
/interface wireguard peers print

# Probar conectividad por el túnel
/ping 10.0.0.2          # IP del túnel del Router B
/ping 192.168.2.1       # Gateway de la red del Router B

Si el last-handshake muestra un timestamp reciente (menos de 2 minutos) y el ping responde, el túnel está activo.

Escenario CGNAT: ambos sin IP pública

Cuando ninguno de los dos routers tiene IP pública (ambos detrás de CGNAT), la conexión directa no es posible. Las opciones son:

1. Contratar IP fija — solución más simple, costo adicional con el operador
2. VPS como relay — un servidor con IP pública en el medio, haciendo de concentrador
3. DDNS + port-forwarding en el router del operador — funciona en CGNAT leve (CGN sin mapeo doble)
4. Plataforma con relay integrado — como Mikrosinc, que provisiona automáticamente el túnel incluso en CGNAT total sin exigir VPS ni IP fija

Errores comunes y cómo resolverlos

Handshake no se establece

• Verifica que el puerto UDP 13231 está liberado en el firewall del Router A
• Confirma que las claves públicas fueron copiadas correctamente (sin espacios extra)
• Prueba si el IP/puerto del endpoint es accesible: /tool tcp-ping 203.0.113.1 13231

Handshake se establece pero el ping no funciona

• Verifica que las rutas fueron agregadas correctamente en ambos lados
• Confirma que allowed-address incluye la subnet de la red remota
• Verifica si hay reglas de firewall bloqueando tráfico en la interfaz wg-site

El túnel cae después de unos minutos

• Activa persistent-keepalive=25 en el peer que está detrás de NAT
• Verifica que el router con IP pública no está reiniciando la interfaz