MANUAL: Mikrotik, WireGuard VPN a fondo (RW + STS)

Introducción​

Después del aperitivo de montar esto en un router secundario que tenía funcionando como switch (o AP, lo mismo me da), ahora que la v7.1 está entre nosotros (como testing-cuasi-estable), vamos a meternos de lleno con la configuración de WireGuard, usando para ello nuestros routers principales.

Manos a la obra​

Vamos a plantear los dos tipos de setup más comunes que vamos a encontrar para una VPN, mas uno de regalo que a más de uno le va a gustar. Configuraremos tres interfaces WireGuard en el router HQ con este manual:
  • Servidor WireGuard para road warriors (clientes que se conectan desde cualquier sitio)
  • Servidor WireGuard para un site-to-site (unir dos o más sedes)
  • Servidor WireGuard para montar un túnel, sobre el que montar luego EoIP (tunel in tunel)

WireGuard: Modo Road Warrior​

Este setup está prácticamente explicado en el post anterior, con la salvedad de que ahora lo vamos a montar en nuestro router principal. Para ello, simplemente crearemos una nueva interfaz WireGuard, elegiremos un segmento cualquier para la VPN de este tipo, y daremos de alta un peer para que conecte (segundo y siguientes serían idénticos). Vamos al lío:

Creamos la interfaz, en un puerto cualquiera
Código:
/interface wireguard
add listen-port=12345 name=wireguard-rw

Elegimos un segmento de red para estos clientes, por ejemplo el 192.168.50.1/24, y lo asignamos a dicha interfaz.
Código:
/ip address
add address=192.168.50.1/24 interface=wireguard-rw

Damos de alta un peer con la dirección 192.168.50.2/32, indicando su clave pública (traída del servidor del otro extremo, del cliente que se va a conectar)
Código:
/interface wireguard peers
add allowed-address=192.168.50.2/32 comment=PeerRW interface=wireguard-rw \
    public-key="0dpuMJZ2Tlpji8ywc/OjupVvKOVxxI00Sn4d7fAkLWc="

Aceptamos el tráfico en input para el puerto seleccionado en la interfaz (si tenéis la config por defecto, el place-before la dejará donde toca, sino, moverla donde corresponda, antes de las reglas de drop generales que tengáis en input)
Código:
/ip firewall filter
add action=accept chain=input comment="vpn: allow wireguard-rw" \
    dst-port=12345 protocol=udp \
    place-before [find comment="defconf: drop all not coming from LAN"]

OPCIONAL: Si queréis que los clientes RW accedan al propio router. Dos maneras, o metéis la interfaz WireGuard en la lista LAN (no le afectará la regla de input que tira el tráfico que no venga de la lista LAN) o creáis una nueva regla de input que acepte el tráfico de la subred road warrior o de la IP concreta que queráis permitir llegar al propio router
Código:
# Usando la lista LAN
/interface list member
add interface=wireguard-rw list=LAN

# Usando una regla de input
/ip firewall filter
add chain=input src-address=192.168.50.0/24 action=accept \
    place-before [find comment="defconf: drop all not coming from LAN"]

OPCIONAL: Restringir que el tráfico de los RW sólo acceda a internet, y a nada más en nuestra red. En este caso, haríamos lo mismo que hacemos con las redes de invitados, caparlas en forward, de la siguiente manera:
Código:
/ip firewall filter
add action=drop chain=forward comment="VPN: block road warriors to have only internet" \
    out-interface-list=!WAN src-address=192.168.50.0/24

Ejemplo de configuración de un cliente cualquiera en modo RW

Móvil (iPhone, app oficial para WireGuard)
1638643357798.png


Portátil (Mac, app oficial para WireGuard), mismo ejemplo:
1638643755594.png


WireGuard: Modo Site to Site​

En este modo, uniremos dos routers mikrotik que tengan la V7 corriendo, y permitiremos el acceso de la LAN de ambos equipos desde el otro extremo. Para ello, en cada extremo, manejaremos dos segmentos de red bien diferenciados
  • Segmento de red local (normalmente un /24). Suponemos A tiene la 192.168.88.0/24 y B tiene la 192.168.77.0/24
  • Segmento del túnel (al ser un túnel punto a punto, usaremos direcciones /30). Usaremos estas dos, por ejemplo: 172.16.1.1/30 en A y 172.16.1.2/30 en B
Para el ejemplo, suponemos que tenemos IP -> Cloud corriendo en ambos extremos, y que las direcciones públicas se resuelven a partir del DDNS propio de mikrotik, siendo serialA.sn.mynetname.net el del extremo A, y serialB.sn.mynetname.net el del extremo B. Con estas consideraciones, tendríamos

Configuración en A
Creamos la interfaz del servidor A (puerto a elegir, pongo uno sucesivo al anterior, por si queréis probar los tres túneles de un golpe)
Código:
/interface wireguard
add listen-port=12346 name=wireguard-sts

Nos apuntamos la IP pública de A, para crear el peer en B (con este comando lo imprimís por terminal)
Código:
:put [/interface/wireguard/get [find name=wireguard-sts] public-key]

Configuración en B
Creamos la interfaz del servidor en B
Código:
/interface wireguard
add listen-port=12346 name=wireguard-sts

Nos apuntamos la IP pública de B, para crear el peer en A (con este comando lo imprimís por terminal)
Código:
:put [/interface/wireguard/get [find name=wireguard-sts] public-key]

Resto de configuración en A
Asignamos la IP /30 sobre la interfaz wireguard-sts
Código:
/ip address
add address=172.16.1.1/30 interface=wireguard-sts

Cremos una ruta estática para decirle a A que el segmento LAN de B se encuentra al otro lado del túnel, por la IP del otro extremo, la .2
Código:
/ip route
add dst-address=192.168.77.0/24 gateway=172.16.1.2

Crearemos el peer que representa al otro extremo en A, con la clave pública de B. Permitiremos el tráfico tanto de la IP .2/30 del otro extremo, como del segmento LAN de B. Nos quedaría algo así:
Código:
/interface wireguard peers
add allowed-address=172.16.1.2/32,192.168.77.0/24 interface=wireguard-sts \
    public-key="PUBLIC_KEY_FROM_B" \
    endpoint-address=serialB.sn.mynetname.net endpoint-port=12346

Aceptaremos el tráfico en input del puerto 12346, que hemos usado para el servidor de este ejemplo
Código:
/ip firewall filter
add action=accept chain=input comment="vpn: allow wireguard-sts" \
    dst-port=12346 protocol=udp \
    place-before [find comment="defconf: drop all not coming from LAN"]


Resto de configuración en B (Idéntica a A, pero con los términos invertidos)
Asignamos la IP /30 sobre la interfaz wireguard-sts
Código:
/ip address
add address=172.16.1.2/30 interface=wireguard-sts

Cremos una ruta estática para decirle a B que el segmento LAN de A se encuentra al otro lado del túnel, por la IP del otro extremo, la .1
Código:
/ip route
add dst-address=192.168.88.0/24 gateway=172.16.1.1

Crearemos el peer que representa al otro extremo en B, con la clave pública de A. Permitiremos el tráfico tanto de la IP .1/32 del otro extremo del túnel, como del segmento LAN de B. Nos quedaría algo así:
Código:
/interface wireguard peers
add allowed-address=172.16.1.1/32,192.168.88.0/24 interface=wireguard-sts \
    public-key="PUBLIC_KEY_FROM_A" \
    endpoint-address=serialA.sn.mynetname.net endpoint-port=12346

Aceptaremos el tráfico en input del puerto 12346, que hemos usado para el servidor de este ejemplo
Código:
/ip firewall filter
add action=accept chain=input comment="vpn: allow wireguard-sts" \
    dst-port=12346 protocol=udp \
    place-before [find comment="defconf: drop all not coming from LAN"]

Y con esto y un bizcocho, si lo hemos hecho bien, tendremos ambas sedes unidas por un túnel WireGuard, enrutando las redes LAN de ambos extremos, mientras el resto del tráfico local y la salida a internet se queda en cada sitio. Además, al tener ambos peers configurado el endpoint del otro extremo, da igual qué extremo se venga abajo, cualquiera de los dos será capaz de reconectar el túnel

NOTA MUY IMPORTANTE: para los que vengan de IKEv2 site-to-site
Me he vuelto mico intentando hacer hoy este setup, puesto que lo estaba montando sobre dos routers que previamente estaban unidos usando IKEv2 en modo site to site. Aunque la conexión no esté levantada, las policy templates siguen funcionando, y hacen que sea imposible comunicar ambas LAN (puedes hacer ping desde el router, pero no desde un equipo de la LAN de un extremo a un equipo de la LAN del otro extremo. Conforme borras las policy templates, el tema empieza a fluir como por arte de magia. Me he dado cuenta al ver que, si enmascaraba el tráfico de la interfaz WireGuard de A, sí que llegaba a los equipos de B, cosa que es innecesaria en este tipo de VPN. Así que no hagáis como yo, si vais a montar esto, desmontar antes IKEv2 site-to-site


BONUS! - WireGuard Site to Site + EoIP

Como habréis podido intuir, montar lo anterior pero poniéndole encima un túnel EoIP es de lo más trivial. Recordemos que, para montar un túnel EoIP, todo lo que necesitamos son IP's locales de ambos extremos, las cuales ya tenemos con los esas IP's /30 que hemos definido antes (usaremos 172.16.0.1/30 y 172.16.0.2/30 en lugar de las de antes) Hecho eso, todo lo que necesitamos es crear ambos túneles EoIP en ambos extremos, añadir esa nueva interfaz EoIP al que sea el bridge donde queremos propagar el dominio de broadcast, y listo. Para este ejemplo vamos a partir de la misma configuración que el site to site, pero en A vamos a meter el EoIP en el bridge principal, y en B vamos a crear un bridge nuevo con el EoIP y un puerto dedicado, por ejemplo, ether5. Así, en B, los puertos del 2 al 4 se comportarán como venían haciendo hasta ahora (obteniendo una IP del segmento de .77 de su LAN) y el puerto 5 obtendrá una IP .88 del mismo dominio de broadcast que hay en A. En este caso, como el túnel sólo lo vamos a montar para eso, omitimos la parte de las rutas estáticas, puesto que la LAN no la vamos a enrutar en esta ocasión, la vamos a tele-transportar directamente.

Configuración en A
Creamos la interfaz del servidor A (puerto a elegir, pongo uno sucesivo al anterior, por si queréis probar los tres túneles de un golpe)
Código:
/interface wireguard
add listen-port=12347 name=wireguard-sts-eoip

Nos apuntamos la IP pública de A, para crear el peer en B (con este comando lo imprimís por terminal)
Código:
:put [/interface/wireguard/get [find name=wireguard-sts-eoip] public-key]

Configuración en B
Creamos la interfaz del servidor en B
Código:
/interface wireguard
add listen-port=12347 name=wireguard-sts-eoip

Nos apuntamos la IP pública de B, para crear el peer en A (con este comando lo imprimís por terminal)
Código:
:put [/interface/wireguard/get [find name=wireguard-sts-eoip] public-key]

Resto de configuración en A
Asignamos la IP /30 sobre la interfaz wireguard-sts-eoip
Código:
/ip address
add address=172.16.0.1/30 interface=wireguard-sts-eoip

Crearemos el peer que representa al otro extremo en A, con la clave pública de B. Permitiremos el tráfico tanto de la IP .2/30 del otro extremo, como del segmento LAN de B. Nos quedaría algo así:
Código:
/interface wireguard peers
add allowed-address=172.16.0.2/32 interface=wireguard-sts-eoip \
    public-key="PUBLIC_KEY_FROM_B" \
    endpoint-address=serialB.sn.mynetname.net endpoint-port=12347

Aceptaremos el tráfico en input del puerto 12347, que hemos usado para el servidor de este ejemplo
Código:
/ip firewall filter
add action=accept chain=input comment="vpn: allow wireguard-sts-eoip" \
    dst-port=12347 protocol=udp \
    place-before [find comment="defconf: drop all not coming from LAN"]

Creamos un nuevo túnel EoIP en A, con ip local la .1 y remota la .2 de los segmentos usados para el túnel
Código:
/interface eoip
add local-address=172.16.0.1 name=eoip-tunnel-over-wg-sts \
   remote-address=172.16.0.2 tunnel-id=0

Añadimos dicho túnel al bridge principal que tengamos ya corriendo en A (supongo un único bridge, llamado "bridge")
Código:
/interface bridge port
add bridge=bridge interface=eoip-tunnel-over-wg-sts


Resto de configuración en B (Idéntica a A, pero con los términos invertidos)
Asignamos la IP /30 sobre la interfaz wireguard-sts
Código:
/ip address
add address=172.16.0.2/30 interface=wireguard-sts-eoip

Crearemos el peer que representa al otro extremo en B, con la clave pública de A. Permitiremos el tráfico únicamente de la IP .1/32
Código:
/interface wireguard peers
add allowed-address=172.16.0.1/32 interface=wireguard-sts-eoip \
    public-key="PUBLIC_KEY_FROM_A" \
    endpoint-address=serialA.sn.mynetname.net endpoint-port=12347

Aceptaremos el tráfico en input del puerto 12347, que hemos usado para el servidor de este ejemplo
Código:
/ip firewall filter
add action=accept chain=input comment="vpn: allow wireguard-sts" \
    dst-port=12347 protocol=udp \
    place-before [find comment="defconf: drop all not coming from LAN"]

Creamos un nuevo túnel EoIP, con las IP's del extremo de los túneles (local en B la .2, remote la .1, a la inversa que antes)
Código:
/interface eoip
add local-address=172.16.0.2 name=eoip-tunnel-over-wg-sts \
    remote-address=172.16.0.1 tunnel-id=0

Sacamos la interfaz "ether5" en B del bridge principal, para después meterla en el nuevo bridge. Supongo que el bridge principal se llama "bridge"
Código:
interface bridge port remove [find where interface=ether5 and bridge=bridge]

Creamos un nuevo bridge y añadimos en él la interfaz EoIP y el puerto 5 que recién hemos sacado del bridge principal. Metemos también el EoIP en el mismo nuevo bridge
Código:
/interface bridge
add name=bridge-eoip-from-a
/interface bridge port
add bridge=bridge-eoip-from-a interface=ether5
add bridge=bridge-eoip-from-a interface=eoip-tunnel-over-wg-sts

Y, con esto y un bizcocho, si conectamos un equipo a ether5, deberíamos obtener una IP del segmento 192.168.88.0/24 del router principal.

Espero que os guste el manual, tenía muchas ganas de montarlo, y ahora que la RouterOS v7 es una realidad, era casi una obligación.

Saludos, y que lo disfrutéis!
 
Última edición:
Excelente!!! @pokoyo

Gracias x todos tus aportes!!! Y la ayuda q das incondicionalmente a todos lo q siempre tenemos dudas en este maravilloso mundo de MK.

Sldos
 
Impresionante manual que te has montado, muchas gracias por tu colaboración y por contagiarnos tu entusiasmo @pokoyo !!

Estoy muy contento con IKEv2 pero veo que las posibilidades que ofrece Wireguard y es una pasada!

Ya lo tenía funcionando en una NAS con MV de ubuntu server (gracias a @huzoaaz) y va super rápido. Anoche lo configuré en el RB4011 y lo probé con un par de móviles (Android) y también va muy bien. Más adelante lo probaré con mi segunda vivienda a ver que tal.

S@lu2.
 
Impresionante manual que te has montado, muchas gracias por tu colaboración y por contagiarnos tu entusiasmo @pokoyo !!

Estoy muy contento con IKEv2 pero veo que las posibilidades que ofrece Wireguard y es una pasada!

Ya lo tenía funcionando en una NAS con MV de ubuntu server (gracias a @huzoaaz) y va super rápido. Anoche lo configuré en el RB4011 y lo probé con un par de móviles (Android) y también va muy bien. Más adelante lo probaré con mi segunda vivienda a ver que tal.

S@lu2.

Yo ya lo he pasado el Wireguard server al Mikrotik… y de momento he deshabilitado la VM que usaba en el NAS… Así le doy algo de respiro….

Y decir que va de lujo… configurado en el iphone y dos portátiles y va genial…. Dejaré el del Synology de por si acaso tengo que tirar de el y listo…
 
Yo ya lo he pasado el Wireguard server al Mikrotik… y de momento he deshabilitado la VM que usaba en el NAS… Así le doy algo de respiro….

Y decir que va de lujo… configurado en el iphone y dos portátiles y va genial…. Dejaré el del Synology de por si acaso tengo que tirar de el y listo…
Y el Pihole? Lo sigues teniendo en la MV?

S@lu2
 
Gracias @pokoyo .
Estupendo manual y muy didáctico. Será de gran utilidad para muchos. Muy bien explicados los tres ejemplos. Completísimo.
Gracias por tu tiempo y dedicación.
 
Si tienes un nas synology compatible con Docker, te aconsejo que el pi-hole lo metas por docker….. yo lo tengo en un contenedor y asignados 256 mb de ram (y creo q con menos funcionaria tb) y va de lujo…

Si te interesa, creo q hice un manual de los pasos a seguir…. Ya me dirás…
Yo tengo Adguard y también funciona perfecto; en docker y Synology. Antes tenia pihole y también funcionaba bien. En docker come menos recursos que en vm....
 
Y adguard mejor q pihole?

Yo no he visto muchas diferencias tangibles, pero no soy experto. Pero me gustó más, sobretodo pq se puede controlar muy bien y cómodamente, sobre la marcha, con home assistant. Con un docker, en 10mim lo tienes funcionando, si no te convence lo borras. A mi me convenció... :)
 
Guay, cuando me ponga ya os pido consejo. Quise utilizar Docker en su momento pero no pude en NAS Synology.

S@lu2


Enviado desde mi M2007J17G mediante Tapatalk
 
Guay, cuando me ponga ya os pido consejo. Quise utilizar Docker en su momento pero no pude en NAS Synology.

S@lu2


Enviado desde mi M2007J17G mediante Tapatalk

Que modelo tienes? Lo más “básico” compatible tiene que ser de la serie plus… si no, olvidate…

Pongo “básico” entre comillas porque los plus ya son la gama potente, partiendo de configuraciones con 2gb de ram en adelante y procesadores potentes también…
 
@pokoyo, como siempre, mil gracias por tus aportes y "curradas".

En cuanto monte v7 en el 4011, me animo a probar a ver qué tal va este túnel. Temo tener problemas con la config de IPTV de movistar al pasar a v7.


Saludos!
 
@pokoyo, como siempre, mil gracias por tus aportes y "curradas".

En cuanto monte v7 en el 4011, me animo a probar a ver qué tal va este túnel. Temo tener problemas con la config de IPTV de movistar al pasar a v7.


Saludos!
Alguno se tiene que animar, que sino no vamos a sacar la config de iptv para la V7 nunca!

Saludos!
 
Sencillamente brutal!! Muchas gracias @pokoyo. Yo de hecho le tengo que montar algo de esto a mi router de vacaciones (hAP mini). Lo tenía con un tunel EoIP, pero no se yo si la opción de Wireguard site-to-site, o la site-to-site EoIP puede ir mejor... A ver si le doy una vueltecilla :)
 
Arriba