← Volver al blog

WireGuard MikroTik site-to-site: guía RouterOS v7

12 de junio de 2026

WireGuard MikroTik site-to-site: guía RouterOS v7

Si operas una red distribuida —una casa matriz con sucursales, un ISP con nodos remotos o un data center con presencia en terreno— tarde o temprano necesitas unir subredes privadas a través de internet sin exponerlas. Durante años eso significó IPsec: negociaciones IKE frágiles, políticas SA que se caen sin avisar y horas de depuración por un mismatch de propuestas. WireGuard MikroTik cambia esa ecuación. Con un puñado de comandos en RouterOS levantas un túnel cifrado site-to-site estable, con menos superficie de configuración y un rendimiento notablemente mejor. En este artículo veremos cómo diseñar e implementar WireGuard MikroTik en un escenario real de dos oficinas, con los comandos exactos de RouterOS v7 y las consideraciones de firewall que casi siempre se pasan por alto.

Por qué WireGuard MikroTik y no IPsec en un enlace site-to-site

WireGuard es un protocolo VPN moderno que vive en el kernel y usa criptografía fija y opinada (Curve25519, ChaCha20, Poly1305). No hay suites que negociar ni fases que sincronizar: cada extremo tiene un par de llaves y una lista de redes permitidas, y eso es todo. Para un equipo de red esto se traduce en ventajas concretas:

  • Menos estado, menos fallas. No hay SA que expiren ni renegociaciones IKE que dejen el túnel a medias. El handshake es liviano y se reestablece solo.
  • Mejor rendimiento por CPU. En equipos ARM y ARM64 típicos de la línea MikroTik, WireGuard entrega más throughput por ciclo que IPsec sin aceleración por hardware.
  • Configuración auditable. Toda la definición de un peer cabe en una línea: llave pública, endpoint y allowed-address. Es trivial de documentar y revisar.
  • Comportamiento silencioso. WireGuard no responde a paquetes de origen no autenticado, lo que reduce su exposición frente a escaneos.

WireGuard está disponible de forma nativa desde RouterOS v7. Si aún mantienes core o borde sobre v6, este es uno más de los motivos para planificar la migración. Puedes revisar el resto de nuestras soluciones de VPN site-to-site y acceso remoto para decidir qué protocolo encaja con cada tramo de tu red.

El escenario: dos oficinas, dos subredes, un túnel

Trabajemos sobre el caso canónico: dos routers MikroTik, cada uno con salida a internet y una LAN detrás de NAT. La Oficina 1 tiene la subred 10.1.202.0/24 y la Oficina 2 la 10.1.101.0/24. Queremos que ambas LAN se vean entre sí de forma segura. Para direccionar el túnel usaremos una /30 dedicada, 10.255.255.0/30, que no colisiona con ninguna LAN.

ParámetroOficina 1Oficina 2
LAN local10.1.202.0/2410.1.101.0/24
IP del túnel10.255.255.1/3010.255.255.2/30
WAN (endpoint público)192.168.90.1192.168.80.1
Puerto de escucha (UDP)1323113231

Interfaz y peers: el corazón de WireGuard MikroTik

Crear la interfaz en cada router

El primer paso es crear la interfaz WireGuard en ambos extremos. Al crearla, RouterOS genera automáticamente el par de llaves privada y pública. El comando es idéntico en los dos routers:

/interface/wireguard
add listen-port=13231 name=wireguard1

Ahora imprime la interfaz para obtener la llave pública de cada router; es lo único que intercambiarás entre extremos. La llave privada nunca sale del equipo que la generó —de ahí su nombre—.

/interface/wireguard/print
Flags: X - disabled; R - running
 0  R name="wireguard1" mtu=1420 listen-port=13231
      private-key="yKt9NJ4e5qlaSgh48WnPCDCEkDmq+VsBTt/DDEBWfEo="
      public-key="u7gYAg5tkioJDcm3hyS7pm79eADKPs/ZUGON6/fF3iI="

Anota la public-key de la Oficina 1 y la de la Oficina 2. Nota el MTU por defecto de 1420: WireGuard reserva overhead de encapsulación, y respetar ese valor evita fragmentación y los clásicos problemas de "algunas páginas cargan y otras no".

Definir los peers

El peer define quién puede usar el túnel y qué tráfico viaja por él. Aquí está el concepto más importante y el que más errores causa: allowed-address es a la vez control de acceso y tabla de ruteo interna del túnel. Solo se aceptan y envían paquetes cuyas IP de origen/destino calcen con esa lista. En un site-to-site incluyes la LAN remota y la IP del túnel del otro extremo.

En la Oficina 1 apuntamos al peer de la Oficina 2 (su llave pública, su endpoint público y las redes que alcanzaremos a través de él):

/interface/wireguard/peers
add interface=wireguard1 \
    public-key="v/oIzPyFm1FPHrqhytZgsKjU7mUToQHLrW+Tb5e601M=" \
    endpoint-address=192.168.80.1 endpoint-port=13231 \
    allowed-address=10.1.101.0/24,10.255.255.2/32

Y en la Oficina 2, el peer espejo hacia la Oficina 1:

/interface/wireguard/peers
add interface=wireguard1 \
    public-key="u7gYAg5tkioJDcm3hyS7pm79eADKPs/ZUGON6/fF3iI=" \
    endpoint-address=192.168.90.1 endpoint-port=13231 \
    allowed-address=10.1.202.0/24,10.255.255.1/32

Dos propiedades del peer que vale la pena conocer para escenarios reales:

  • persistent-keepalive: si uno o ambos routers están detrás de NAT y no tienen IP pública fija de cara al túnel, fija este valor (por ejemplo 25s) para que el mapeo NAT se mantenga vivo y el túnel no se "duerma".
  • preshared-key: agrega una capa simétrica opcional sobre la criptografía asimétrica, un endurecimiento extra de cara a un futuro con cómputo cuántico. Debe coincidir en ambos peers.

Direccionamiento, ruteo y verificación del túnel

La interfaz ya existe y los peers se conocen, pero falta decirle a RouterOS cómo llegar a la LAN remota. Asignamos la IP del túnel y agregamos la ruta hacia la subred del otro lado.

Oficina 1:

/ip/address
add address=10.255.255.1/30 interface=wireguard1
/ip/route
add dst-address=10.1.101.0/24 gateway=wireguard1

Oficina 2:

/ip/address
add address=10.255.255.2/30 interface=wireguard1
/ip/route
add dst-address=10.1.202.0/24 gateway=wireguard1

Para verificar que el túnel está vivo, imprime los peers y revisa last-handshake: si muestra un valor de pocos segundos y los contadores rx/tx crecen, el enlace está negociando y transportando tráfico. Un last-handshake que nunca aparece casi siempre apunta a firewall o a una llave pública mal copiada. Si el túnel levanta pero el tráfico no cruza, el problema está en el ruteo o en las reglas de forward, no en WireGuard; nuestro equipo de soporte MikroTik resuelve a diario ese tipo de diagnóstico sobre redes en producción.

Firewall: el paso que rompe el túnel si se omite

El firewall por defecto de RouterOS bloqueará el establecimiento del túnel. Hay que aceptar el tráfico WireGuard en la cadena input antes de cualquier regla de drop, en ambos routers. WireGuard viaja sobre UDP en el puerto que definiste como listen-port:

# Oficina 1
/ip/firewall/filter
add action=accept chain=input protocol=udp dst-port=13231 \
    src-address=192.168.80.1

# Oficina 2
/ip/firewall/filter
add action=accept chain=input protocol=udp dst-port=13231 \
    src-address=192.168.90.1

Además, la cadena forward suele restringir la comunicación entre subredes. Hay que permitir explícitamente el tráfico entre ambas LAN, antes de las reglas de descarte:

# Oficina 1
/ip/firewall/filter
add action=accept chain=forward src-address=10.1.202.0/24 dst-address=10.1.101.0/24
add action=accept chain=forward src-address=10.1.101.0/24 dst-address=10.1.202.0/24

Este es el punto donde más túneles "que deberían funcionar" fallan. Si diseñas políticas de firewall estrictas —como corresponde en una red de producción— conviene integrar estas reglas dentro de tu esquema general y no como parches sueltos. Ten presente además el orden: en RouterOS las reglas se evalúan de arriba hacia abajo, así que estas aceptaciones deben quedar por sobre cualquier drop genérico de la cadena. Si tu router ya tiene un ruleset maduro, revisa nuestra guía de firewall RouterOS para ubicar correctamente las reglas de aceptación en el orden de la cadena.

Buenas prácticas para producción y próximos pasos

El laboratorio funciona con lo anterior; una red que opera 24/7 pide algunos cuidados adicionales:

  • Cuida el allowed-address. Es tu límite real de blast radius. No pongas 0.0.0.0/0 en un site-to-site salvo que quieras enrutar todo el tráfico del sitio remoto por el túnel; limítalo a las subredes que de verdad deben cruzarse.
  • Endpoints dinámicos. Si un extremo no tiene IP pública fija, combina WireGuard con un DNS dinámico y persistent-keepalive; el peer con IP estable actúa como responder y el otro inicia el handshake.
  • Documenta las llaves y los peers. Guarda qué llave pública corresponde a qué sitio. Rotar una llave comprometida es trivial, pero solo si sabes dónde está desplegada.
  • MTU y MSS. Mantén el MTU de 1420 y, si ves conexiones que cuelgan bajo carga, evalúa un ajuste de MSS clamping en el forward para tráfico TCP.
  • Malla de más de dos sitios. WireGuard escala a topologías hub-and-spoke o full-mesh agregando peers; cada nuevo sitio suma su llave pública y su rango en allowed-address, sin renegociar nada de lo existente.

WireGuard MikroTik resuelve la enorme mayoría de los enlaces site-to-site con una elegancia que IPsec rara vez alcanza, pero el diseño correcto —segmentación, políticas de firewall, ruteo entre múltiples sitios y coexistencia con enlaces existentes— es lo que separa un túnel de laboratorio de una VPN de misión crítica. En MikroTik Chile diseñamos, implementamos y operamos redes seguras sobre RouterOS para empresas e ISP, con equipo certificado y enfoque en estabilidad documentada. Si estás evaluando llevar WireGuard a producción o migrar tus túneles IPsec, conversemos sobre tu topología con nuestro equipo de consultoría y revisemos tu caso en concreto.

Conversemos