WireGuard site-to-site entre dos MikroTik: Guía paso a paso 2026

Conectar dos oficinas, dos PoPs de un WISP o dos sucursales de forma segura a través de internet es una necesidad constante. Hasta RouterOS 6, la única opción nativa era IPsec u OpenVPN — ambos funcionales pero tediosos de configurar y con mal rendimiento en hardware ARM. Desde RouterOS 7, WireGuard está disponible nativamente y se ha convertido en la opción por defecto para túneles site-to-site en la flota que administramos en MikroHelp.

Esta guía cubre la configuración completa de un túnel WireGuard site-to-site entre dos MikroTik RouterOS 7, con comandos listos para pegar, diagrama de topología, rutas, firewall y verificación. Aplicable a cualquier par de equipos MikroTik: CCR, CRS con ROS, hAP, RB4011, etc.

1. Topología y planificación de IPs

Usaremos un ejemplo real: sede central en Ciudad de México con una subred 192.168.10.0/24 y sucursal en Monterrey con 192.168.20.0/24. El túnel WireGuard usará el rango 10.200.200.0/30 para los dos endpoints.

El router A expone el puerto UDP 51820 en su WAN. El router B se conecta hacia el A. Una vez establecido, el túnel es bidireccional.

2. Configuración Router A (sede central)

Creamos la interfaz WireGuard, le asignamos IP, y agregamos el peer correspondiente al router B. RouterOS genera las claves automáticamente al crear la interfaz.

# 1. Crear la interfaz WireGuard
/interface wireguard add name=wg-mty listen-port=51820 mtu=1420 comment="tunnel to MTY"

# 2. Ver la clave pública generada (la necesitas para configurar el router B)
/interface wireguard print detail
# Copiar el campo public-key, ejemplo:
# public-key="xAbCdEfGhIjKlMnOpQrStUvWxYz0123456789aBcDeFgHi="

# 3. Asignar IP al endpoint del túnel
/ip address add address=10.200.200.1/30 interface=wg-mty comment="WG tunnel A"

# 4. Abrir puerto UDP 51820 en el firewall (input chain)
/ip firewall filter add chain=input protocol=udp dst-port=51820 action=accept place-before=0 comment="accept WireGuard"

3. Configuración Router B (sucursal)

En el router B hacemos el mismo procedimiento: crear la interfaz, asignar IP, y luego agregar el peer remoto apuntando al router A con su clave pública y endpoint.

# 1. Crear la interfaz WireGuard
/interface wireguard add name=wg-cdmx listen-port=51820 mtu=1420 comment="tunnel to CDMX"

# 2. Ver la clave pública generada del router B
/interface wireguard print detail
# Guarda este public-key — lo usarás en el paso 5 del router A

# 3. Asignar IP al endpoint del túnel
/ip address add address=10.200.200.2/30 interface=wg-cdmx comment="WG tunnel B"

# 4. Agregar el peer (router A) con su clave pública
/interface wireguard peers add interface=wg-cdmx \
  public-key="CLAVE_PUBLICA_DEL_ROUTER_A" \
  endpoint-address=203.0.113.10 endpoint-port=51820 \
  allowed-address=10.200.200.1/32,192.168.10.0/24 \
  persistent-keepalive=25s \
  comment="peer CDMX"

El parámetro allowed-address es clave: define qué rangos de IP pueden enviarse por este túnel. Incluye siempre la IP del endpoint remoto (10.200.200.1/32) y la subred LAN remota (192.168.10.0/24).

El persistent-keepalive=25s es crítico cuando el router B está detrás de NAT: envía un paquete cada 25 segundos para mantener abierta la sesión NAT en el router upstream.

4. Agregar el peer en Router A

Ahora que ya conoces la clave pública del router B, regresa al router A y agrega el peer correspondiente:

# Agregar peer del router B. Sin endpoint porque B inicia la conexión.
/interface wireguard peers add interface=wg-mty \
  public-key="CLAVE_PUBLICA_DEL_ROUTER_B" \
  allowed-address=10.200.200.2/32,192.168.20.0/24 \
  comment="peer MTY"

En este lado no especificamos endpoint-address porque el router B tiene IP dinámica y es quien inicia la conexión. WireGuard aprende el endpoint cuando recibe el primer handshake válido.

5. Rutas entre las LANs

WireGuard no enruta automáticamente las LANs remotas. Debes agregar rutas estáticas que apunten a través del túnel:

# En Router A — ruta hacia la LAN de Monterrey
/ip route add dst-address=192.168.20.0/24 gateway=wg-mty comment="to MTY LAN via WG"

# En Router B — ruta hacia la LAN de CDMX
/ip route add dst-address=192.168.10.0/24 gateway=wg-cdmx comment="to CDMX LAN via WG"

6. Reglas de firewall para permitir tráfico del túnel

Si tienes un firewall estricto (como recomendamos en la guía de firewall MikroTik para ISP), debes permitir explícitamente el tráfico que llega por la interfaz WireGuard hacia tus LANs:

# Router A: permitir tráfico desde el túnel WG hacia la LAN local
/ip firewall filter add chain=forward in-interface=wg-mty src-address=192.168.20.0/24 \
  dst-address=192.168.10.0/24 action=accept comment="allow MTY to CDMX LAN"

/ip firewall filter add chain=forward out-interface=wg-mty src-address=192.168.10.0/24 \
  dst-address=192.168.20.0/24 action=accept comment="allow CDMX to MTY LAN"

# Router B: misma lógica invertida
/ip firewall filter add chain=forward in-interface=wg-cdmx src-address=192.168.10.0/24 \
  dst-address=192.168.20.0/24 action=accept comment="allow CDMX to MTY LAN"

/ip firewall filter add chain=forward out-interface=wg-cdmx src-address=192.168.20.0/24 \
  dst-address=192.168.10.0/24 action=accept comment="allow MTY to CDMX LAN"

7. Verificación y handshake

Después de aplicar la configuración en ambos lados, verifica que el túnel esté activo. Un handshake reciente significa que WireGuard está negociando correctamente:

# Ver estado del peer (debe mostrar last-handshake reciente)
/interface wireguard peers print detail

# Ver contadores de tráfico en la interfaz WG
/interface wireguard print stats

# Ping de prueba desde Router A hacia Router B
/ping 10.200.200.2 count=5

# Ping desde Router A hacia un host en la LAN de B
/ping 192.168.20.1 count=5

# Ver tabla de rutas activas
/ip route print where active

Si el handshake no ocurre, revisa en este orden:

1. Firewall input en el router A — ¿está aceptando UDP 51820?
2. NAT upstream del router B — ¿realmente permite UDP saliente?
3. Claves públicas — ¿copiaste exactamente la clave, sin espacios extra?
4. allowed-address — ¿incluye tanto la IP del endpoint remoto como la LAN?
5. MTU — si el handshake funciona pero el tráfico no pasa, reduce MTU del túnel a 1380 o menos.

8. Troubleshooting común

El handshake ocurre pero no pasa tráfico hacia la LAN

El problema casi siempre es falta de ruta o NAT aplicándose al tráfico del túnel. Verifica que el masquerade de la WAN excluya el destino de la LAN remota.

El túnel cae después de unos minutos

Si el lado cliente (router B) está detrás de NAT y no tiene persistent-keepalive, el NAT upstream cierra la sesión. Agrega persistent-keepalive=25s al peer en el router B.

Paquetes se fragmentan o hay throughput bajo

Reduce el MTU de la interfaz WireGuard. El overhead de WireGuard es ~60 bytes, así que mtu=1420 es seguro sobre la mayoría de las WANs. Si tu proveedor usa PPPoE, baja a mtu=1380.

Error "invalid key format"

Las claves WireGuard son base64 y terminan en =. Si copias y pegas desde un correo o chat, a veces se pierde el = final. Verifica que la clave tenga exactamente 44 caracteres.

Conclusión

Un túnel WireGuard site-to-site en RouterOS 7 se configura en 5 pasos esenciales: crear interfaz, asignar IP, agregar peers con clave pública, crear rutas y abrir firewall. Una vez funciona, es de las VPNs más estables y rápidas que existen en el ecosistema MikroTik.

En MikroHelp usamos WireGuard hub-spoke para administrar más de 30 equipos MikroTik distribuidos en 3 países. El túnel nunca nos ha fallado en producción en los últimos 18 meses de operación continua.