MANUAL: Mikrotik, VPN tipo RoadWarrior usando WireGuard

Ok, entonces me pondré de momento con este post:

Como quieras. Es un tipo de vpn muy rápida también y que funciona muy bien. Algo más compleja de montar que WireGuard, pero muy rápida también.

Saludos!
 
Como quieras. Es un tipo de vpn muy rápida también y que funciona muy bien. Algo más compleja de montar que WireGuard, pero muy rápida también.

Saludos!
por probar me gustaria, pero la V7 todavia esta en desarrollo, no es version stable y no soy muy amigo de las versiones beta. Y la otra opcion aparte de esta seria la que va por IKEv2 no?
 
por probar me gustaria, pero la V7 todavia esta en desarrollo, no es version stable y no soy muy amigo de las versiones beta. Y la otra opcion aparte de esta seria la que va por IKEv2 no?
La v7 sigue siento una versión en desarrollo, pero es ya una release candidate. Yo tampoco soy muy amigo de usar versiones beta, pero tuve mucho tiempo la v7 funcionando en un router convertido en switch y este fin de semana me decidí a migrar el router principal. Y, de momento, sin problema.

Saludos!
 
Buenas tardes.

Un placer aparecer por aquí nuevamente tras un largo parón que me han obligado a hacer mis hijos y trabajo.

Esperemos que salga pronto la versión 7 estable que tengo muchas ganas de probar la VPN Wireward porque hasta ahora estoy utilizando OpenVPN a través del NAS pues no me ha dado tiempo a ponerme para configurarlo directamente en el router.

Espero tener más tiempo para pasar por aquí, seguir aprendiendo de vosotros y si algún nuevo novato se anima y puedo echarle una mano pues fantástico.

Un saludo.
 
Buenas chicos.

Para poder acceder al router desde un cliente conectado a la VPN he hecho esto:

1638583146057.png


Es decir, he añadido la interfaz wireguard a la lista LAN. Decidme que no he hecho ninguna burrada...

Saludos!
 
Buenas chicos.

Para poder acceder al router desde un cliente conectado a la VPN he hecho esto:

Ver el adjunto 88938

Es decir, he añadido la interfaz wireguard a la lista LAN. Decidme que no he hecho ninguna burrada...

Saludos!
De entrada no, pero todo depende de lo que busques. ¿Quieres que todos y cada uno de los clientes que atienda esa interfaz accedan al equipo? O solo alguna de las IPs /32 que tienes en la lista de Peers? Puedes crear una lista en ip > firewall > address list y dar de alta allí las IPs concretas que necesitas que tengan acceso al propio router, y crear en el chain de input una regla que diga “allow admin from wireguard”, usas esa lista como src-address-list, y así segmentas un poquito mejor.

Otra opción es tener dos interfaces wireguard (dos servidores), uno para admins u otro para el mundán populacho, y harías lo mismo que has hecho tú, pero a la del populacho la restringiría como si de una red de invitados se tratara: capando en forward todo tráfico con destino distinto de WAN.

Saludos!
 
Muchas gracias @pokoyo. Da gusto así. Tengo dos dudas.

La primera es la de siempre. No se si alguna vez aprenderé las prioridades de las reglas de firewall de chain de tipo input. Donde colocaría esa regla?

Y la segunda duda es, con respecto a la segunda solución que propones (que no es mala), qué sentido le ves a crear una segunda interfaz VPN en la que le capes todo el trafico que no sea la WAN? Para eso no te conectes a la VPN y listo, no? A no ser que te refieras a tener algo de seguridad cuando te conectas a una red tipo la de los aeropuertos o algo, no le veo mucho sentido.

Saludos!!
 
La primera es la de siempre. No se si alguna vez aprenderé las prioridades de las reglas de firewall de chain de tipo input. Donde colocaría esa regla?
Las prioridades son, según las lees de arriba a abajo. Si usas el filtro de arriba a la derecha de winbox en la pantalla de firewall filter, puedes filtrar solo para las de un chain, y así las ves todas de seguido. La prioridad es el orden de esa lista, de arriba a abajo, ni más ni menos.

Y la segunda duda es, con respecto a la segunda solución que propones (que no es mala), qué sentido le ves a crear una segunda interfaz VPN en la que le capes todo el trafico que no sea la WAN? Para eso no te conectes a la VPN y listo, no? A no ser que te refieras a tener algo de seguridad cuando te conectas a una red tipo la de los aeropuertos o algo, no le veo mucho sentido.
Yo puedo tener dos VPN's. Una donde me conecto yo, y accedo al router, otra donde se conecta mi familia y amigos, y sólo accede a los equipos que yo quiero que accedan y a internet. Para eso vale.

Saludos!
 
Gran hilo! @pocoyo, funciona todo perfecto. Tengo el wireguard en la version 7.1 del rb4011 y las pruebas todas ok. La unica cosa, realmente hace falta hacerle masquerade? Porque en principio yo no lo tengo, lo deshabilite para probar y parece que va igual. De hecho tenia la regla debajo de la masquerade de la red normal y no se movian los counters, si la pongo encima si se mueven, pero claro, igualmente parece que enmascara con la regla principal...

Supongo que podriamos quitarla no? O me he perdido en algo?

Por cierto, ojo a los que tengáis varias Addresses configuradas y las que no quieren que se vean entre ellas, yo he configurado una regla tal que:

1638627187673.png


Dropeo todo el trafico de la red 10.10.0.0/24 si no voy a mi LAN principal o !WAN, de esta forma, los clientes wireguard solo entrarian a mi red principal (No es una regla que haya que aplicar en todos los casos, este es mi caso), pero lo que intento en mi caso con esto es que los clientes wireguard no accedan a las redes que no me interesan (solo en mi caso acceso a la 192.168.11.0/24) Cada caso es un mundo, pero si no se pone una regla tal que así, los clientes wireguard podrían acceder al resto de redes configuradas en el mikrotik
 
Última edición:
Yo puedo tener dos VPN's. Una donde me conecto yo, y accedo al router, otra donde se conecta mi familia y amigos, y sólo accede a los equipos que yo quiero que accedan y a internet. Para eso vale.

Si, eso lo entiendo. Quizás no me he explicado bien. La duda es. ¿Para qué quieres conectar a tu familia a la VPN solo para navegar a Internet, si pueden hacerlo sin estar conectados a la VPN? Es lo que te decía antes, que igual estando conectado a la wifi de un aeropuerto le veo sentido (por seguridad) pero quitando esa casuística... yo lo dejaría sin estar en la VPN.

Yo es que el principal uso que le veo a la VPN es precisamente poder acceder a los chismes de mi LAN. Tengo un NAS, y para que mi familia pueda acceder a sus documentos, imágenes y tal, pues lo podrían hacer por samba conectándose a la VPN. Para todo lo demás, la red de datos del movil va muy bien :)

¡Saludos!
 
Gran hilo! @pocoyo, funciona todo perfecto. Tengo el wireguard en la version 7.1 del rb4011 y las pruebas todas ok. La unica cosa, realmente hace falta hacerle masquerade? Porque en principio yo no lo tengo, lo deshabilite para probar y parece que va igual. De hecho tenia la regla debajo de la masquerade de la red normal y no se movian los counters, si la pongo encima si se mueven, pero claro, igualmente parece que enmascara con la regla principal...

Supongo que podriamos quitarla no? O me he perdido en algo?

Por cierto, ojo a los que tengáis varias Addresses configuradas y las que no quieren que se vean entre ellas, yo he configurado una regla tal que:

Ver el adjunto 88950

Dropeo todo el trafico de la red 10.10.0.0/24 si no voy a mi LAN principal o !WAN, de esta forma, los clientes wireguard solo entrarian a mi red principal (No es una regla que haya que aplicar en todos los casos, este es mi caso), pero lo que intento en mi caso con esto es que los clientes wireguard no accedan a las redes que no me interesan (solo en mi caso acceso a la 192.168.11.0/24) Cada caso es un mundo, pero si no se pone una regla tal que así, los clientes wireguard podrían acceder al resto de redes configuradas en el mikrotik

No es necesario hacer masquerade con wireguard, ahora lo corrijo en el manual (fue de las primera pruebas y estaba hecha en un equipo que no era router principal). Ese masquerade sobra.

Y, en lugar de esa regla de drop, puedes configurar qué subredes le mandas al peer remoto, en lugar de dejarle acceder a 0.0.0/0 (aunque bien es verdad que si no controlas el remoto, él podría cambiarlo e intentar acceder a ellas).

Saludos!
 
Si, eso lo entiendo. Quizás no me he explicado bien. La duda es. ¿Para qué quieres conectar a tu familia a la VPN solo para navegar a Internet, si pueden hacerlo sin estar conectados a la VPN? Es lo que te decía antes, que igual estando conectado a la wifi de un aeropuerto le veo sentido (por seguridad) pero quitando esa casuística... yo lo dejaría sin estar en la VPN.

Yo es que el principal uso que le veo a la VPN es precisamente poder acceder a los chismes de mi LAN. Tengo un NAS, y para que mi familia pueda acceder a sus documentos, imágenes y tal, pues lo podrían hacer por samba conectándose a la VPN.

¡Saludos!
Imagínate que sólo quiero que accedan a una máquina concreta, restringido por una regla de firewall, y que viven en finlandia, y quieren ver TV española con una IP de aquí.

Saludos!
 
Imagínate que sólo quiero que accedan a una máquina concreta, restringido por una regla de firewall, y que viven en finlandia, y quieren ver TV española con una IP de aquí.

Saludos!
En ese caso sí que lo haría :)

En mi caso me interesa mucho más la primera opción que diste. Le doy acceso a la LAN, pero no al router. Así pueden acceder al NAS, o a Home Assistant, o a lo que quieran, sin necesidad de acceso al router, que es lo que no necesitan

Gracias @pokoyo
 
De entrada no, pero todo depende de lo que busques. ¿Quieres que todos y cada uno de los clientes que atienda esa interfaz accedan al equipo? O solo alguna de las IPs /32 que tienes en la lista de Peers? Puedes crear una lista en ip > firewall > address list y dar de alta allí las IPs concretas que necesitas que tengan acceso al propio router, y crear en el chain de input una regla que diga “allow admin from wireguard”, usas esa lista como src-address-list, y así segmentas un poquito mejor.
Buenos pues vamos manos a la obra. A ver si con esto termino afianzando ya las reglas del chain de tipo input.

Lo primero de todo me he creado la lista con las ips que tendrán acceso al router desde Wireguard. He visto que no te deja crear en una única fila mas de una IP, asi que he optado por definir un rango de esta forma:

1638659785620.png


Entiendo que no debería tener problema, y que esto debería funcionar bien. A los clientes que no quiera que tengan acceso al router de doy una IP mayor que la 192.168.90.10, y para los que quiera que tengan acceso se la doy menor o igual.

Bueno, ahora voy con la chain de tipo input. Aquí es donde me pierdo más. Según me has explicado de las prioridades, lo que creo que deberíamos hacer es meter una regla justo por encima de la allow Wireguard "universal" (que no deja acceder al router), y esta regla, será idéntica pero añadiremos la condición que indicas (comprobar si la IP es una de las definidas en la lista).

Aquí viene mi deducción: Si eso pasa, ¿Entiendo que lo que tengo que hacer aceptarla pero asignándole la in-interface-list LAN para que tenga acceso al router?

Así es como la he definido y ubicado (linea 2):

1638661179293.png


Pero no me va, así que supongo que mi lógica no está acertando :D

Saludos!
 
Última edición:
No, no vas bien compi. Es mucho más sencillo, te estás complicando al vida tela.

Lo primero de todo me he creado la lista con las ips que tendrán acceso al router desde Wireguard. He visto que no te deja crear en una única fila mas de una IP, asi que he optado por definir un rango de esta forma:

1638659785620.png


Entiendo que no debería tener problema, y que esto debería funcionar bien. A los clientes que no quiera que tengan acceso al router de doy una IP mayor que la 192.168.90.10, y para los que quiera que tengan acceso se la doy menor o igual.
Crea la lista que sea y mete una IP. Luego le das a "copy" mantén el nombre de la lista, y metes una segunda IP. Y así sucesivamente. El campo del nombre de la lista es un dropdown, puedes seleccionar una, si ya hay previamente al menos una entrada creada. ¿puedes definir una lista, tal y como has hecho? Sí, puedes, pero no es obligatorio.


Bueno, ahora voy con la chain de tipo input. Aquí es donde me pierdo más. Según me has explicado de las prioridades, lo que creo que deberíamos hacer es meter una regla justo por encima de la allow Wireguard "universal" (que no deja acceder al router), y esta regla, será idéntica pero añadiremos la condición que indicas (comprobar si la IP es una de las definidas en la lista).

Aquí viene mi deducción: Si eso pasa, ¿Entiendo que lo que tengo que hacer aceptarla pero asignándole la in-interface-list LAN para que tenga acceso al router?

Así es como la he definido y ubicado (linea 2):

1638661179293.png


Pero no me va, así que supongo que mi lógica no está acertando :D
Aquí vas mal del todo. Repasemos los chains o cadena de conexión de un firewall:
input: tráfico con destino el propio equipo, en nuestro caso, el router
forward: tráfico con origen o destino un equipo que está detrás del router (NATeados, normalmente)
output: tráfico con origen el propio equipo, en nuestro caso, el router

Sabiendo esto, ya sabemos una cosa clara: todo servicio que corra el propio router y al cual quieras acceder desde fuera, necesita una regla de input que acepte dicho tráfico explícitamente. ¿por qué? Porque el firewall por defecto de mikrotik (muy inteligentemente) impide que nada del mundo exterior acceda al propio router. Analicemos las reglas por defecto del chain de input (todas las defconf: XXX). Si arriba a la derecha en el dropdown que pone "all" seleccionas "input" lo verás más fácil, puesto que filtras y muestras las de ese chain únicamente. ¿cómo entra el tráfico por las las reglas? Pues en orden en el que se las va encontrando y, conforme encuentra un "match" entra por ahí y no sigue mirando más reglas. Es por eso que las reglas de "accept" (aceptan el tipo de tráfico que machea con la regla) suelan ser de carácter específico, y las de "drop" sean generalistas. ¿por qué? porque todo tráfico que no se descarte, se acepta por defecto (firewall sin reglas = acepta todo = Sodoma y Gomorra)


Regla 1: "accept established, related, untracked": acepta tráfico de una conexión ya establecida. Al ser la primera regla, toda conexión ya establecida sólo pasará por una única regla, la primera, y dejará de mirar el resto de reglas, por lo que hemos explicado justo antes.
Regla 2: "drop invalid": tira todo paquete inválido
Reglas 3, 4, 5, 6... etc: reglas que aceptan explícitamente que cierto tráfico llegue al propio router
Última regla de input, "drop all not coming from LAN": esta es la que hace la magia. Es una regla generalista que impide que, para el tráfico que haya llegado hasta ella (recordemos que conforme hay un match el tráfico entra por esa regla, es como una escalera), si no viene de dentro de la red interna (normalmente únicamente el bridge principal está dentro de la lista LAN), lo mande a hacer gárgaras. Es decir, esta es la regla que previene que un tío desde internet, acceda a tu equipo (si lo quieres comprobar, es tan sencillo como comentar la regla y, en una conexión 3G del móvil, abrir un navegador y poner tu ip pública, verás como llegas al router). Con la regla en funcionamiento, ese tráfico nunca llega al router.

Con este repaso, sabemos que las reglas que aceptan tráfico con destino al router tienen que ir entre la regla dos y la última que descarta "todo lo que no sea LAN". ¿cómo lo hacemos para conseguir lo que tú quieres hacer? Pues, en lugar de la regla que has creado (la puedes borrar, está mal, tiene más filtros que la virgen), creamos esta:
Código:
/ip firewall filter
add action=accept chain=input comment="vpn: allow admins from wireguard" \
    src-address-list=wireguard-admins  \
    place-before [find comment="defconf: drop all not coming from LAN"]

Que quiere decir: permite que los clientes con una IP en esa lista lleguen al router. Y me la pones delante de la regla generalista que tira el tráfico que no viene de la LAN.

La que tú creaste, decía:
permite que los clientes con una IP en esa lista (hasta aquí bien), que vengan de la iterfaz LAN (mal, vienen por otra interfaz) y que accedan al puerto de wireguard (mal, los clientes accederán al 80 o al puerto de winbox, pero no al de wireguard) y con tipo de tráfico udp (mal, el acceso al router es tcp), [los que cumplan TODAS esas condiciones] lleguen al router

¿se entiende mejor ahora?

Por cierto, no te pierdas el nuevo manual de WireGuard a fondo, que te va a venir muy bien para este y otros setups.

Saludos!
 
@pokoyo me ha quedado clarísimo. Y por supuesto que funciona... Vaya masterclass...

Vale. Por no tener claros los conceptos creo que me ha liado la regla de allow Wireguard (la del protocolo udp), pero creo que ya he entendido su funcionamiento, a ver si estoy en lo cierto: Por esta regla pasa cuando un cliente abre una conexión con Wireguard. Entonces envía un paquete al puerto 51820 por el protocolo upd y, gracias a esta regla, el router la acepta (de hecho la ip de origen es una ip publica, y la ip de destino es la ip publica del router). Una vez aceptado, el cliente ya envia peticiones con su IP privada (en mi caso 192.168.90.2) y usando el protocolo tcp (al menos cuando intenta acceder al router, al resto de equipos de mi red no estoy seguro). Por eso es necesaria esa regla que has indicado para poder acceder al router.

Me queda una duda con respecto a esto. A nivel de filter rules, en cuanto a un cliente ya conectado a la VPN de Wireguard. ¿Qué diferencia hay entre una petición para conectarte al NAS, y otra para conectarte al router? Es decir, yo sin la regla de "allow admins from Wireguard" podía acceder al NAS, pero no al router. ¿Es porque estas peticiones van por el protocolo udp y puerto 51820? Es por saber qué regla es la que aceptaba este tipo de peticiones al NAS, y no se aceptaba las peticiones al router.

Luego tengo una duda pequeña con respecto al orden. Estoy casi seguro que el QuickSet me creó las reglas del firewall de las anteriores VPNs (L2TP e IKEv2) antes de la regla del drop invalid, tal que así:

1638720403226.png


También el tutorial de @stargate4you, crea una regla para aceptar la Voip antes de la regla del drop invalid, de esta forma:

Código:
# Aceptar el tráfico de entrada para la vlan3 en el firewall
/ip firewall filter
add action=accept chain=input comment="Acepta el trafico de la vlan del telefono" \
    in-interface=vlan3 src-address=10.0.0.0/8 \
    place-before=[find where chain=input and comment="defconf: drop invalid"]

Sin embargo tu indicas (y con mucho sentido), que es mejor que este tipo de reglas esté siempre detrás de esa regla, para que si llega un paquete no valido, ni siquiera se lo replantee y lo tire fuera. Lo he modificado segun tus indicaciones y me ha quedado así:

1638720534671.png


¿Es más correcto tener el filter rules de esta forma? ¿Por qué crees que MikroTik montaba la reglas de las VPN delante de la regla del drop invalid? ¿Es indiferente?

El manual de WireGuard acabo de ver que existe... :-O. Me lo he mirado por encima y tiene muy muy buena pinta. Esta noche me lo leo despacio para enterarme de todo.

Saludos!!
 
Vale. Por no tener claros los conceptos creo que me ha liado la regla de allow Wireguard (la del protocolo udp), pero creo que ya he entendido su funcionamiento, a ver si estoy en lo cierto: Por esta regla pasa cuando un cliente abre una conexión con Wireguard. Entonces envía un paquete al puerto 51820 por el protocolo upd y, gracias a esta regla, el router la acepta (de hecho la ip de origen es una ip publica, y la ip de destino es la ip publica del router). Una vez aceptado, el cliente ya envia peticiones con su IP privada (en mi caso 192.168.90.2) y usando el protocolo tcp (al menos cuando intenta acceder al router, al resto de equipos de mi red no estoy seguro). Por eso es necesaria esa regla que has indicado para poder acceder al router.
Ihhh casi, no es exactamente así, pero vas muy bien encaminado. Esa regla vale para arrancar el túnel... y nada más. El cliente o clientes que consuman tu servidor VPN, se comunicarán con tu IP pública, en ese puerto (o cualquier otro que elijas, como ves puedes poner el que más te guste) y tirarán un paquete para arrancar el servicio VPN. Establecido el túnel y satisfecho el handshake, el resto es un intercambio de datos en otro chain, el de forward (recuerda, forward = tráfico con origen o destino un equipo de dentro de la red, en este caso, tu cliente VPN que se le considera interno al venir por un túnel VPN). Esa regla no filtro alguno, porque asume que la conexión la puede originar cualquiera, es decir, es un tipo de conexión "road-warrior". La segunda regla, lo que permite es que un cliente N de la subred de wireguard, sea capaz de llegar a la web de admin del propio router. No tiene filtro, pero, si quieres, podrías restringir eso al puerto del winbox o al puerto donde corra webfig, (imagínate que lo has cambiado y no lo tienes en el 80). Son dos reglas totalmente distintas. Una permite la VPN, y la otra permite que, una vez dentro de la VPN llegues a lo que es el propio router (lo cual normalmente no es ni necesario).

Me queda una duda con respecto a esto. A nivel de filter rules, en cuanto a un cliente ya conectado a la VPN de Wireguard. ¿Qué diferencia hay entre una petición para conectarte al NAS, y otra para conectarte al router? Es decir, yo sin la regla de "allow admins from Wireguard" podía acceder al NAS, pero no al router. ¿Es porque estas peticiones van por el protocolo udp y puerto 51820? Es por saber qué regla es la que aceptaba este tipo de peticiones al NAS, y no se aceptaba las peticiones al router.
Revisa la explicación de los chains. Porque el router es una cosa (input/output) y lo que está debajo del router es otra (forward). Y, en forward, toda conexión originada desde dentro de la red, por defecto, está permitida (si te lees las reglas de drop de forward, verás que no hay nada que lo impida). Al contrario, toda conexión originada desde fuera está descartada, salvo que esté abierta en el NAT explicitamente (que es justo lo que significa la última regla de drop que dice "defconf: drop all from WAN not DSTNATed". Pero ¿qué pasa con las VPN? pues que son como si fueran un agujerito por el que tú te metes dentro de la red, y pasas a considerarte un elemento de dentro, no de fuera. Es por eso que siempre recomiendo VPN frente a abrir puertos, porque abrir puertos es hacer un agujero a una bolsa de agua, por ahí se escapa. Sin embargo, un túnel VPN es como tener una pajita, solo tú que la tienes puedes pincharla y chupar agua de dentro de la bolsa. Bueno, no es el mejor ejemplo, pero si le echas un poco de imaginación... ya me entiendes.

Con respecto al orden de las reglas: es tan sencillo como que ejecutes esta instrucción, si quieres ver el orden original, para imprimir el script de auto-configuración.
Código:
system default-configuration print
1638729087765.png


Es decir, la regla de drop es la segunda, también en el script original. Y una muy muy importante, y que no deberías mover también de la posición donde está es la del ICPM. Esa regla permite que hagas ping a tu IP pública desde internet (y dirás tú, pues la quito, total, para qué la quiero, yo no quiero que nadie me haga ping desde internet), pero es que también se usa para calcular el MTU (tamaño máximo del paquete de transmisión de datos), de manera automática. Así que, esa regla, inmediatamente detrás de la del drop invalid. La de CAPsMAN sólo vale para equipos que tengan wifi incorporado, por si en un momento quisieras manejar la wifi de ese propio equipo vía CAPsMAN, siendo él mismo manager. Si tienes un equipo de sólo cable, esa regla no te vale para nada, la podrías borrar.

Así que la posición de todo lo que abras implícitamente en input, ha de ir justo por encima de la de "drop all not coming from LAN", y debajo de la que acepta el ICMP. Y, dentro de ese hueco, si tienes que meter varias reglas, sigue esta regla lógica: lo que vaya a recibir más tráfico, primero (por ejemplo, la que acepta la conexión de la vpn, antes de la que acepta que los clientes de la VPN puedan acceder al router).

Mírate el manual de WireGuard a fondo, que te va a gustar.

Saludos!
 
Ihhh casi, no es exactamente así, pero vas muy bien encaminado. Esa regla vale para arrancar el túnel... y nada más. El cliente o clientes que consuman tu servidor VPN, se comunicarán con tu IP pública, en ese puerto (o cualquier otro que elijas, como ves puedes poner el que más te guste) y tirarán un paquete para arrancar el servicio VPN. Establecido el túnel y satisfecho el handshake, el resto es un intercambio de datos en otro chain, el de forward (recuerda, forward = tráfico con origen o destino un equipo de dentro de la red, en este caso, tu cliente VPN que se le considera interno al venir por un túnel VPN). Esa regla no filtro alguno, porque asume que la conexión la puede originar cualquiera, es decir, es un tipo de conexión "road-warrior". La segunda regla, lo que permite es que un cliente N de la subred de wireguard, sea capaz de llegar a la web de admin del propio router. No tiene filtro, pero, si quieres, podrías restringir eso al puerto del winbox o al puerto donde corra webfig, (imagínate que lo has cambiado y no lo tienes en el 80). Son dos reglas totalmente distintas. Una permite la VPN, y la otra permite que, una vez dentro de la VPN llegues a lo que es el propio router (lo cual normalmente no es ni necesario).
Vale, ya me queda clarísimo esto. Mi fallo era lo del chain, input para llegar al router, y el forward es para el tráfico con origen o destino un equipo de la red. Era lo que me faltaba por comprender para entender ahora el funcionamiento de esto :)

Revisa la explicación de los chains. Porque el router es una cosa (input/output) y lo que está debajo del router es otra (forward). Y, en forward, toda conexión originada desde dentro de la red, por defecto, está permitida (si te lees las reglas de drop de forward, verás que no hay nada que lo impida). Al contrario, toda conexión originada desde fuera está descartada, salvo que esté abierta en el NAT explicitamente (que es justo lo que significa la última regla de drop que dice "defconf: drop all from WAN not DSTNATed". Pero ¿qué pasa con las VPN? pues que son como si fueran un agujerito por el que tú te metes dentro de la red, y pasas a considerarte un elemento de dentro, no de fuera. Es por eso que siempre recomiendo VPN frente a abrir puertos, porque abrir puertos es hacer un agujero a una bolsa de agua, por ahí se escapa. Sin embargo, un túnel VPN es como tener una pajita, solo tú que la tienes puedes pincharla y chupar agua de dentro de la bolsa. Bueno, no es el mejor ejemplo, pero si le echas un poco de imaginación... ya me entiendes.
Si, ya está claro. Si el cliente de vpn accede al router se usa el chain de tipo input, pero si intenta acceder a otro sitio usa el chain de tipo forward (si ya está dentro de la VPN) :)

Con respecto al orden de las reglas: es tan sencillo como que ejecutes esta instrucción, si quieres ver el orden original, para imprimir el script de auto-configuración.
Código:
system default-configuration print
Ver el adjunto 89022
Mmm cachis, es que esta default configuration no te monta las reglas de las VPN cuando marcas del check de "VPN" del QuickSet. Me es super complejo probarlo ahora porque solo tengo un router, pero ya te digo que estoy casi seguro que las montaba encima de la regla 2 (drop invalid de input), pero bueno, es lo de menos.

La regla de drop es la segunda, también en el script original. Y una muy muy importante, y que no deberías mover también de la posición donde está es la del ICPM. Esa regla permite que hagas ping a tu IP pública desde internet (y dirás tú, pues la quito, total, para qué la quiero, yo no quiero que nadie me haga ping desde internet), pero es que también se usa para calcular el MTU (tamaño máximo del paquete de transmisión de datos), de manera automática. Así que, esa regla, inmediatamente detrás de la del drop invalid.
Perfecto, y aclarado. No tenía ni idea de lo que hacía esa regla de ICMP, pero claro si es una regla para calcular el MTU, es importante. Pues modificadas las prioridades, y me ha quedado así las reglas de filtrado. ¿Cómo lo ves?

1638738699349.png


La de CAPsMAN sólo vale para equipos que tengan wifi incorporado, por si en un momento quisieras manejar la wifi de ese propio equipo vía CAPsMAN, siendo él mismo manager. Si tienes un equipo de sólo cable, esa regla no te vale para nada, la podrías borrar.
La he deshabilitado, por no borrarla. Mi equipo es un hEX sin wifi.

Así que la posición de todo lo que abras implícitamente en input, ha de ir justo por encima de la de "drop all not coming from LAN", y debajo de la que acepta el ICMP. Y, dentro de ese hueco, si tienes que meter varias reglas, sigue esta regla lógica: lo que vaya a recibir más tráfico, primero (por ejemplo, la que acepta la conexión de la vpn, antes de la que acepta que los clientes de la VPN puedan acceder al router).
Entendido, aunque no entiendo por qué la que acepta la conexión a la VPN antes que la de acceso al router. Entiendo que la de la aceptación de la VPN solo va a ocurrir una vez. En cambio, cuando accedas a la VPN, podrás interactuar varias veces con el router (cosa que suelo hacer cuando me conecto a la VPN). ¿No tendrá más tráfico esta regla, que la de aceptación de la VPN, que solo ocurre una vez por cada conexión?

Mírate el manual de WireGuard a fondo, que te va a gustar.
Por supuesto que lo voy a hacer :)

Mil gracias, y saludos!!
 
Las reglas están bien, aunque yo subiría la de la voip justo debajo de la del icmp. Y no, no va a recibir más tráfico la de acceso al router que la de la conexión a la vpn. Por lógica (o al menos yo así lo veo), debería ser justo al contrario, porque no siempre que te conectes a la vpn vas a acceder al router, pero al revés, sólo se puede dar tráfico en esa regla si previamente has establecido una conexión vpn, porque sino el filtro del src-address-list no se cumple.

Simplemente mira los contadores de las reglas, y sales de dudas en poco tiempo.

Saludos!
 
Las reglas están bien, aunque yo subiría la de la voip justo debajo de la del icmp. Y no, no va a recibir más tráfico la de acceso al router que la de la conexión a la vpn. Por lógica (o al menos yo así lo veo), debería ser justo al contrario, porque no siempre que te conectes a la vpn vas a acceder al router, pero al revés, sólo se puede dar tráfico en esa regla si previamente has establecido una conexión vpn, porque sino el filtro del src-address-list no se cumple.

Simplemente mira los contadores de las reglas, y sales de dudas en poco tiempo.
No puedes llevar más razón...

1638743151817.png


Gracias por esta masterclass. Lo que se aprende... :)
 
Arriba