Wireguard + VLANs

Lo prometido es deuda @pokoyo !

Me está molando mucho esto y aprendiendo poco a poco. Así que después de leer bastante, me dispongo a proponer lo que tengo pensado para mi red en casa, para ver si me puedes llevar un poco de la mano y dejarlo funcionando con una configuración limpia.

Empiezo con los equipos involucrados y disponibles en mi setup:
- Router Mikrotik RB5009
- Switch gestionable 24 tomas Netgear JGS524PE
- Switch no gestionable industrial de 8 tomas, instalado dentro de un cuadro eléctrico/domótico.
- 2 APs Unifi U6 Pro

Dejo aquí un gráfico de la red que persigo, y algunas tablas con información de los puertos y VLANs.

1673133015472.png


1. El paso número 1 sería montar Wireguard, para poder acceder de forma remota a la configuración del Router y a mi red.

2. Propongo 4 VLANs, además de la subred para Wireguard:
- Admin -> VLAN10: 192.168.10.0/24
- LAN -> VLAN20: 192.168.20.0/24. -> WLAN 2.4/5 GHz asociada en U6 Pro (Home-General)
- IoT -> VLAN30: 192.168.30.0/24. -> WLAN 2.4 GHz asociada en U6 Pro (Home-Domo)
- Invitados-> VLAN40: 192.168.40.0/24. -> WLAN 2.4 GHz asociada en U6 Pro (Home-Invitados)
- Wireguard -> 192.168.90.0/24

3. La VLAN "Admin" me gustaría usarla para reunir la gestión de los distintos dispositivos que controlan la red (Router, Switch, Servidor + APs). Sin embargo, me gustaría aclarar si al tener que activar el "Bridge VLAN filtering", puedo ahorrarme esta VLAN y usar la VLAN 1 que se activa por defecto para este propósito, ya que todos los puertos irán asociados al menos a una VLAN.

4. Tema de accesos para cada VLAN/subred y comunicaciones entre ellas:
- LAN -> Acceso a Internet + comunicación con VLANs/subredes: IoT, Admin, Wireguard
- IoT -> Solo acceso a Internet
- Invitados-> Solo acceso a Internet
- Wireguard -> Acceso a Internet + comunicación con VLANs: LAN, Admin, IoT

5. Extra de seguridad a la config de invitados, impidiendo que los equipos accedan a la red si se ponen IP estática a mano, e impidiendo también ninguna comunicación en capa 2 con IPs /32 en el DHCP.

6. En el servidor que montaré (aún no lo tengo), irá un Proxmox con lo siguiente:
- VM Home Assistant -> VLAN30 (IoT)
- VM Pi-Hole -> VLAN20 (LAN)
- VM Linux -> Instalaré docker, y con "macvlans" taggaré cada Docker a la VLAN correspondiente.

7. Al ETH3 del router RB5009, tengo conectado un switch industrial de 8 puertos, que tiene conectado lo siguiente:
- 5 dispositivos domóticos conectados por cable -> VLAN30 (IoT)
- Me quedan 2 puertos libres, aunque es bastante posible que en uno de ellos conecte un AP simple de 2.4GHz, por si la señal WiFi no llega bien al interior del cuadro eléctrico por la puerta metálica.

Y en principio, esto es todo. Seguro que me ha dejado algo, pero irá saliendo a lo largo del diseño seguro.
La configuración de VLANs en el router gestionable la tengo controlada.
¿Hay algún error de base que no se pueda hacer o que no sea recomendable tal y como lo he planteado?

Por otro lado, como ya te comenté, no vivo aún allí, por lo que lo ideal sería montar Wireguard y configurar las VLANs en el switch lo primero de todo, de modo que el resto pueda hacerlo de forma remota desde mi domicilio actual.

Un saludo y muchísimas gracias por adelantado.
 
Empiezo con los equipos involucrados y disponibles en mi setup:
- Router Mikrotik RB5009
- Switch gestionable 24 tomas Netgear JGS524PE
- Switch no gestionable industrial de 8 tomas, instalado dentro de un cuadro eléctrico/domótico.
- 2 APs Unifi U6 Pro
Buenos equipos, vas a lo grande.

1. El paso número 1 sería montar Wireguard, para poder acceder de forma remota a la configuración del Router y a mi red.
Correcto. Tienes un manual para ello, este: https://www.adslzone.net/foro/mikrotik.199/manual-mikrotik-wireguard-vpn-fondo-rw-sts.579540/
Inténtalo, y si te atascas, me dices.

2. Propongo 4 VLANs, además de la subred para Wireguard:
- Admin -> VLAN10: 192.168.10.0/24
- LAN -> VLAN20: 192.168.20.0/24. -> WLAN 2.4/5 GHz asociada en U6 Pro (Home-General)
- IoT -> VLAN30: 192.168.30.0/24. -> WLAN 2.4 GHz asociada en U6 Pro (Home-Domo)
- Invitados-> VLAN40: 192.168.40.0/24. -> WLAN 2.4 GHz asociada en U6 Pro (Home-Invitados)
- Wireguard -> 192.168.90.0/24
OK. Yo intentaría usar VLANs que no use ningún operador español conocido (como la vlan 20). Pero si tienes claro que de Movistar/O2 no te mueven, adelante.

3. La VLAN "Admin" me gustaría usarla para reunir la gestión de los distintos dispositivos que controlan la red (Router, Switch, Servidor + APs). Sin embargo, me gustaría aclarar si al tener que activar el "Bridge VLAN filtering", puedo ahorrarme esta VLAN y usar la VLAN 1 que se activa por defecto para este propósito, ya que todos los puertos irán asociados al menos a una VLAN.
Hazte la siguiente pregunta, ¿desde dónde vas a querer acceder a los cacharrros? Si la respuesta es desde ninguna VLAN salvo la VLAN "Admin", esta subred está perfectamente como está planteada. Sería la que usarías para enlazar la infraestructura entre sí, además de la que usarías para acceder a ella cuando estés insitu.
Si en algún momento se te pasa por la cabeza acceder desde la "LAN", esa vlan sobra, y consideraríamos la otra tu VLAN "base", desde la que vas a querer gestionarlo todo. Piénsatelo muy bien porque el cambio no es grande, pero sí es tedioso: si restringes a acceder a la infraestructura desde una única VLAN, vas a necesitar un puerto del router dedicado a ello y/o un SSID más en los APs. Es un setup mucho más seguro pero, como digo, también más tedioso. Si por el contrario quieres que desde tu LAN se llegue a todo, esa VLAN la borraríamos, y consideraríamos la VLAN 20 como la que interconecta todo y te da acceso a ti, el "fucking master del universo".

4. Tema de accesos para cada VLAN/subred y comunicaciones entre ellas:
- LAN -> Acceso a Internet + comunicación con VLANs/subredes: IoT, Admin, Wireguard
- IoT -> Solo acceso a Internet
- Invitados-> Solo acceso a Internet
- Wireguard -> Acceso a Internet + comunicación con VLANs: LAN, Admin, IoT
OK.

5. Extra de seguridad a la config de invitados, impidiendo que los equipos accedan a la red si se ponen IP estática a mano, e impidiendo también ninguna comunicación en capa 2 con IPs /32 en el DHCP.
OK. Esto únicamente implica un par de cambios: la vlan de invitados va con "arp=reply-only", y en el DHCP Server, entregas esa opción con "add-arp=yes". Para que las IPs vayan con formato /32 y no tengan broadcast alguno, es tan sencillo como editar el "network" de esa subred en el servidor DHCP y ponerles el campo "netmask=32".

6. En el servidor que montaré (aún no lo tengo), irá un Proxmox con lo siguiente:
- VM Home Assistant -> VLAN30 (IoT)
- VM Pi-Hole -> VLAN20 (LAN)
- VM Linux -> Instalaré docker, y con "macvlans" taggaré cada Docker a la VLAN correspondiente.
OK. No conozco macvlans, pero me el setup.

7. Al ETH3 del router RB5009, tengo conectado un switch industrial de 8 puertos, que tiene conectado lo siguiente:
- 5 dispositivos domóticos conectados por cable -> VLAN30 (IoT)
- Me quedan 2 puertos libres, aunque es bastante posible que en uno de ellos conecte un AP simple de 2.4GHz, por si la señal WiFi no llega bien al interior del cuadro eléctrico por la puerta metálica.
Ese switch, al no ser gestionable, no llevaría trunk, como tienes en tu tabla. Sino que sería un acceso de la VLAN de IOT. No obstante, podrías mandarle tráfico trunk si quisieras (otra vlan distinta taggeada), si por ejemplo quisieras que esa otra VLAN llegase al AP. Si tanto en el AP como en el switch sólo va a existir tráfico IOT, sería en modo acceso y listo, sin más.

Y en principio, esto es todo. Seguro que me ha dejado algo, pero irá saliendo a lo largo del diseño seguro.
La configuración de VLANs en el router gestionable la tengo controlada.
¿Hay algún error de base que no se pueda hacer o que no sea recomendable tal y como lo he planteado?
Un planteamiento alternativo. ¿Por qué no conectar todo al switch de 24 puertos, y sacar las VLANs desde ahí? Te ahorrarías el vlan filtering del bridge en el router, donde sus puertos serían todos independientes. No obstante, es una simple apreciación, se puede montar perfectamente como lo tienes planteado. Lo único que tienes mal es el "trunk" del switch no gestionable, eso sería un puerto de acceso, no trunk.

Por otro lado, como ya te comenté, no vivo aún allí, por lo que lo ideal sería montar Wireguard y configurar las VLANs en el switch lo primero de todo, de modo que el resto pueda hacerlo de forma remota desde mi domicilio actual.
Mándame la interfaz del switch a ver si la conozco. El modelo no lo he manejado, pero sí algún otro swtich de netgear. Sino, tiraremos de la documentación online y listo. El cambio más grande a hacer en el switch es la VLAN de administración que, dependiendo de con qué opción de las planteadas al principio te quedes, habrá que configurarlo de una manera o de otra. Y ese es el que debes configurar en local antes de llevártelo al sitio, porque es muy probable que haciendo un cambio remoto te quedes sin acceso a él.
Y, por descontando, no uses la VLAN1 (vlan por defecto) para nada. Todo el tráfico en su vlan y el el router con ingress filtering, no queremos que ningúna vlan salte por puertos que no le corresponden.

Empieza por wireguard y, cuando lo tengas funcionando, seguimos con las VLANs.

Saludos!
 
Correcto. Tienes un manual para ello, este: https://www.adslzone.net/foro/mikrotik.199/manual-mikrotik-wireguard-vpn-fondo-rw-sts.579540/
Inténtalo, y si te atascas, me dices.
Ok, seguiré ese manual y lo intento echar a andar. Si hay algún problema, te comento, pero espero que no!

OK. Yo intentaría usar VLANs que no use ningún operador español conocido (como la vlan 20). Pero si tienes claro que de Movistar/O2 no te mueven, adelante.
Sin problema, no uso el ID 20. Puedo usar 30, 40, 50, 60 y 90 para Wireguard.

Hazte la siguiente pregunta, ¿desde dónde vas a querer acceder a los cacharrros? Si la respuesta es desde ninguna VLAN salvo la VLAN "Admin", esta subred está perfectamente como está planteada. Sería la que usarías para enlazar la infraestructura entre sí, además de la que usarías para acceder a ella cuando estés insitu.
Si en algún momento se te pasa por la cabeza acceder desde la "LAN", esa vlan sobra, y consideraríamos la otra tu VLAN "base", desde la que vas a querer gestionarlo todo. Piénsatelo muy bien porque el cambio no es grande, pero sí es tedioso: si restringes a acceder a la infraestructura desde una única VLAN, vas a necesitar un puerto del router dedicado a ello y/o un SSID más en los APs. Es un setup mucho más seguro pero, como digo, también más tedioso. Si por el contrario quieres que desde tu LAN se llegue a todo, esa VLAN la borraríamos, y consideraríamos la VLAN 20 como la que interconecta todo y te da acceso a ti, el "fucking master del universo".
Realmente sí que me gustaría acceder a la configuración de los dispositivos desde LAN, o al menos, desde algún dispositivo especifico conectado a dicha red (mi portátil por ejemplo). El hecho de dedicar un puerto del Router solo para la VLAN Admin, y tener que crear un SSID adicional solo para este propósito, no le veo mucho sentido. Las opciones que veo son mantener esa VLAN Admin, permitiéndole acceso solo a LAN (o algún dispositivo concreto de dicha VLAN), o elimina directamente es VLAN e incluirlo la gestión en LAN, perdiendo un poco de limpieza, organización y seguridad.

OK. Esto únicamente implica un par de cambios: la vlan de invitados va con "arp=reply-only", y en el DHCP Server, entregas esa opción con "add-arp=yes". Para que las IPs vayan con formato /32 y no tengan broadcast alguno, es tan sencillo como editar el "network" de esa subred en el servidor DHCP y ponerles el campo "netmask=32".
No lo he entendido muy bien, pero se podrá mirar como detalle adicional una vez esté montado todo.

OK. No conozco macvlans, pero me el setup.
Yo no conocía macvlan, pero parece sencillo y muy versátil, ya que permite tener IPs especificas para cada contenedor, ahorrándote asi posibles problemas de conflicto de puertos.

Ese switch, al no ser gestionable, no llevaría trunk, como tienes en tu tabla. Sino que sería un acceso de la VLAN de IOT. No obstante, podrías mandarle tráfico trunk si quisieras (otra vlan distinta taggeada), si por ejemplo quisieras que esa otra VLAN llegase al AP. Si tanto en el AP como en el switch sólo va a existir tráfico IOT, sería en modo acceso y listo, sin más.
El AP (Map Lite) o router/switch (HapAc2) si necesitara más puertos, me gustaría que estuviera en la VLAN LAN o Admin, para tener mismo rango de IPs que los demás dispositivos que controlan la red. Por lo que tendría que mandarle tráfico trunk, por eso lo puse así en mi descripción.

Un planteamiento alternativo. ¿Por qué no conectar todo al switch de 24 puertos, y sacar las VLANs desde ahí? Te ahorrarías el vlan filtering del bridge en el router, donde sus puertos serían todos independientes. No obstante, es una simple apreciación, se puede montar perfectamente como lo tienes planteado. Lo único que tienes mal es el "trunk" del switch no gestionable, eso sería un puerto de acceso, no trunk.
No puedo hacer eso por varios motivos. El primero y principal es que tengo más tomas planteadas que las disponibles en el switch. El segundo motivo, es que lo tengo ya todo cableado, bonito y crimpado en el patch-panel. Por lo que el switch me gustaría no tocarlo, y meterle vlan filtering en el bridge, que tengo equipo de sobra.

Mándame la interfaz del switch a ver si la conozco. El modelo no lo he manejado, pero sí algún otro swtich de netgear. Sino, tiraremos de la documentación online y listo. El cambio más grande a hacer en el switch es la VLAN de administración que, dependiendo de con qué opción de las planteadas al principio te quedes, habrá que configurarlo de una manera o de otra. Y ese es el que debes configurar en local antes de llevártelo al sitio, porque es muy probable que haciendo un cambio remoto te quedes sin acceso a él.
Todo el setup está montado ya. Pero no es problema que vaya a la nueva casa y lo configure allí insitu, a la vez que Wireguard. Es lo que tenía planteado inicialmente.
Respecto al manual, no parece dificil hacerlo. De todos modos, dejo aquí el enlace a dicho manual:
Manual Switch Netgear

Y, por descontando, no uses la VLAN1 (vlan por defecto) para nada. Todo el tráfico en su vlan y el el router con ingress filtering, no queremos que ningúna vlan salte por puertos que no le corresponden.
Comprendido

Empieza por wireguard y, cuando lo tengas funcionando, seguimos con las VLANs.
Eso haré! Te voy informando de las novedades!!

Saludos y muchísimas gracias!!
 
Realmente sí que me gustaría acceder a la configuración de los dispositivos desde LAN, o al menos, desde algún dispositivo especifico conectado a dicha red (mi portátil por ejemplo). El hecho de dedicar un puerto del Router solo para la VLAN Admin, y tener que crear un SSID adicional solo para este propósito, no le veo mucho sentido. Las opciones que veo son mantener esa VLAN Admin, permitiéndole acceso solo a LAN (o algún dispositivo concreto de dicha VLAN), o elimina directamente es VLAN e incluirlo la gestión en LAN, perdiendo un poco de limpieza, organización y seguridad.
En ese caso olvídate de la VLAN admin. Ese tipo de vlan (vlan admin, management, base, etc) se usan cuando quieres tener acceso a los equipos sólo desde esa VLAN, y todas las demás son VLANs de servicio. En tu caso, tu vlan de servicio principal es al mismo tiempo la de administración. Así que yo lo dejaría con tres VLANs:
- lan (home, local, llámala como más te guste)
- iot
- invitados

Y le daría permiso a la VLAN home para administrar la red (configurar la etiqueta de VLAN que sea que asignes a la vlan home, como la VLAN de management en el switch).

El AP (Map Lite) o router/switch (HapAc2) si necesitara más puertos, me gustaría que estuviera en la VLAN LAN o Admin, para tener mismo rango de IPs que los demás dispositivos que controlan la red. Por lo que tendría que mandarle tráfico trunk, por eso lo puse así en mi descripción.
OK. Si montas un mAP-Lite, tendrías que mandarle tu vlan "lan" (home) en modo taggeado, y la de IOT untagged, puesto que ese chisme sólo lleva un puerto e irá conectado al switch. Si montas por el contrario un hAP-ac2, podrías montar bridge vlan filtering y sacar un puerto para IOT y el resto para LAN (vlan home).

No puedo hacer eso por varios motivos. El primero y principal es que tengo más tomas planteadas que las disponibles en el switch. El segundo motivo, es que lo tengo ya todo cableado, bonito y crimpado en el patch-panel. Por lo que el switch me gustaría no tocarlo, y meterle vlan filtering en el bridge, que tengo equipo de sobra.
Perfecto. No hay mejor cosa que tenerlo claro. Vamos con bridge vlan filtering en el router en ese caso. Usa los puertos que necesites, y el resto los desactivas. Así, según vayas activando puertos porque los necesitas, los vas metiendo el en bridge en una vlan concreta o como trunk. De esta manera es más fácil no perderse con el mapeo de puertos.

Lo dicho, cuando tengas wireguard montado, seguimos con el resto. Te doy un adelanto de cómo podrían quedar las tres VLANs que te planteaba anteriormente, incluidos los pormenores que querías para la vlan de invitados.

Doy por hecho que estás partiendo de la configuración por defecto. Mantenla de momento, que nos viene bien para configurar todo. Luego borraremos los rastros de la subred 88.

Código:
# Creamos las VLANs
/interface vlan
add interface=bridge name=lan vlan-id=30
add interface=bridge name=iot vlan-id=40
add interface=bridge name=inv vlan-id=50 arp=reply-only

# Las direccionamos
/ip address
add address=192.168.30.1/24 interface=lan
add address=192.168.40.1/24 interface=iot
add address=192.168.50.1/24 interface=inv

# Creamos los pools, dhcp servers y sus correspondientes networks
/ip pool
add name=pool-lan ranges=192.168.30.10-192.168.30.254
add name=pool-iot ranges=192.168.40.10-192.168.40.254
add name=pool-inv ranges=192.168.50.10-192.168.50.254

# DHCP Servers
/ip dhcp-server
add address-pool=pool-lan interface=lan name=dhcp-lan
add address-pool=pool-iot interface=iot name=dhcp-iot
add address-pool=pool-inv interface=inv name=dhcp-inv add-arp=yes

# DHCP Server Networks
/ip dhcp-server network
add address=192.168.30.0/24 dns-server=192.168.30.1 gateway=192.168.30.1
add address=192.168.40.0/24 dns-server=8.8.8.8,8.8.4.4 gateway=192.168.40.1
add address=192.168.50.0/24 dns-server=8.8.8.8,8.8.4.4 gateway=192.168.50.1 netmask=32

# Metemos la interfaz vlan "lan" en la lista LAN, donde ahora está el tráfico untagged del bridge, para que tenga acceso al chain de input del router (si no tocaste el firewall por defecto).
/interface list member
add interface=lan list=LAN

# Creamos la tabla de vlans del bridge, con el siguiente planteamiento
# ether1 - trunk all vlans (30, 40, 50)
# ether3 - híbrido IOT + LAN (40 untagged, 30 tagged)
# ether4 - híbrido LAN + IOT (30 untagged, 40 tagged)
/interface bridge vlan
add bridge=bridge comment=lan tagged=bridge,ether1,ether3 vlan-ids=30
add bridge=bridge comment=iot tagged=bridge,ether1,ether4 vlan-ids=40
add bridge=bridge comment=inv tagged=bridge,ether1 vlan-ids=50

# Modificamos los puertos del bridge para que se ajusten a lo que hemos definido antes
/interface bridge port
set [find interface=ether1 and bridge=bridge] frame-types=admit-only-vlan-tagged
set [find interface=ether3 and bridge=bridge] frame-types=admit-all pvid=40
set [find interface=ether4 and bridge=bridge] frame-types=admit-all pvid=30

# Activamos bridge vlan filtering, de momento sin eliminar la vlan1 por defecto
/interface bridge
set 0 vlan-filtering=yes

Saludos!
 
En ese caso olvídate de la VLAN admin. Ese tipo de vlan (vlan admin, management, base, etc) se usan cuando quieres tener acceso a los equipos sólo desde esa VLAN, y todas las demás son VLANs de servicio. En tu caso, tu vlan de servicio principal es al mismo tiempo la de administración. Así que yo lo dejaría con tres VLANs:
- lan (home, local, llámala como más te guste)
- iot
- invitados
Perfecto, lo hacemos así pues. LAN, IoT e Invitados.

Y le daría permiso a la VLAN home para administrar la red (configurar la etiqueta de VLAN que sea que asignes a la vlan home, como la VLAN de management en el switch).
Genial, miraré como hacer esto en el switch.
OK. Si montas un mAP-Lite, tendrías que mandarle tu vlan "lan" (home) en modo taggeado, y la de IOT untagged, puesto que ese chisme sólo lleva un puerto e irá conectado al switch. Si montas por el contrario un hAP-ac2, podrías montar bridge vlan filtering y sacar un puerto para IOT y el resto para LAN (vlan home).
De momento no tengo AP en el cuadro domótico, y existe la posibilidad de que no me haga falta. Así que de momento por ese puerto solo irá IoT :). Pero es bueno saber que es posible hacerlo en el futuro.
Perfecto. No hay mejor cosa que tenerlo claro. Vamos con bridge vlan filtering en el router en ese caso. Usa los puertos que necesites, y el resto los desactivas. Así, según vayas activando puertos porque los necesitas, los vas metiendo el en bridge en una vlan concreta o como trunk. De esta manera es más fácil no perderse con el mapeo de puertos.
Comprendido

Lo dicho, cuando tengas wireguard montado, seguimos con el resto. Te doy un adelanto de cómo podrían quedar las tres VLANs que te planteaba anteriormente, incluidos los pormenores que querías para la vlan de invitados.
Wireguard ya está montado y funcionando.
He probado dandole conexion a mi pórtatil mediente conexión compartida en el móvil, y me he podido conectar sin problemas al router, y aparece el peer activado en WinBox.
Sin embargo, he intentado seguir el mismo procedimiento en Android (Samsung S22 Ultra), y me salta un error a la hora de levantar la interfaz (wgTurnOn devolvió -1), pero diría que más error del móvil que de la configuración, pues he seguido el mismo orden.
Doy por hecho que estás partiendo de la configuración por defecto. Mantenla de momento, que nos viene bien para configurar todo. Luego borraremos los rastros de la subred 88.
Das por hecho bien :)

Código:
# Creamos las VLANs
/interface vlan
add interface=bridge name=lan vlan-id=30
add interface=bridge name=iot vlan-id=40
add interface=bridge name=inv vlan-id=50 arp=reply-only

# Las direccionamos
/ip address
add address=192.168.30.1/24 interface=lan
add address=192.168.40.1/24 interface=iot
add address=192.168.50.1/24 interface=inv

# Creamos los pools, dhcp servers y sus correspondientes networks
/ip pool
add name=pool-lan ranges=192.168.30.10-192.168.30.254
add name=pool-iot ranges=192.168.40.10-192.168.40.254
add name=pool-inv ranges=192.168.50.10-192.168.50.254

# DHCP Servers
/ip dhcp-server
add address-pool=pool-lan interface=lan name=dhcp-lan
add address-pool=pool-iot interface=iot name=dhcp-iot
add address-pool=pool-inv interface=inv name=dhcp-inv add-arp=yes

# DHCP Server Networks
/ip dhcp-server network
add address=192.168.30.0/24 dns-server=192.168.30.1 gateway=192.168.30.1
add address=192.168.40.0/24 dns-server=8.8.8.8,8.8.4.4 gateway=192.168.40.1
add address=192.168.50.0/24 dns-server=8.8.8.8,8.8.4.4 gateway=192.168.50.1 netmask=32

# Metemos la interfaz vlan "lan" en la lista LAN, donde ahora está el tráfico untagged del bridge, para que tenga acceso al chain de input del router (si no tocaste el firewall por defecto).
/interface list member
add interface=lan list=LAN

# Creamos la tabla de vlans del bridge, con el siguiente planteamiento
# ether1 - trunk all vlans (30, 40, 50)
# ether3 - híbrido IOT + LAN (40 untagged, 30 tagged)
# ether4 - híbrido LAN + IOT (30 untagged, 40 tagged)
/interface bridge vlan
add bridge=bridge comment=lan tagged=bridge,ether1,ether3 vlan-ids=30
add bridge=bridge comment=iot tagged=bridge,ether1,ether4 vlan-ids=40
add bridge=bridge comment=inv tagged=bridge,ether1 vlan-ids=50

# Modificamos los puertos del bridge para que se ajusten a lo que hemos definido antes
/interface bridge port
set [find interface=ether1 and bridge=bridge] frame-types=admit-only-vlan-tagged
set [find interface=ether3 and bridge=bridge] frame-types=admit-all pvid=40
set [find interface=ether4 and bridge=bridge] frame-types=admit-all pvid=30

# Activamos bridge vlan filtering, de momento sin eliminar la vlan1 por defecto
/interface bridge
set 0 vlan-filtering=yes
¿Puedo ir haciendo esto entonces, no?
Quedo a la espera! Saludos!
 
Última edición:
Ya tengo Wireguard funcionando en el móvil Android también.
Algo muy útil para todos -> Parece ser que en Android el puerto usado para Wireguard debe ser mayor a 1000.
Había probado 111, y tras leer mucho, he visto que para la interfaz que usa Android para leer el puerto, debe ser mayor a 1000, si no se complica la cosa. He usado pues el puerto por defecto que define @pokoyo en el manual de Wireguard (12345) y todo andando tanto en el PC como en el móvil.

Listo para empezar con las VLANs!
 
Dale caña a las vlans entonces. Si el puerto que va al switch de momento es sólo acceso de la vlan IOT, configura pvid tal y como te lo mando, pero el frame-mode como “admit only vlan untagged and priority tagged”, y quitas el tag de la vlan 30 de su puerto en la tabla de vlans.

Cuando lo tengas, me pasas un export

Saludos!
 
Dale caña a las vlans entonces. Si el puerto que va al switch de momento es sólo acceso de la vlan IOT, configura pvid tal y como te lo mando, pero el frame-mode como “admit only vlan untagged and priority tagged”, y quitas el tag de la vlan 30 de su puerto en la tabla de vlans.

Cuando lo tengas, me pasas un export

Saludos!
Configuración hecha!
Finalmente he llamado a las VLANs (Home, IoT, Invitados), por lo que toda la config va alineada a esos nombres.

Te adjunto el export.

Por otro lado, tengo que configurar las VLANs en el Switch, porque he perdido acceso a él y a todo lo que cuelga de él.
Saludos!
 

Adjuntos

  • Config_VLANs.rsc.zip
    3 KB · Visitas: 21
Conecta el switch a cualquier otro puerto del bridge (por ejemplo, ether5) donde se sigue usando la vlan1 por defecto, y volverás a tener acceso al router. Configuras las VLANs acorde y mira a ver dónde se configura la management VLAN en el switch, porque en la documentación no queda nada claro.

Saludos!
 
Buenas @pokoyo .
Mientras me contestabas me estaba peleando yo con el Switch, jeje.
Parece que lo tengo ya funcionando.
La clave en el Switch es poner PVID=30 en todos los puertos (menos en el que solo lleva IoT). De esta forma, como verás en las siguiente imagenes, aunque por el puerto 1 van taggeadas todas las VLAN, el switch asigna la definida en el PVID.

En la imagen se puede ver que se están usando 3 puertos (el ether1 es el que va del router al Switch). Las VLANs están definidas correctamente, y en el puerto 8 sigo usando el bridge de la .88
1673294890096.png


En el switch:

1673294964746.png

1673294986756.png

1673294998436.png

1673295011982.png

1673295034833.png


¿El export lo ves correcto, no?
Si es así, creo que solo queda jugar con el tema de los accesos permitidos entre VLANs, y eliminar la VLAN1 por defecto.

Saludos y gracias por la ayuda :)
 
Correcto. Estaba leyendo esto: https://github.com/yhitzel/netgear_gs1058e_mgmt_vlan
Y parece que es la manera que tiene Netgear de tener una vlan de management: simplemente taggeándola en todos los puertos que no sean de acceso a dicha VLAN.

Con respecto a lo que queda: como ambas vlans sólo necesitan acceso a internet, vamos a meter ambas en una lista "ISOLATED" y crear una única regla en forward que impida todo lo que no sea origien esa lista y destino distinto de WAN.
Código:
/interface list
add name=ISOLATED

/interface list member
add list=ISOLATED interface=IoT
add list=ISOLATED interface=Invitados

/ip firewall filter
add action=reject chain=forward comment="isolated vlans: can only access internet" \
in-interface-list=ISOLATED out-interface-list=!WAN reject-with=icmp-net-prohibited

Y, para eliminar de la ecuación la vlan por defecto, simplemente saca del bridge los puertos que no estén en uso ni tengan un PVID concreto (distinto de 1 y que no sean trunk), doble click al bridge, pestaña VLAN, y seleccionas el frame-type=admit only vlan tagged, y con ingress filtering activado:
1673296824159.png


Si luego vas a Bridge -> VLANs, deberías ver que la VLAN ID = 1 ha desaparecido de la tabla.

Saludos!
 
Correcto. Estaba leyendo esto: https://github.com/yhitzel/netgear_gs1058e_mgmt_vlan
Y parece que es la manera que tiene Netgear de tener una vlan de management: simplemente taggeándola en todos los puertos que no sean de acceso a dicha VLAN.

Con respecto a lo que queda: como ambas vlans sólo necesitan acceso a internet, vamos a meter ambas en una lista "ISOLATED" y crear una única regla en forward que impida todo lo que no sea origien esa lista y destino distinto de WAN.
Código:
/interface list
add name=ISOLATED

/interface list member
add list=ISOLATED interface=IoT
add list=ISOLATED interface=Invitados

/ip firewall filter
add action=reject chain=forward comment="isolated vlans: can only access internet" \
in-interface-list=ISOLATED out-interface-list=!WAN reject-with=icmp-net-prohibited

Y, para eliminar de la ecuación la vlan por defecto, simplemente saca del bridge los puertos que no estén en uso ni tengan un PVID concreto (distinto de 1 y que no sean trunk), doble click al bridge, pestaña VLAN, y seleccionas el frame-type=admit only vlan tagged, y con ingress filtering activado:
Ver el adjunto 102801

Si luego vas a Bridge -> VLANs, deberías ver que la VLAN ID = 1 ha desaparecido de la tabla.

Saludos!
Mañana lo pruebo insitu, porque queria probar algunas cosas, y he restaurado en remoto el backup que tenia, pero ahora después de esto no puedo acceder al router, el tunel Wireguard levanta pero parece que no recibe nada, y no tengo ping al router.

Por otro lado, otro tema que me viene a la mente...
¿Hay alguna posibilidad de incluir los RW de Wireguard en la VLAN Home? Me encuentro con el problema que no puedo acceder a gestionar algunos dispositivos como el switch, me rechaza la conexión. Esto puede ocurrir por varios motivos:
- Alguna regla de Firewall que me falta por añadir.
- Necesito estar en el mismo rango de IPs que el switch (Wireguard .90, Home .30) -> Me inclino porque este es el motivo

Lo mismo me ocurre por ejemplo con la gestión de los Unifi, al no estar en la misma subred, parece que no los detecta si abro la consola en remoto.
 
¿Hay alguna posibilidad de incluir los RW de Wireguard en la VLAN Home? Me encuentro con el problema que no puedo acceder a gestionar algunos dispositivos como el switch, me rechaza la conexión. Esto puede ocurrir por varios motivos:
- Alguna regla de Firewall que me falta por añadir.
- Necesito estar en el mismo rango de IPs que el switch (Wireguard .90, Home .30) -> Me inclino porque este es el motivo
No es necesario. Wireguard = L3, VLANs = L2. En L3, en forward, todo salvo lo que prohíbas expresamente está comunicado. Si no llegas a una consola de admin web del switch netgear, tienes un problema de MTU (me ha pasado lo mismo con uno que tengo instalado en casa de un familiar y al que no llegaba vía unión site to site usando wireguard). Se corrige con una regla de mangle (ya la meteremos, descuida). Pero tírale un ping a la IP, verás como llegas.

No obstante, si conectas con el cliente móvil de wireguard, verás que sí llegas a cualquier equipo de cualquiera de las tres VLANs.

Saludos!
 
No es necesario. Wireguard = L3, VLANs = L2. En L3, en forward, todo salvo lo que prohíbas expresamente está comunicado. Si no llegas a una consola de admin web del switch netgear, tienes un problema de MTU (me ha pasado lo mismo con uno que tengo instalado en casa de un familiar y al que no llegaba vía unión site to site usando wireguard). Se corrige con una regla de mangle (ya la meteremos, descuida). Pero tírale un ping a la IP, verás como llegas.

No obstante, si conectas con el cliente móvil de wireguard, verás que sí llegas a cualquier equipo de cualquiera de las tres VLANs.

Saludos!
Si, mediante ping sí llegaba sin problemas. Tardaba bastante más (30 ms), normal por el túnel, pero llegaba.
Pues sí, habrá que meter esa regla de mangle sí.

Por otro lado, ¿es normal lo que me ha pasado que al restaurar un backup en remoto, usando el túnel Wireguard, ahora el túnel no levanta porque falla el handshake? Ahora necesito ir de nuevo esta tarde para chequear, porque he perdido todo acceso remoto después de restaurar el backup.
 
Pues la historia es que como no sé qué estás restaurando, no sé si es normal o no lo que te falla. Ten en cuenta que las interfaces wireguard, cada vez que las generas, generan una clave privada distinta. Y, asociada a esa clave privada, va la pública que intercambias con los peers. Si eso ha cambiado, no vas a conectar ni en broma al otro extremo, por mucho que todo lo demás esté bien. Pero insisto, sin saber qué backup es ni qué configuración estás restaurando, es un poco aventurado decir "sí, este es el problema".

Con respecto a la regla de mangle, si tienes ahora mismo un site to site montando entre tu casa y donde va a ir ese setup montado a futuro, mete la siguiente regla de mangle para ajustar el MTU del tráfico de lan a lan, donde "STS" es una lista a la cual pertenecen las interfaces wireguard de tipo site to site (por si tienes más de una, sino, siempre puedes modificar la regla y, en lugar de "out-interface-list=STS" pone "out-interface=wireguardX" o la que sea tu interfaz).
Código:
/ip firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu out-interface-list=\
    STS passthrough=yes protocol=tcp tcp-flags=syn
 
Pues la historia es que como no sé qué estás restaurando, no sé si es normal o no lo que te falla. Ten en cuenta que las interfaces wireguard, cada vez que las generas, generan una clave privada distinta. Y, asociada a esa clave privada, va la pública que intercambias con los peers. Si eso ha cambiado, no vas a conectar ni en broma al otro extremo, por mucho que todo lo demás esté bien. Pero insisto, sin saber qué backup es ni qué configuración estás restaurando, es un poco aventurado decir "sí, este es el problema".
Culpa mía no describirlo mejor.
Cuando tenía funcionando tanto la VPN Wireguard (Roadwarrior) como las VLAN de forma correcta, saqué un backup, como buena práctica que me gustaría seguir.
Luego, cuando llegué a mi casa actual, me conecté al Router mediante la VPN, y me puse a juguetear un poco con las distintas opciones de Winbox para aprender más, con idea de restaurar el backup que había hecho cuando terminara. Asi que cuando terminé, me fui a System-> Reset Configuration, activé "Keep users" y nada más, y le indiqué que cargara el backup que había hecho un rato antes.

Desde ese momento, perdí comunicación con el router y pensé que la había liado, pero tal y como dices, si Wireguard crea nuevas claves al desactivar la interfaz o cargar una configuración, entonces queda todo explicado.
Con respecto a la regla de mangle, si tienes ahora mismo un site to site montando entre tu casa y donde va a ir ese setup montado a futuro, mete la siguiente regla de mangle para ajustar el MTU del tráfico de lan a lan, donde "STS" es una lista a la cual pertenecen las interfaces wireguard de tipo site to site (por si tienes más de una, sino, siempre puedes modificar la regla y, en lugar de "out-interface-list=STS" pone "out-interface=wireguardX" o la que sea tu interfaz).
Código:
/ip firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu out-interface-list=\
    STS passthrough=yes protocol=tcp tcp-flags=syn
Mi configuración no es un site to site (que creo que sería un túnel entre 2 routers Mikrotik). Es una configuración RoadWarrior donde mi pórtatil es cliente Wireguard para mi red. En ese caso, ¿la regla que comentas es todavía válida? Voy a leer un poco a ver qué significa cada campo que la compone.

Muchas gracias!
 
Así no se carga un backup, se carga une export. Y ha de ser un export completo, si no se hizo con un show-sensitive, le faltarán las contraseñas y datos sensibles (como la clave privada del wireguard). Así que ya sabes lo que te ha pasado, la interfaz wireguard se ha regenerado, con otra clave privada.

Para otra vez, guarda backup y restaura backup también, además del export. Este se restaura en el menú "Files" o desde terminal con la instrucción siguiente:
Código:
system/backup/load name=fichero-backup

La regla no suele ser necesaria para un acceso de tipo road-warrior, ya que los clientes suelen hacer el cálculo del MTU de manera automática.

Saludos!
 
Así no se carga un backup, se carga une export. Y ha de ser un export completo, si no se hizo con un show-sensitive, le faltarán las contraseñas y datos sensibles (como la clave privada del wireguard). Así que ya sabes lo que te ha pasado, la interfaz wireguard se ha regenerado, con otra clave privada.

Para otra vez, guarda backup y restaura backup también, además del export. Este se restaura en el menú "Files" o desde terminal con la instrucción siguiente:
Código:
system/backup/load name=fichero-backup
Fallo mío de nuevo al explicarme. Lo que yo hice fue un export, con "export file="xxx" ". Imagino que mi fallo fue no hacerlo con el show-sensitive, pensé que lo hacía por defecto, y sólo había que explicitar cuando querias ocultarlos con el "hide sensitive".
El proceso correcto entonces es: restaurar backup y luego importar el export?

La regla no suele ser necesaria para un acceso de tipo road-warrior, ya que los clientes suelen hacer el cálculo del MTU de manera automática.
En mi portátil Mac e intentando acceder a la interfaz del switch Netgear:
- Si lo hago insitu, accedo sin problemas.
- Usando el túnel Wireguard, conexión rechazada. Sin embargo, sí tengo ping tal y como vaticinaste.

Espero que sea uno de esos casos raros de clientes que no hacen bien el cálculo de MTU. Pruebo la regla que me has pasado y te comento.

Muchísimas gracias de nuevo, y saludos!
 
No exactamente. Si quieres guardar tu config con idea de consultarla, modificarla o llevártela a otro equipo > export.

Si quieres algo que guarde una copia exacta que puedas restaurar > backup/restore.

Saludos!
 
Disculpad la intromisión en el hilo.

Quería hacer una consulta, relativa a la "famosa" regla de mangle para ajustar el MTU. ¿Es necesaria o conveniente para conexiones wireguard-sts donde corre un túnel EoIP (Paco-Pepe)?

Lo comento porque sigo investigando leves pixelaciones que tengo tanto en local como en remoto. La topología de red es íntegramente mikrotik (ONT+MK) tanto en Paco (yo) como en pepe.

Como siempre, mil gracias de antemano.

Saludos!
 
Arriba