[solucionado] [VPN] Dar acceso a peer a una ip y puerto específicos de mi red, denegar el resto

SmartPhoneLover · 19 Octubre 2022

Hola a todos,

Esta vez vengo con la pregunta de si lo que he configurado hasta ahora, va bien encaminado o no del todo. Pues, el trabajo lo hace correctamente, consiguiendo que el peer que configure en dichas reglas, no tenga acceso a ningún recurso de mi red, ni acceso a internet, y que solo pueda acceder a una dirección IP y a un Puerto de esa IP específicos.

Básicamente, quiero que un usuario, ajeno a mi grupo familiar, pueda tener acceso a un servicio montado en uno de mis servidores, en Docker. Pero, evitando que pueda navegar (lo veo innecesario), y sobretodo, reestringir el acceso al resto de mi red LAN.

Esto es lo que he hecho hasta el momento:
# Creo el interface, distinto al que uso yo en mis dispositivos, simplemente, porque mi interface lo he metido en 'Interface List' para otorgar acceso al router desde cualquier dispositivo por el que me conecte por VPN.
/interface wireguard
add listen-port=<OCULTO> mtu=1420 name=vpn-casa
add listen-port=<OCULTO> mtu=1420 name=vpn-amigo

# Creo el peer asociado al interface de arriba, y he configurado un rango de IP distinto al mío para esa VPN, por si quiere registrar más dispositivos, pues que lo haga sobre una subred para él solo.
/interface wireguard peers
add allowed-address=192.168.101.2/32 interface=vpn-amigo
public-key="<OCULTO>"

# Creo la red 192.168.101.1 para dicha VPN.
/ip address
add address=192.168.100.1/24 comment=VPN interface=vpn-casa network=\
192.168.100.0
add address=192.168.101.1/24 comment=VPN interface=vpn-amigo network=\
192.168.101.0

# Añado las correspondientes reglas en el firewall para impedir el acceso a ninguna interfaz (mato dos pajaros de un tiro, vamos, es lo que entiendo: no internet no lan, en vez de crear dos reglas separadas, una para cada interfaz), y permitir solo a una IP y Puerto.
/ip firewall filter
add action=accept chain=input comment=vpn-casa dst-port=<OCULTO> protocol=udp
add action=accept chain=input comment=vpn-amigo dst-port=<OCULTO> protocol=udp
add action=accept chain=forward dst-address=192.168.10.3 dst-port=10019 \
protocol=tcp src-address=192.168.101.1
add action=drop chain=forward in-interface-list=all src-address=192.168.101.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
in-interface-list=!LAN

pokoyo · 19 Octubre 2022

Vas mal.

Input = tráfico con destino un servicio del propio router
Forward = tráfico con origen o destino los elementos que cuelgan del router.

Y ese Peer lo puedes colgar perfectamente de tu propio servidor road warrior, no tiene por qué ir en una interfaz separada. Y, para aislarlo del mundo, ya que no quieres que si quiera navegue, es tan sencillo como hacerlo con la siguiente línea de drop en forward, a meter a continuación de la última regla de forward por defecto del router. Considero tu colega la 192.168.100.x, perteneciente a la interfaz vpn-casa

Código:

/ip firewall filter
add action=drop chain=forward src-address=192.168.100.x dst-address!=192.168.10.3

Es decir, anula todo tráfico entre esa IP y lo que no sea el servidor en concreto.

Saludos!

SmartPhoneLover · 19 Octubre 2022

Hola pokoyo,

Lo del input y forward, creo tenerlo claro, al menos, según he construido las reglas con anterioridad. O, al menos eso creía yo. Podrías aclararme, en caso de haber hecho algo mal, en qué exactamente? Porque no logro ver dónde las apliqué mal.

Nota: Los servicios en Docker los tengo configurados en red Bridge, no macvlan. Por ello, todos los servicios que puedan existir en dicho servidor, salen por la misma IP del Host, pero usando un puerto diferente.

Me explico:
Las de input las uso para permitir el paso del tráfico de las conexiones VPN por el puerto (externo) que use dicha interfaz, al router. O simplemente, habilitar dicho puerto por donde la VPN va a funcionar.

Código:

/ip firewall filter
add action=accept chain=input comment=vpn-casa dst-port=<OCULTO> protocol=udp

En cambio, las de forward, las uso para permitir la comuncación entre el peer conectado y el servicio que está conectado al router (ajeno a éste).

Código:

add action=accept chain=forward dst-address=192.168.10.3 dst-port=10019 \
protocol=tcp src-address=192.168.100.0/24
# Pero, ésta solo sería válida ahora, si destino esta dirección a él, pues estaría restringiéndome mi propia conexión.
add action=drop chain=forward in-interface-list=all src-address=192.168.100.0/24

Si bien, encuentro muy útil la regla que me has dado, ya que entiendo que ya no me hace falta la segunda que yo metí:

Código:

add action=drop chain=forward in-interface-list=all src-address=192.168.100.x
o
# Si decidía usar una subred a parte.
add action=drop chain=forward in-interface-list=all src-address=192.168.100.0/24

Lo que no consigue la siguiente que me has pasado es, precisamente, bloquear el acceso al resto de servicios que puedan estar alojados en ese servidor. Lo único que consigo es bloquear toda conexión que intente hacerse fuera de esa IP (192.168.10.3), pero nada más.

Código:

/ip firewall filter
add action=drop chain=forward src-address=192.168.100.x dst-address!=192.168.10.3

He intentado adaptarla, pero esto creo que no estoy haciéndolo bien, pues no hace lo que pretendo:

Código:

add action=drop chain=forward dst-address=!192.168.10.3 dst-port=!10019 \
    protocol=tcp src-address=192.168.100.x

pokoyo · 19 Octubre 2022

SmartPhoneLover dijo:
Lo del input y forward, creo tenerlo claro, al menos, según he construido las reglas con anterioridad. O, al menos eso creía yo. Podrías aclararme, en caso de haber hecho algo mal, en qué exactamente? Porque no logro ver dónde las apliqué mal.

Perdona, que confundí una de las reglas y pensé que la tenías en input. El input está bien, incluso puedes ahorrarte la segunda regla y hacer esto:

Código:

/ip firewall filter
add action=accept chain=input comment="vpn: allow wireguard interfaces" dst-port=1234,4321 protocol=udp

Es decir, simplemente aceptar tráfico de dos puertos UDP correspondientes a sendas interfaces, en una única regla. No obstante, como lo pintas también está bien.

En forward, si necesitas restringir también el puerto, no puedes hacerlo como te digo, porque las reglas evalúan las condiciones en un && (and) no como || (or). En ese caso, tendrías que tirar de dos reglas, consecutivas, tal que así:

Código:

/ip firewall filter
add action=accept chain=forward src-address=192.168.100.x dst-address=192.168.10.3 dst-port=10019
add action=drop chain=forward src-address=192.168.100.x

Es decir, acepto de tal IP a cual IP y puerto, pero acto seguido dropeo todo lo demás de esa IP.

Saludos!

SmartPhoneLover · 19 Octubre 2022

pokoyo dijo:

Siempre olvido que puedo meter más de un puerto. Mejor aún!

pokoyo dijo:
En forward, si necesitas restringir también el puerto, no puedes hacerlo como te digo, porque las reglas evalúan las condiciones en un && (and) no como || (or). En ese caso, tendrías que tirar de dos reglas, consecutivas, tal que así:

Código:

/ip firewall filter add action=accept chain=forward src-address=192.168.100.x dst-address=192.168.10.3 dst-port=10019 add action=drop chain=forward src-address=192.168.100.x

Es decir, acepto de tal IP a cual IP y puerto, pero acto seguido dropeo todo lo demás de esa IP.

Funciona perfecto, justo lo que buscaba.

Pero, sigo con la duda, de si el método que apliqué en el primer post, relacionado con la restricción de acceso es igualmente válido a efectos prácticos, en caso de usar una red distinta. Solo por tenerlo en cuenta.
Pues, si mi compañero decide configurar más dispositivos, cada uno tendrá su IP que yo le asigne. Por tanto, si sigo tu forma, aún estando en otra subred, debería crear tantas reglas como IPs registre él. Salvo para drop, que puedo utilizar '192.168.10x.0/24'. Y si decido utilizar mi misma interfaz, tengo que sumar las reglas drop por cada IP suya.
Lo comento, además, porque veo que no es posible especificar un rango de IPs de una red o IPs separadas por comas en una sola regla.

pokoyo · 19 Octubre 2022

SmartPhoneLover dijo:
Siempre olvido que puedo meter más de un puerto. Mejor aún!

Funciona perfecto, justo lo que buscaba.

Pero, sigo con la duda, de si el método que apliqué en el primer post, relacionado con la restricción de acceso es igualmente válido a efectos prácticos, en caso de usar una red distinta. Solo por tenerlo en cuenta.
Pues, si mi compañero decide configurar más dispositivos, cada uno tendrá su IP que yo le asigne. Por tanto, si sigo tu forma, aún estando en otra subred, debería crear tantas reglas como IPs registre él. Salvo para drop, que puedo utilizar '192.168.10x.0/24'. Y si decido utilizar mi misma interfaz, tengo que sumar las reglas drop por cada IP suya.
Lo comento, además, porque veo que no es posible especificar un rango de IPs de una red o IPs separadas por comas en una sola regla.

Metes las IPs en una lista y cambias src-address por src-address-list y en paz. Lo de in-interface=all no lo veo.

Saludos!

SmartPhoneLover · 19 Octubre 2022

pokoyo dijo:
Metes las IPs en una lista y cambias src-address por src-address-list y en paz. Lo de in-interface=all no lo veo.

Saludos!

Ahhh perfecto, otra cosa en la que no había caído. Eso me lo soluciona.
Con respecto a 'in-interface=all', estaba confundido, pensaba que bloqueando LAN y WAN estaba haciendo lo que quería, pero no era como lo tenía en vente.

Muchas gracias pokoyo, nuevamente!

Universo2021 · 19 Octubre 2022

pokoyo dijo:
Perdona, que confundí una de las reglas y pensé que la tenías en input. El input está bien, incluso puedes ahorrarte la segunda regla y hacer esto:

Código:

/ip firewall filter add action=accept chain=input comment="vpn: allow wireguard interfaces" dst-port=1234,4321 protocol=udp

Es decir, simplemente aceptar tráfico de dos puertos UDP correspondientes a sendas interfaces, en una única regla. No obstante, como lo pintas también está bien.

En forward, si necesitas restringir también el puerto, no puedes hacerlo como te digo, porque las reglas evalúan las condiciones en un && (and) no como || (or). En ese caso, tendrías que tirar de dos reglas, consecutivas, tal que así:

Código:

/ip firewall filter add action=accept chain=forward src-address=192.168.100.x dst-address=192.168.10.3 dst-port=10019 add action=drop chain=forward src-address=192.168.100.x

Es decir, acepto de tal IP a cual IP y puerto, pero acto seguido dropeo todo lo demás de esa IP.

Saludos!

Hola

Me surge la pregunta para poder ahorrar líneas en el firewall, ¿no se podría decidir a qué dispositivo va la VPN dentro de la red local desde la parte de cliente, donde poner direcciones permitidas? Más que nada lo digo porque si tengo múltiples servicios que quiero dar a cierta gente tendría que crear tantas líneas de firewall tipo ...

pokoyo dijo:
/ip firewall filter
add action=accept chain=forward src-address=192.168.100.x dst-address=192.168.10.3 dst-port=10019
add action=drop chain=forward src-address=192.168.100.x

Como peers y servicios quiera que tengan acceso y haciendo la lista de firewall bastante grande, ¿Esto sería contraproducente? Si no0 es la mejor manera de hacerlo ¿Cuál sería la forma correcta? Gracias

pokoyo · 19 Octubre 2022

Universo2021 dijo:
Hola

Me surge la pregunta para poder ahorrar líneas en el firewall, ¿no se podría decidir a qué dispositivo va la VPN dentro de la red local desde la parte de cliente, donde poner direcciones permitidas? Más que nada lo digo porque si tengo múltiples servicios que quiero dar a cierta gente tendría que crear tantas líneas de firewall tipo ...

Como peers y servicios quiera que tengan acceso y haciendo la lista de firewall bastante grande, ¿Esto sería contraproducente? Si no0 es la mejor manera de hacerlo ¿Cuál sería la forma correcta? Gracias

No entiendo muy bien a qué te refieres, si me puedes dar un ejemplo, lo vemos.
Siempre que se pueda, es preferible montar listas de direcciones que reglas adicionales de filtrado. Daos cuenta de que por las reglas de filtrando vas saltando de una en una, hasta que entras por una de ellas. Si tienes 25 reglas u entras por la número 25, ese tráfico ha saltado previamente por las otras 24.

Saludos!

Universo2021 · 19 Octubre 2022

pokoyo dijo:
No entiendo muy bien a qué te refieres, si me puedes dar un ejemplo, lo vemos.
Siempre que se pueda, es preferible montar listas de direcciones que reglas adicionales de filtrado. Daos cuenta de que por las reglas de filtrando vas saltando de una en una, hasta que entras por una de ellas. Si tienes 25 reglas u entras por la número 25, ese tráfico ha saltado previamente por las otras 24.

Saludos!

Si por ejemplo tengo xx servicios en una maquina en xx puertos cada uno y y quiero que varios usuarios 5 o 10, los que sean accedan a esos servicios por VPN, me parece una locura crear tantas reglas como servicios quiera dar a xx usuarios.
No sé si estoy liándola más de lo que debo o si me estoy explicando mal, estoy planteando mi red en papel y me surgen dudas a raíz de post que voy viendo para hacer en mi red y creo que esto es lo más lioso y complejo.

Gracias

pokoyo · 19 Octubre 2022

Universo2021 dijo:
Si por ejemplo tengo xx servicios en una maquina en xx puertos cada uno y y quiero que varios usuarios 5 o 10, los que sean accedan a esos servicios por VPN, me parece una locura crear tantas reglas como servicios quiera dar a xx usuarios.
No sé si estoy liándola más de lo que debo o si me estoy explicando mal, estoy planteando mi red en papel y me surgen dudas a raíz de post que voy viendo para hacer en mi red y creo que esto es lo más lioso y complejo.

Gracias

Los usuarios los metes en una lista, y la usas como filtro src-address-list. Si el destino es una misma máquina y no quieres andar creando una regla por puerto, das acceso con origen la lista y destino la máquina y ya lo tienes, con una única regla de filtrado en el firewall. Pero por puerto no puedes crear listas, así que ese control queda en manos del servicio de destino, o te lías a meter una regla por puerto. No hay otra opción, a día de hoy.

Saludos!

Universo2021 · 19 Octubre 2022

pokoyo dijo:
Los usuarios los metes en una lista, y la usas como filtro src-address-list. Si el destino es una misma máquina y no quieres andar creando una regla por puerto, das acceso con origen la lista y destino la máquina y ya lo tienes, con una única regla de filtrado en el firewall. Pero por puerto no puedes crear listas, así que ese control queda en manos del servicio de destino, o te lías a meter una regla por puerto. No hay otra opción, a día de hoy.

Saludos!

Gracias @pokoyo miraré esa fórmula con lo que pretendo hacer.

Saludos

SmartPhoneLover · 19 Octubre 2022

pokoyo dijo:
No entiendo muy bien a qué te refieres, si me puedes dar un ejemplo, lo vemos.
Siempre que se pueda, es preferible montar listas de direcciones que reglas adicionales de filtrado. Daos cuenta de que por las reglas de filtrando vas saltando de una en una, hasta que entras por una de ellas. Si tienes 25 reglas u entras por la número 25, ese tráfico ha saltado previamente por las otras 24.

Saludos!

En respuesta a...

Universo2021 dijo:
Me surge la pregunta para poder ahorrar líneas en el firewall, ¿no se podría decidir a qué dispositivo va la VPN dentro de la red local desde la parte de cliente, donde poner direcciones permitidas? Más que nada lo digo porque si tengo múltiples servicios que quiero dar a cierta gente tendría que crear tantas líneas de firewall tipo ...

Como peers y servicios quiera que tengan acceso y haciendo la lista de firewall bastante grande, ¿Esto sería contraproducente? Si no0 es la mejor manera de hacerlo ¿Cuál sería la forma correcta? Gracias

Según la recomendación de pokyo, esto es lo que entiendo que estaría bien hacer para evitar crear tantas reglas como usuarios (IPs), y/o servicios (puertos por IP) existan. Pero, teniendo en cuenta que todos los usuarios que definamos en dicha lista van a hacer uso de los mismos servicios.
1. Por una parte, crear un listado de las IPs de cada usuario.
2. Por otro, agrupar los puertos, dentro esa lista de IPs.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

pokoyo dijo:
Los usuarios los metes en una lista, y la usas como filtro src-address-list. Si el destino es una misma máquina y no quieres andar creando una regla por puerto, das acceso con origen la lista y destino la máquina y ya lo tienes, con una única regla de filtrado en el firewall. Pero por puerto no puedes crear listas, así que ese control queda en manos del servicio de destino, o te lías a meter una regla por puerto. No hay otra opción, a día de hoy.

Saludos!

En respuesta a...

Universo2021 dijo:
Si por ejemplo tengo xx servicios en una maquina en xx puertos cada uno y y quiero que varios usuarios 5 o 10, los que sean accedan a esos servicios por VPN, me parece una locura crear tantas reglas como servicios quiera dar a xx usuarios.
No sé si estoy liándola más de lo que debo o si me estoy explicando mal, estoy planteando mi red en papel y me surgen dudas a raíz de post que voy viendo para hacer en mi red y creo que esto es lo más lioso y complejo.

Si lo que quieres es permitir el acceso a diferentes servicios que puedan estar alojados en diferentes servidores, se podrían agregar sus direcciones en 'Addres Lists', bajo el nombre de 'vpn-public-servers' (ejemplo). Luego, en las reglas, simplemente editando las que puse arriba, en vez de indicar las IPs a mano (varias reglas), indicas la lista de todos los servidores que alojen los servicios que van a usar tus usuarios.

Si lo de arriba es válido (¿?), sobretodo el tema de puertos (@pokoyo), deberías asegurarte que en unos servidores no expones nada en los puertos o rangos de puertos declarados para el otro, y viceversa. Pero, esa es la solución que se me ocurre, un poco cutre, pero viable si sigues queriendo usar solo unas pocas reglas, y si por supuesto, es una regla válida a fines prácticos.

SmartPhoneLover · 21 Octubre 2022

Bueno, consideraría el hilo como solucionado, pues ya conozco más de una forma de conseguir lo mismo. Una más apta que otra, o cada una adaptada a ciertas circumstancias, pero al fin y al cabo, funcionales.

Sin embargo, tengo algunas preguntas más, si no es mucha molestia...

Pregunta 1
Por un lado, la otra parte (peer), comunica que el comportamiento de la conexión, o más bien, cómo se cargan las direcciones a las que accede, no es del todo correcto. Y, no debería de ser así. Me explico...

Actualmente, he configurado las reglas para que bloquee todo acceso a mi red (incluido internet), salvo, la dirección del servidor y un puerto espécifico (192.168.10.3:10019). Pero, que tampoco tendrá acceso al servidor como tal, solo a ese servicio de ese puerto específico.

El problema o bug en el cortafuegos del MT que describe el cliente, es que al intentar acceder a cualquier otra dirección de mi LAN que no sea a la que tiene acceso (solo), el navegador se queda cargando dicha dirección por un rato, hasta que porfin comunica que la petición no ha podido tramitarse y ya le salta el mensaje de que la página/servicio no está disponible. Según el cliente, no debería de ocurrir esto, sino, que al intentar acceder a una dirección a la que, simplemente, no tiene acceso por parte del propio router, debería de saltar el aviso de recurso o página no disponible de manera instantánea, justo después de darle al ENTER para acceder a ese segmento de red bloqueado.

Pero, yo pienso que el comportamiento que percibe la otra parte, es normal. Creo, que para que el navegador lanze el mensaje de que no se pudo acceder a la dirección solicitada de manera instantánea, o bien, tiene que haber algún otro servicio corriendo que detecte que ese segmento de red no está disponible, y así devolver la respuesta correspondiente al navegador (código error); o se debería ajustar el timeout para las peticiones en el propio navegador, para que no duren no más de 1-3 segundo.

Tras hacer pruebas, el cliente no puede acceder a ningún servicio ni elemento de mi red que no sea el indicado arriba, según he configurado las reglas en el firewall. Por tanto, considero que todo está funcionando como debe, y que el modo y retraso que se produce en su navegador con respecto a una petición (bloqueada) es normal.

Pregunta 2

pokoyo dijo:
En forward, si necesitas restringir también el puerto, no puedes hacerlo como te digo, porque las reglas evalúan las condiciones en un && (and) no como || (or). En ese caso, tendrías que tirar de dos reglas, consecutivas, tal que así:

Código:

/ip firewall filter add action=accept chain=forward src-address=192.168.100.x dst-address=192.168.10.3 dst-port=10019 add action=drop chain=forward src-address=192.168.100.x

Es decir, acepto de tal IP a cual IP y puerto, pero acto seguido dropeo todo lo demás de esa IP.

Con respecto a: las reglas evalúan las condiciones en un && (and) no como || (or), entendemos los dos implicados, que la siguiente regla debería de funcionar, sustituyendo a esas otras dos:

Código:

add action=drop chain=forward dst-address=!192.168.10.3 dst-port=!10019 protocol=tcp src-address=192.168.100.x

Según estamos interpretando dicha regla, esto es lo que entendemos:
Denegar (action=drop) toda petición de acceso que no pertenezca a 192.168.10.3 (dst-address=!192.168.10.3), al mismo tiempo de impedir acceder al resto de puertos disponibles dentro de la misma IP, salvo el 10019 (dst-port=!10019), siempre y cuando (AND), la conexión se establezca por 192.168.100.x.

Pues, lo que pasa es justamente lo contrario, el peer puede acceder absolutamente a todos los recursos de mi red, sin restricción.

¿Es correcto dicho razonamiento? Estamos tratando a todos los elementos configurados como un AND.

Pregunta 3
Tras haber configurado todo, a diferencia de cuando me conecto yo con mis equipos, cuando se conecta y desconecta el peer (amigo), el handshake no es detectado. Siempre están en cero. Pero la conexión se establece, pues puede acceder al recurso en cuestión.

A qué puede deberse esto?

pokoyo · 22 Octubre 2022

SmartPhoneLover dijo:
Pregunta 1
Por un lado, la otra parte (peer), comunica que el comportamiento de la conexión, o más bien, cómo se cargan las direcciones a las que accede, no es del todo correcto. Y, no debería de ser así. Me explico...

Actualmente, he configurado las reglas para que bloquee todo acceso a mi red (incluido internet), salvo, la dirección del servidor y un puerto espécifico (192.168.10.3:10019). Pero, que tampoco tendrá acceso al servidor como tal, solo a ese servicio de ese puerto específico.

El problema o bug en el cortafuegos del MT que describe el cliente, es que al intentar acceder a cualquier otra dirección de mi LAN que no sea a la que tiene acceso (solo), el navegador se queda cargando dicha dirección por un rato, hasta que porfin comunica que la petición no ha podido tramitarse y ya le salta el mensaje de que la página/servicio no está disponible. Según el cliente, no debería de ocurrir esto, sino, que al intentar acceder a una dirección a la que, simplemente, no tiene acceso por parte del propio router, debería de saltar el aviso de recurso o página no disponible de manera instantánea, justo después de darle al ENTER para acceder a ese segmento de red bloqueado.

Pero, yo pienso que el comportamiento que percibe la otra parte, es normal. Creo, que para que el navegador lanze el mensaje de que no se pudo acceder a la dirección solicitada de manera instantánea, o bien, tiene que haber algún otro servicio corriendo que detecte que ese segmento de red no está disponible, y así devolver la respuesta correspondiente al navegador (código error); o se debería ajustar el timeout para las peticiones en el propio navegador, para que no duren no más de 1-3 segundo.

Tras hacer pruebas, el cliente no puede acceder a ningún servicio ni elemento de mi red que no sea el indicado arriba, según he configurado las reglas en el firewall. Por tanto, considero que todo está funcionando como debe, y que el modo y retraso que se produce en su navegador con respecto a una petición (bloqueada) es normal.

Lo primero, dejar claro un cosa: la red la manejas tú, y eres tú quien tiene que certificarla. "El cliente" no puede decirte lo que en una red es correcto o no, porque se supone que el experto en redes eres tú. Aquí lo tienes todo perfectamente configurado, cumples con lo que has pedido: el cliente no tiene acceso al recurso. Ahora bien, ese tipo de denegación se puede hacer de varias maneras, y para ello tienes que estudiar las distintas acciones que te permite una regla de firewall. Te doy una pista: un drop es una denegación silenciosa, mientras que hay otro tipo de denegaciones que sí que reportan un estado al navegador. Tienes más info aquí: https://help.mikrotik.com/docs/display/ROS/Filter

SmartPhoneLover dijo:
Según estamos interpretando dicha regla, esto es lo que entendemos:
Denegar (action=drop) toda petición de acceso que no pertenezca a 192.168.10.3 (dst-address=!192.168.10.3), al mismo tiempo de impedir acceder al resto de puertos disponibles dentro de la misma IP, salvo el 10019 (dst-port=!10019), siempre y cuando (AND), la conexión se establezca por 192.168.100.x.

Pues, lo que pasa es justamente lo contrario, el peer puede acceder absolutamente a todos los recursos de mi red, sin restricción.

¿Es correcto dicho razonamiento? Estamos tratando a todos los elementos configurados como un AND.

Me retracto, de entrada te dije que no se podía hacer con una sóla regla (las dobles negaciones a veces dan la lata), pero sí se puede.
Acabo de probarlo en mi propia red y, como bien te digo, las condiciones son independientes y se evalúan con como &&. Es decir, la regla:

Código:

/ip firewall filter
add action=drop chain=forward dst-address=!192.168.10.3 dst-port=!10019 protocol=tcp src-address=192.168.100.5

Bloqueará todo tráfico con origen la 192.168.100.5, salvo el tráfico con destino 192.168.10.3 y puerto 10019. Si no lo hace, puede que no hayas puesto esa regla donde toca, recuerda que el firewall tiene un orden.

SmartPhoneLover dijo:
Pregunta 3
Tras haber configurado todo, a diferencia de cuando me conecto yo con mis equipos, cuando se conecta y desconecta el peer (amigo), el handshake no es detectado. Siempre están en cero. Pero la conexión se establece, pues puede acceder al recurso en cuestión.

A qué puede deberse esto?

Probablemente sea un mero problema visual. Revisa sin vía winbox o terminal tienes el mismo resultado. Si hay comunicación, por descontado hay handshake.

Saludos!

SmartPhoneLover · 22 Octubre 2022

pokoyo dijo:
Lo primero, dejar claro un cosa: la red la manejas tú, y eres tú quien tiene que certificarla. "El cliente" no puede decirte lo que en una red es correcto o no, porque se supone que el experto en redes eres tú. Aquí lo tienes todo perfectamente configurado, cumples con lo que has pedido: el cliente no tiene acceso al recurso. Ahora bien, ese tipo de denegación se puede hacer de varias maneras, y para ello tienes que estudiar las distintas acciones que te permite una regla de firewall. Te doy una pista: un drop es una denegación silenciosa, mientras que hay otro tipo de denegaciones que sí que reportan un estado al navegador. Tienes más info aquí: https://help.mikrotik.com/docs/display/ROS/Filter

Genial, ya conseguí configurar la regla para que, del lado del cliente, sea notificado de manera instantánea del rechazo a su intento de conexión a un servicio bloqueado: Action: REJECT. Además, ya me he informado de cómo funcionan, aunque sea por encima, en comparación con DROP. Link muy útil!

pokoyo dijo:
Acabo de probarlo en mi propia red y, como bien te digo, las condiciones son independientes y se evalúan con como &&. Es decir, la regla:

Código:

/ip firewall filter add action=drop chain=forward dst-address=!192.168.10.3 dst-port=!10019 protocol=tcp src-address=192.168.100.5

Bloqueará todo tráfico con origen la 192.168.100.5, salvo el tráfico con destino 192.168.10.3 y puerto 10019. Si no lo hace, puede que no hayas puesto esa regla donde toca, recuerda que el firewall tiene un orden.

Esa es la regla que había probado al principio, pero no me funciona. Y la he posicionado (al final) de la última (por defecto) del router:

También he probado a ponerla entre las de vpn, más arriba: 6-8, pero tampoco hace nada. Rechaza todo fuera de la 192.168.10.3, pero me permite acceder a todos los servicios que hay en dicha IP, incluso al mismo servidor.

pokoyo dijo:
Probablemente sea un mero problema visual. Revisa sin vía winbox o terminal tienes el mismo resultado. Si hay comunicación, por descontado hay handshake.

He exportado el valor de los handshake de los peers por terminal, y no reportan nada. Todos en 00:00:00.
Lo raro, es que cuando un Android se conecta, si se registra, pero cuando un PC (windows 10) se conecta, no.

pokoyo · 23 Octubre 2022

¿qué pintan tres reglas de forward, en medio de las reglas de input? Las reglas se procesan en orden, dentro de su mismo chain. Pero no consigues más que confusión intercalando reglas de distinto chain. Pásame un export completo del equipo y revisamos esta parte, que me da que por ahí van los tiros de por qué no te funciona como debe.

Saludos!

SmartPhoneLover · 23 Octubre 2022

Si, lo sé, he hecho algo incomprensible con lo de las reglas

.

Aquí mando el export solicitado:

Código:

# oct/23/2022 12:16:59 by RouterOS 7.6
# software id = 7MD6-CZR2

/interface bridge
add admin-mac=<OCULTO> auto-mac=no name=bridge
add name=bridge-vlans vlan-filtering=yes

/interface ethernet
set [ find default-name=ether1 ] name=ether1-wan
set [ find default-name=ether2 ] name=ether2-switch
set [ find default-name=ether3 ] name=ether3-ap

/interface wireguard
add listen-port=51820 mtu=1420 name=vpn-casa
add listen-port=51821 mtu=1420 name=vpn-amigo

/interface vlan
add interface=bridge-vlans name=vlan-guests vlan-id=30
add interface=ether1-wan name=vlan-isp vlan-id=832

/interface list
add name=WAN
add name=LAN

/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
add authentication-types=wpa2-psk mode=dynamic-keys name=protegido \
    supplicant-identity=""
add authentication-types=wpa2-psk mode=dynamic-keys name=invitados \
    supplicant-identity=""

/interface wireless
set [ find default-name=wlan1 ] band=2ghz-g/n country=spain \
    default-authentication=no disabled=no distance=indoors frequency=2437 \
    mode=ap-bridge name=wlan1-2g security-profile=protegido ssid=\
    <OCULTO> wps-mode=disabled
set [ find default-name=wlan2 ] band=5ghz-n/ac channel-width=20/40/80mhz-eCee \
    country=spain default-authentication=no disabled=no distance=indoors \
    frequency=5200 mode=ap-bridge name=wlan2-5g security-profile=protegido \
    ssid=<OCULTO>-5G wps-mode=disabled
add default-authentication=no keepalive-frames=disabled mac-address=\
    2E:C8:1B:C6:79:D5 master-interface=wlan1-2g multicast-buffering=disabled \
    name=wlan3-2g security-profile=invitados ssid=<OCULTO>-INVITADOS vlan-id=30 \
    vlan-mode=use-tag wds-cost-range=0 wds-default-cost=0 wps-mode=disabled

/ip pool
add name=pool-lan ranges=192.168.10.11-192.168.10.254
add name=pool-guests ranges=192.168.30.2-192.168.30.254

/ip dhcp-server
add address-pool=pool-lan interface=bridge name=dhcp-bridge
add address-pool=pool-guests interface=vlan-guests name=dhcp-guests

/interface bridge port
add bridge=bridge interface=ether2-switch
add bridge=bridge interface=ether3-ap
add bridge=bridge interface=ether4
add bridge=bridge interface=ether5
add bridge=bridge interface=wlan1-2g
add bridge=bridge interface=wlan2-5g
add bridge=bridge-vlans interface=wlan3-2g pvid=30

/ip neighbor discovery-settings
set discover-interface-list=LAN

/interface bridge vlan
add bridge=bridge-vlans tagged=bridge-vlans,wlan3-2g vlan-ids=30

/interface list member
add interface=bridge list=LAN
add interface=ether1-wan list=WAN
add interface=*F list=LAN
add interface=vpn-casa list=LAN

/interface wireguard peers
add allowed-address=192.168.100.2/32 comment="Redmi Note 7" interface=\
    vpn-casa public-key="<OCULTO>"
add allowed-address=192.168.100.3/32 comment="Portátil" interface=vpn-casa \
    public-key="<OCULTO>"
add allowed-address=192.168.101.2/32 comment=amigo interface=vpn-amigo \
    public-key="<OCULTO>"

/ip address
add address=192.168.10.1/24 comment=Lan interface=bridge network=192.168.10.0
add address=192.168.100.1/24 comment=VPN interface=vpn-casa network=\
    192.168.100.0
add address=192.168.30.1/24 interface=vlan-guests network=192.168.30.0
add address=192.168.101.1/24 interface=vpn-amigo network=192.168.101.0

/ip dhcp-client
add comment=defconf interface=vlan-isp use-peer-dns=no

/ip dhcp-server network
add address=192.168.10.0/24 comment=Lan dns-server=192.168.10.5 gateway=\
    192.168.10.1
add address=192.168.30.0/24 gateway=192.168.30.1

/ip firewall filter
add action=accept chain=input comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment=\
    "defconf: accept to local loopback (for CAPsMAN)" disabled=yes \
    dst-address=127.0.0.1
add action=accept chain=input comment=vpn dst-port=51820,51821 protocol=udp
add action=accept chain=forward dst-address=192.168.10.2 dst-port=8096 \
    protocol=tcp src-address=192.168.101.0/24
add action=accept chain=forward dst-address=192.168.10.3 dst-port=10019 \
    protocol=tcp src-address=192.168.101.0/24
add action=reject chain=forward reject-with=icmp-network-unreachable \
    src-address=192.168.101.0/24
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
    in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
    ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
    ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related hw-offload=yes
add action=accept chain=forward comment=\
    "defconf: accept established,related, untracked" connection-state=\
    established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=drop chain=forward comment=\
    "defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
    connection-state=new in-interface-list=WAN

/ip firewall nat
add action=masquerade chain=srcnat comment="NAT Loopback (2)" disabled=yes \
    dst-address=192.168.1.0/24 src-address=192.168.1.0/24
add action=masquerade chain=srcnat comment="defconf: masquerade" \
    ipsec-policy=out,none out-interface=vlan-isp
add action=dst-nat chain=dstnat comment=qBittorrent dst-port=<OCULTO> \
    in-interface=vlan-isp protocol=tcp to-addresses=192.168.10.2 to-ports=\
    6881
add action=dst-nat chain=dstnat comment="Nginx Proxy (1)" disabled=yes \
    dst-port=80 in-interface=vlan-isp protocol=tcp to-addresses=192.168.10.3 \
    to-ports=10080
add action=dst-nat chain=dstnat comment="Nginx Proxy (2)" disabled=yes \
    dst-port=443 in-interface=vlan-isp protocol=tcp to-addresses=192.168.10.3 \
    to-ports=10443
add action=dst-nat chain=dstnat comment="NAT Loopback (1)" disabled=yes \
    dst-address-list=public-ip dst-port=443 protocol=tcp to-addresses=\
    192.168.1.125 to-ports=10443

/ipv6 firewall address-list
add address=::/128 comment="defconf: unspecified address" list=bad_ipv6
add address=::1/128 comment="defconf: lo" list=bad_ipv6
add address=fec0::/10 comment="defconf: site-local" list=bad_ipv6
add address=::ffff:0.0.0.0/96 comment="defconf: ipv4-mapped" list=bad_ipv6
add address=::/96 comment="defconf: ipv4 compat" list=bad_ipv6
add address=100::/64 comment="defconf: discard only " list=bad_ipv6
add address=2001:db8::/32 comment="defconf: documentation" list=bad_ipv6
add address=2001:10::/28 comment="defconf: ORCHID" list=bad_ipv6
add address=3ffe::/16 comment="defconf: 6bone" list=bad_ipv6

/ipv6 firewall filter
add action=accept chain=input comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="defconf: accept ICMPv6" protocol=\
    icmpv6
add action=accept chain=input comment="defconf: accept UDP traceroute" port=\
    33434-33534 protocol=udp
add action=accept chain=input comment=\
    "defconf: accept DHCPv6-Client prefix delegation." dst-port=546 protocol=\
    udp src-address=fe80::/10
add action=accept chain=input comment="defconf: accept IKE" dst-port=500,4500 \
    protocol=udp
add action=accept chain=input comment="defconf: accept ipsec AH" protocol=\
    ipsec-ah
add action=accept chain=input comment="defconf: accept ipsec ESP" protocol=\
    ipsec-esp
add action=accept chain=input comment=\
    "defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=input comment=\
    "defconf: drop everything else not coming from LAN" in-interface-list=\
    !LAN
add action=accept chain=forward comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=drop chain=forward comment=\
    "defconf: drop packets with bad src ipv6" src-address-list=bad_ipv6
add action=drop chain=forward comment=\
    "defconf: drop packets with bad dst ipv6" dst-address-list=bad_ipv6
add action=drop chain=forward comment="defconf: rfc4890 drop hop-limit=1" \
    hop-limit=equal:1 protocol=icmpv6
add action=accept chain=forward comment="defconf: accept ICMPv6" protocol=\
    icmpv6
add action=accept chain=forward comment="defconf: accept HIP" protocol=139
add action=accept chain=forward comment="defconf: accept IKE" dst-port=\
    500,4500 protocol=udp
add action=accept chain=forward comment="defconf: accept ipsec AH" protocol=\
    ipsec-ah
add action=accept chain=forward comment="defconf: accept ipsec ESP" protocol=\
    ipsec-esp
add action=accept chain=forward comment=\
    "defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=forward comment=\
    "defconf: drop everything else not coming from LAN" in-interface-list=\
    !LAN

pokoyo · 23 Octubre 2022

Comenta todo tu firewall y mete este, a ver qué hace. He eliminado la regla de CAPsMAN que tenías deshabilitada, las dos de IPSec que no usas, ya que estás con Wireguard, y las he puesto en su correspondiente orden. Ahora el equipo 192.168.101.2 debería llegar únicamente a la 192.168.10.3, puerto 10019. La vpn-casa llega a todo.

Código:

/ip firewall filter
add action=accept chain=input comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment=vpn dst-port=51820,51821 protocol=udp
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
    in-interface-list=!LAN
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related hw-offload=yes
add action=accept chain=forward comment=\
    "defconf: accept established,related, untracked" connection-state=\
    established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=drop chain=forward comment=\
    "defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
    connection-state=new in-interface-list=WAN
add action=reject reject-with=icmp-network-unreachable chain=forward \
    dst-address=!192.168.10.3 dst-port=!10019 protocol=tcp src-address=192.168.101.2

SmartPhoneLover · 23 Octubre 2022

Comprobado, y era exactamente como había probado en uno de los tests que hice, habiendo deshabilitado las reglas de accept (6 y 7).
Se comporta como te comenté: me impide acceder al resto de recursos de la LAN, incluido salida a internet, pero sigo pudiendo acceder a todos los servicios de 192.168.10.3, incluido a la propia 192.168.10.3.

[solucionado] [VPN] Dar acceso a peer a una ip y puerto específicos de mi red, denegar el resto

Usuari@ ADSLzone

Moderador ADSLZone - Mikrotik ★★★★★

Usuari@ ADSLzone

Moderador ADSLZone - Mikrotik ★★★★★

Usuari@ ADSLzone

Moderador ADSLZone - Mikrotik ★★★★★

Usuari@ ADSLzone

Usuari@ ADSLzone

Moderador ADSLZone - Mikrotik ★★★★★

Usuari@ ADSLzone

Moderador ADSLZone - Mikrotik ★★★★★

Usuari@ ADSLzone

Usuari@ ADSLzone

Usuari@ ADSLzone

Moderador ADSLZone - Mikrotik ★★★★★

Usuari@ ADSLzone

Moderador ADSLZone - Mikrotik ★★★★★

Usuari@ ADSLzone

Moderador ADSLZone - Mikrotik ★★★★★

Usuari@ ADSLzone

Similar threads