MANUAL: EoiP sobre IKEv2 site to site

El objetivo es hacer un túnel EoiP sobre un túnel Ipsec/IKEv2 con RSA (certificados) entre dos routers MK, de modo que un bridge del router remoto quede integrado totalmente en un bridge del router de HQ (equivalente a esto, se monta automáticamente si creamos un túnel EoiP y le marcamos que sea sobre Ipsec. Pero así, lo que se monta, no es Ikev2). Este bridge lo denominaremos IPTV-bridge, mientras que los bridges "locales" de cada router los podemos llamar como queramos (por ejemplo, LAN-bridge, en HQ, y Playa-bridge, en el router remoto). Partimos, en el router de HQ (en mi caso un hEX), de la configuración con dos bridges, triple VLAN de Movistar, tal y como se indica en el hilo de configuraciones básicas.

Y otro router remoto, "Playa" (en mi caso un hAP), con una configuración estándar de QuickSet, sólo que el acceso WAN lo adaptamos, lógicamente, a lo que diga el ISP de ese lugar; y, eso sí, le ponemos como dirección del Playa-bridge 192.168.18.0/24, para no confundirnos con la del HQ (que es 192.168.88.0/24).

Pues empezamos con el router de HQ

A esta configuración que decía, le aplicamos primero los cambios que indica @pokoyo en el manual "Mikrotik, IKEv2 VPN a fondo" para el IKEv2 en Road Warrior (sólo los de RW, los de site-to-site no son necesarios, a menos que tengamos un tercer router y queramos conectarlo también, pero con el túnel site-to-site Ikev2 simple, ya descrito por @pokoyo; pero no pasa nada si se queda también es<a otra configuración, pues los pasos que voy a exponer no son incompatibles).

1-a) Vamos a crear un nuevo certificado para el router remoto "Playa" (supongo que tenéis ya creados previamente los certificados raíz "VPN CA" y del servidor "VPN Server", según el manual de @pokoyo más arriba. Si no, los creáis, pues son imprescindibles):

1-b) Lo firmamos:

1-c) ...y lo exportamos:

2-a) Ahora vamos a crear un tercer bridge "loopback" en el router HQ. Este es un bridge "tonto", con una dirección de red propia, que solo va a recibir, como veréis, un extremo del túnel IPSEC, pero sobre esa dirección vamos a montar después el túnel EoiP:

2-b) Ahora creamos una subred para el túnel y le damos una dirección al bridge "loopback":

3) Ahora vamos a configurar el túnel Ipsec Ikev2. Pongo en comentarios (copiados de @pokoyo) los pasos de la parte común con Road Warrior, por si no los hubierais hecho, pues son imprescindibles:

3-a) Creamos su propio mode-config. Como veis, lo que hacemos es inyectar el tráfico por el túnel hasta el extremo remoto 192.168.99.2 de la red del bridge "loopback":

3-b) Los siguientes son pasos comunes con la configuración RW, pero es imprescindible tenerlos configurados, si no lo habéis hecho previamente:

3-c) Este paso es común con RW, pero lo pongo porque yo difiero de la configuración de @pokoyo: aquí en el lado HQ tengo deshabilitado send-initial-contact=no. Esto es porque, con algunos dispositivos clientes, no me funcionaba bien el RW en alguna fase. Además, como veréis, en el lado remoto "Playa", SI lo tengo habilitado: con ello la iniciativa de levantar el enlace se la dejo al lado remoto, que es el que puede estar desconectado o apagado sin uso más frecuentemente:

3-d) Damos de alta la identidad del lado remoto "Playa", apuntando a su mode-config:

3-e) Por fin, creamos la plantilla de la política para este túnel. Fijaos que lo hacemos entre las dos direcciones de la red .99, es decir, el lado de loopback (.99.1) y el lado remoto (.99.1):

4-a) Por último, creamos el túnel Eoip sobre el túnel Ipsec/IkeV2 recién creado. Le he puesto un número MAC propio dentro del rango libre, para que sea único (es buena práctica. Haré lo mismo con el otro extremo Playa). Lo importante es que ambos lados tengan el mismo número de túnel: yo he puesto 16. Y se hace entre las dos direcciones de la red .99 creada ad-hoc:

4-b) Ya sólo queda añadir la nueva interfaz a nuestro IPTV-bridge:

Y con esto hemos terminado en el lado HQ.

Vamos al lado remoto "Playa"

# Punto previo: Si no tenéis puesto DDNS hay que ponerlo. Ya sabéis:

5-a) Lo primero, creamos el IPTV-bridge en este router:

5-b) ...y lo metemos en la lista LAN:

6-a) Vamos a crear el túnel Ipsec/Ike2 en este lado. Lo primero, su mode-config. Como veis, es distinto del del lado HQ:

6-b) Voy copiando casi la misma configuración de @pokoyo para el router "branch" del "Manual: Mikrotik, IKEv2 VPN a fondo". Nuevo template group, idéntico al del router HQ

6-c) Perfil, idéntico al del servidor

6-d) Peer, apuntando a la dirección de nuestro dominio o IP estática del router HQ, con send-initial-contact=yes

6-e) Proposal, idéntico al del router de HQ

6-f) Identity, en este caso especificando únicamente el certificado cliente:

6-g) Y por fin, la política. La hacemos aquí en modo template, y también, poniendo las direcciones de los dos extremos:

7-a) Ahora toca crear en este lado el túnel EoiP por encima del recién creado. Fijaos que el MAC es distinto, pero el número de túnel el mismo que en HQ:

7-b) ... añadimos esta nueva interfaz al puente:

7-c) ...y le añadimos además los puertos físicos ether o wireless del router que queramos, que estarán como directamente "en el router HQ" (que antes los hemos quitado del Playa-bridge, el bridge credo con el QuickSet, si es que le hubiéramos dejado añadir todos los de la lan por defecto. El como quitarlos es fácil: vais al puerto correspondiente en /interface bridge port y lo quitáis), en este caso, el ether4 solo:

8 ) Sólo queda levantar un cliente DHCP para que, a través de los túneles, le asigne una dirección de la subred de IPTV-bridge en HQ, en este lado al IPTV-bridge y a los clientes que se conecten a su puerto ether4 (o a las interfaces locales, como una wireless, que hayamos añadido a IPTV-bridge en este router remoto Playa"). Como veis, SI pedimos que le asigne el mismo DNS que tuviera asignado IPTV-bridge en el router HQ:

Con esto estaría listo el router remoto "Playa"

Reglas firewall

Por último, y muy importante: No olvides poner las reglas de firewall correspondientes, tanto en HQ como en Playa, como aconsejaba @pokoyo:

9) En el lado HQ:

10) Y en el lado remoto "Playa":

Y, listo!. Ahora debería levantarse el túnel Eoip en ambos lados y también el Ipsec. Si no fuera así, comprobad que el Playa ha cogido su ip pública en /ip cloud y si no estuviera, hacéis "force update". Después, vais a ip -> ipsec -> installed SAs y hacéis un "flush". Con esto obligáis a levantar el túnel Ike2/Ipsec. Ahora, debería funcionar.

No he puesto las reglas de TCP MSS, pues el túnel EoiP tiene ya una opción por defecto, que creo que podría ser suficiente, al menos para EoiP, pero como hay dos túneles... no sé...; pero antes debo estudiarlo y calcular exactamente la dimensión del doble encapsulamiento, y probarlo en real, que no lo he hecho.

Si lo probáis, veréis que este túnel EoiP es más rápido y eficiente que el EoiP sobre Ipsec automático, tanto al levantarse el enlace, como en su funcionamiento. Además, si el extremo remoto está desconectado, no hace falta deshabilitar la interfaz Eoip ni el loopback: se quedan esperando sin dar la lata. Veréis que no hay mensajes de error si el extremo hAP (Playa) está caído o desconectado. Por supuesto que al basarse en certificados RSA en vez de en clave compartida es también más seguro.

Espero que os sea útil.
Suerte!!!

Chinchetazo!

Buenas. Para los de movistar funcionará, porque interpreto que tienen varios bridges y configuraciones específicas en los mismos, pero para los de "solo fibra" (bridge único LAN) (sin tv, ni telefono) nos fallan algunos pasos. A mi al menos no me funciona.

Salu2!! y gracias por el tutorial

furny dijo:

No he puesto las reglas de TCP MSS, pues el túnel EoiP tiene ya una opción por defecto, que creo que podría ser suficiente, al menos para EoiP, pero como hay dos túneles... no sé...; pero antes debo estudiarlo y calcular exactamente la dimensión del doble encapsulamiento, y probarlo en real, que no lo he hecho.

Haz clic para expandir...

No es necesario. Me queda la duda si en este caso poner el túnel con el mtu a 1500 como solemos hacer, o dejar el tamaño de mtu que te planta él por defecto. Habrá que probarlo y ver si hay segmentación y retransmisión de paquetes.

Saludos!

Dado que en el router HQ carezco de un segundo bridge, creé uno siguiendo los pasos de la configuración para movistar. Desconozco si está bien hecho, sea como fuere, no ha funcionado:


Salu2!!

Si no tienes un segundo bridge en HQ, no es necesario crearlo. La interfaz Eoip que creas al final del proceso en el router HQ, la metes en el bridge único y listo.Debería funcionar, sin problemas. Eso si, es imprescindible crear el bridge tonto loopback. Lo de partir de configuraciones con dos bridges en cada router es porque yo lo ha probado así para la aplicación que mas me interesa, que es llevar tráfico IPTV de forma independiente y asilada del resto de la red, para evitar que el multicast interfiera. Pero tambien tiene una gran ventaja usarlo para llevar tráfico internet normal solo, con Voip o con IPTV mezclado, por supuesto, donde solo habria un bridge por router.

Otra cosa es que quieras, en el router remoto, tener dos bridges, uno con el túnel, cuyos puertos estarían “como conectados directamente al bridge de HQ” y otro brigde local para salir desde sus puertos al ISP local directamente. Yo lo tengo así precisamente, y es lo que explico y configuro en el manual. Pero también puedes tener un único bridge en el router remoto, en cuyo caso todos los puertos del router estarían virtualmente conectados al bridge del router HQ.

Con respecto al tamaño del MTU, yo le pondría 1500, de todas formas, pues el valor por defecto de Eoip es de 65 y eso es muy poco y seguro que hay multitud de fragmentaciones y podría ir muy mal. Otra cosa es si hay que ajustar el TCP MSS para optimizar más el rendimiento. Cuando tenga tiempo, hago unos cálculos y unas pruebas para ver la cosa.

Si tenéis dificultades en montar el túnel, lo estudiamos..

furny dijo:

Con respecto al tamaño del MTU, yo le pondría 1500, de todas formas, pues el valor por defecto de Eoip es de 65 y eso es muy poco y seguro que hay multitud de fragmentaciones y podría ir muy mal. Otra cosa es si hay que ajustar el TCP MSS para optimizar más el rendimiento. Cuando tenga tiempo, hago unos cálculos y unas pruebas para ver la cosa.

Haz clic para expandir...

No hombre, el MTU por defecto del túnel EoIP es 1458


Saludos!

pokoyo dijo:

No hombre, el MTU por defecto del túnel EoIP es 1458

Ver el adjunto 81450
Saludos!

Haz clic para expandir...

Hummm... Vale. Seguro que tienes razón. Ya me extrañaba. Es que cuando con el Webfig configuro un Eoip, sea cual sea el router, me ponía 64 siempre, al principio, en la casilla de MTU, al abrirla para poner un valor. Como en el manual no dice nada, daba por supuesto que ese 64 era el valor por defecto. Pero por lo que muestras, debe ser 1458. Eso tiene más sentido.

Lo único que dice el manual es que recomienda ponerlo a 1500 para evitar refragmentaciones de tramas ethernet, cuyo valor de 1500 es el habitual. Dado que el propósito es unir dos bridges, y estos funcionan con 1500, me parece que no hay otra que seguir la recomendación. No obstante, tengo claro que hace falta estudiar este asunto de los valores adecuados de MTU y MSS para este túnel.

furny dijo:

Hummm... Vale. Seguro que tienes razón. Ya me extrañaba. Es que cuando con el Webfig configuro un Eoip, sea cual sea el router, me ponía 64 siempre, al principio, en la casilla de MTU, al abrirla para poner un valor. Como en el manual no dice nada, daba por supuesto que ese 64 era el valor por defecto. Pero por lo que muestras, debe ser 1458. Eso tiene más sentido.

Lo único que dice el manual es que recomienda ponerlo a 1500 para evitar refragmentaciones de tramas ethernet, cuyo valor de 1500 es el habitual. Dado que el propósito es unir dos bridges, y estos funcionan con 1500, me parece que no hay otra que seguir la recomendación. No obstante, tengo claro que hace falta estudiar este asunto de los valores adecuados de MTU y MSS para este túnel.

Haz clic para expandir...

Claro, pero esas tramas ethernet hay que meterlas luego en paquetes que ya llevan parte ocupado por el ipsec. De ahí que me quede la duda de si el “clamp tcp mss” va a hacer lo que tiene que hacer, o justo estemos forzando la fragmentación nosotros mismos, al poner el túnel a 1500.

Yo tampoco lo he mirado, habrá que estudiarlo con tranquilidad.

Saludos!

furny dijo:

Le he puesto un número MAC propio dentro del rango libre, para que sea único (es buena práctica. Haré lo mismo con el otro extremo Playa).

Haz clic para expandir...

Un par de dudas.

La MAC de dónde se obtiene ?

En el router de la playa hay que importar los certificados del router HQ.
Subimos a la carpeta FILES los archivos vpn-ca y vpn-client-playa y luego vamos a system>certificates para importarlos ?

Cuando salga Wireguard en la rama estable, se podrá montar también este tipo de s2s, pensando en la "casa de la playa" (TV) ?

Saludos.

stargate4you dijo:

La MAC de dónde se obtiene ?

Haz clic para expandir...

Se autogenera sola al crear el bridge. Si quieres que no lo haga cada vez que reinicia el equipo, le puedes dar una MAC propia en el campo "Admin MAC Address". En la wiki tienes los rangos que se manejan, aunque lo más sencillo sería copiar la que genera automáticamente la primera vez que creas el bridge, y plantarla en ese campo acto seguido.

stargate4you dijo:

En el router de la playa hay que importar los certificados del router HQ.
Subimos a la carpeta FILES los archivos vpn-ca y vpn-client-playa y luego vamos a system>certificates para importarlos ?

Haz clic para expandir...

Correcto. Importarías tanto la CA como el certificado cliente, y los dejas ahí en el apartado de certificados, no tienes que hacer más. Luego, referenciarlos donde toque.

stargate4you dijo:

Cuando salga Wireguard en la rama estable, se podrá montar también este tipo de s2s, pensando en la "casa de la playa" (TV) ?

Haz clic para expandir...

Correcto. Sería muy parecido, primero montar el site to site de wireguard, y encima de ese túnel el EoIP.

Saludos!

pokoyo dijo:

Claro, pero esas tramas ethernet hay que meterlas luego en paquetes que ya llevan parte ocupado por el ipsec. De ahí que me quede la duda de si el “clamp tcp mss” va a hacer lo que tiene que hacer, o justo estemos forzando la fragmentación nosotros mismos, al poner el túnel a 1500

Haz clic para expandir...

A ver. Una cosa es el MTU, que es el tamaño en nivel 3 (o el L2 MTU, para nivel 2). Normalmente, a través de ICMP, se descubre el Path MTU (PMTU). Eso es, en un "camino" a través de routers, túneles y estrechamientos variados (VPN, EoiP, PPPOE, etc) y a través de la nube un paquete transita de un lado a otro por un "camino" de un determinado tamaño máximo (MTU). Este mecanismo (PTMU discovery, PTMUD) funciona así, más o menos: Desde un origen se manda un paquete con el DF (defragmentation flag) puesto a "no". Si el paquete se rechaza porque para que quepa por el camino hay que fragmentarlo, se devuelve por ICMP un mensaje (código 3:4 o algo así creo). Con ello, el origen detecta que el paquete es demasiado grande y modifica el MTU. Entonces manda un paquete más pequeño y si pasa al siguiente nodo, y allí se rechaza. lo va bajando. Al final del proceso, se ajusta el MTU. Este mecanismo lo tienen los MK y muchos otros routers. El problema es que en algún lugar de ese camino estén bloqueados los mensajes ICMP, por algún motivo (¿seguridad?) y la cadena de autodescubrimiento se rompa (Broken PTMUD).

Como los túneles los estamos haciendo entre MKs, solo si dentro de la nube "algo" lo fastidia, el ajuste del MTU se rompería. Para ello, pero sólo es válido para TCP, existe el "clamp TCP MSS". Ahí lo que se hace es ajustar el tamaño del segmento máximo (MSS, que es de nivel 4), para evitar fragmentaciones, o peor, que haya una aplicación que demande que no se fragmente (DF flag a no) y entonces no se pueda establecer la comunicación. Pero para UDP u otro protocolo no vale: o te funciona el PMTUD o lo tienes que poner a mano el MTU.

Si las cosas van bien, por lo tanto, no habría, en principio, que hacer nada: el router, el solito ajusta por el PMTUD y todo iría bien.

Hace tiempo que estuve jugando con esto y vi que, efectivamente, con los valores calculados, las reglas de mangle eran inútiles, pues no había nada que ajustar: se había ajustado solo. (Fui bajando el TCP MSS poco a poco hasta por debajo del valor máximo teórico: allí el mangle actuaba. Pero si lo ponía exactamente al valor calculado teóricamente, el mangle no hacía nada). Esto lo probé con IKE2 Road Warrior, hace meses y quité las reglas mangle, claro

Además, el Eoip tiene una opción de hacer clamp del TCP MSS, que ahora está activada (es la alternativa por defecto). Cuando se usa debajo IPsec automáticamente "supongo" que esa opción lo tiene en cuenta, pero no estoy seguro. Menos seguro aún estoy si no le ponemos el Ipsec automático, sino que le arreamos in IKEv2 Ipsec nosotros, como es este caso. Lo que debo hacer es el cálculo teórico, ver el comportamiento con un mangle con ese cálculo y comparar el efecto de ese mangle con la opción activada y desactivada y con el túnel EoiP/Ipsec en automático, para despejar dudas. Pero, si todo va bien, y el PMTU funciona, lo del TCP MSS sería irrelevante. Y para que funcione el IPTV, que va por UDP, a mi me resultaría más irrelevante aún: o funciona el PMTUD o tengo que poner valores a mano.

Este es mi entendimiento de la cuestión. Pero puedo estar equivocado (dime si estoy en lo cierto, o tengo algún error de concepto, que se me han olvidado muchas cosas con la edad...). La única forma de salir de dudas es jugar otra vez con las reglas mangle de ajuste de MSS y ver si funciona o no el PMTUD y si hay que hacer algo. Pero para eso hay que ir al entorno real (un router en casa y otro en la playa). Y tenemos de momento, prohibido ir a la playa... me temo. (continuará)

furny dijo:

A ver. Una cosa es el MTU, que es el tamaño en nivel 3 (o el L2 MTU, para nivel 2). Normalmente, a través de ICMP, se descubre el Path MTU (PMTU). Eso es, en un "camino" a través de routers, túneles y estrechamientos variados (VPN, EoiP, PPPOE, etc) y a través de la nube un paquete transita de un lado a otro por un "camino" de un determinado tamaño máximo (MTU). Este mecanismo (PTMU discovery, PTMUD) funciona así, más o menos: Desde un origen se manda un paquete con el DF (defragmentation flag) puesto a "no". Si el paquete se rechaza porque para que quepa por el camino hay que fragmentarlo, se devuelve por ICMP un mensaje (código 3:4 o algo así creo). Con ello, el origen detecta que el paquete es demasiado grande y modifica el MTU. Entonces manda un paquete más pequeño y si pasa al siguiente nodo, y allí se rechaza. lo va bajando. Al final del proceso, se ajusta el MTU. Este mecanismo lo tienen los MK y muchos otros routers. El problema es que en algún lugar de ese camino estén bloqueados los mensajes ICMP, por algún motivo (¿seguridad?) y la cadena de autodescubrimiento se rompa (Broken PTMUD).

Como los túneles los estamos haciendo entre MKs, solo si dentro de la nube "algo" lo fastidia, el ajuste del MTU se rompería. Para ello, pero sólo es válido para TCP, existe el "clamp TCP MSS". Ahí lo que se hace es ajustar el tamaño del segmento máximo (MSS, que es de nivel 4), para evitar fragmentaciones, o peor, que haya una aplicación que demande que no se fragmente (DF flag a no) y entonces no se pueda establecer la comunicación. Pero para UDP u otro protocolo no vale: o te funciona el PMTUD o lo tienes que poner a mano el MTU.

Si las cosas van bien, por lo tanto, no habría, en principio, que hacer nada: el router, el solito ajusta por el PMTUD y todo iría bien.

Hace tiempo que estuve jugando con esto y vi que, efectivamente, con los valores calculados, las reglas de mangle eran inútiles, pues no había nada que ajustar: se había ajustado solo. (Fui bajando el TCP MSS poco a poco hasta por debajo del valor máximo teórico: allí el mangle actuaba. Pero si lo ponía exactamente al valor calculado teóricamente, el mangle no hacía nada). Esto lo probé con IKE2 Road Warrior, hace meses y quité las reglas mangle, claro

Además, el Eoip tiene una opción de hacer clamp del TCP MSS, que ahora está activada (es la alternativa por defecto). Cuando se usa debajo IPsec automáticamente "supongo" que esa opción lo tiene en cuenta, pero no estoy seguro. Menos seguro aún estoy si no le ponemos el Ipsec automático, sino que le arreamos in IKEv2 Ipsec nosotros, como es este caso. Lo que debo hacer es el cálculo teórico, ver el comportamiento con un mangle con ese cálculo y comparar el efecto de ese mangle con la opción activada y desactivada y con el túnel EoiP/Ipsec en automático, para despejar dudas. Pero, si todo va bien, y el PMTU funciona, lo del TCP MSS sería irrelevante. Y para que funcione el IPTV, que va por UDP, a mi me resultaría más irrelevante aún: o funciona el PMTUD o tengo que poner valores a mano.

Este es mi entendimiento de la cuestión. Pero puedo estar equivocado (dime si estoy en lo cierto, o tengo algún error de concepto, que se me han olvidado muchas cosas con la edad...). La única forma de salir de dudas es jugar otra vez con las reglas mangle de ajuste de MSS y ver si funciona o no el PMTUD y si hay que hacer algo. Pero para eso hay que ir al entorno real (un router en casa y otro en la playa). Y tenemos de momento, prohibido ir a la playa... me temo. (continuará)

Haz clic para expandir...

Está todo correcto compi. Es más, es muy probable que reducir el TCP MSS vía mangle, en algunos casos, incluso sea contraproducente, porque todo el camino esté despejado para ir con un tamaño de paquete mayor.
No obstante, me sigue quedando la duda de cómo se comporta el clamp tcp mss. Según el video de Nikita, cuando crea las interfaces de tipo IPIP encima del túnel IKEv2 no especifica MTU alguno, así que entiendo que está dejando al PMTU descubrir ese tamaño.

Si necesitas hacer alguna prueba, estoy encantado de configurarte el hAP-mini o un hEX-S para que cacharres con él y montes el túnel entre ambos equipos. Dime, y lo organizamos. Yo también estoy ansioso por probar esto como dios manda y ver qué tal se comporta. De momento, el site-to-site entre el router de casa y el de mis padres va como un cañón (dentro de lo que cabe, ese equipo "bebe" de un PCL que a sus vez conecta con el router de la operadora; no me quedaba más narices que montarlo así), pero la conexión es tremendamente estable, nada que ver con EoIP con IPSec. Este último lo estuve probando en casa de un vecino y sí que perdía conexión a veces, y el mover cosas grandes en capa 2, al hAP-mini le rascaba.

Saludos!

pokoyo dijo:

Es más, es muy probable que reducir el TCP MSS vía mangle, en algunos casos, incluso sea contraproducente, porque todo el camino esté despejado para ir con un tamaño de paquete mayor.

Haz clic para expandir...

Correcto. Lo suyo es que descubran los routers tranquilamente el MTU apropiado, si los mecanismos automáticos funcionan. Si no, ajustarlo. Como el clamp TCP MSS solo vale para TCP, si es necesario, se usa. Pero ponerlo en un valor bastante bajo, por debajo del máximo que quepa, va a hacer la conexión en realidad más ineficiente, al haber más paquetes con su correspondiente overhead para un tamaño de mensaje dado.

IPsec tiene un overhead de unos 100 bytes, por lo que partiendo de 1500, el tamaño del payload usando Ipsec es de unos 1400; descontando también PPPOE, 8 menos (1392), pero depende de los algoritmos de cifrado usados con IKEv2, concretamente, creo, por lo que hay que calcularlo exacto. Además, hay que descontar el overhead de EoIP (GRE) de 24 bytes. O sea que para TCP se quedaría en 1368. Si descontamos los 40 de overhead de TCP/IP queda un MSS de 1328. Pero tengo que estudiar más en detalle cual es el overhead de IKEv2 con los algoritmos que uso, que no lo tengo claro y no he tenido tiempo de mirarlo.

pokoyo dijo:

Según el video de Nikita, cuando crea las interfaces de tipo IPIP encima del túnel IKEv2 no especifica MTU alguno, así que entiendo que está dejando al PMTU descubrir ese tamaño.

Haz clic para expandir...

Yo vi un video que pasase hace tiempo, pero ahora no lo localizo. Pero si es así, efectivamente, debe estar dejando que el PMTUD actúe. Si me voielves a pasar el video, porfa, lo estudio. De Nikita tengo una presentación suya de IKEv2 de hace unos meses, muy interesante, pero no habla de GRE o de IPIP, que yo recuerde.

pokoyo dijo:

Si necesitas hacer alguna prueba, estoy encantado de configurarte el hAP-mini o un hEX-S para que cacharres con él y montes el túnel entre ambos equipos. Dime, y lo organizamos.

Haz clic para expandir...

Pues me parece muy buena idea, genial. Muchas gracias. Yo este puente creo que me voy a poder escapar y montar el setup de la playa, pero no sé si tendré tiempo de hacer muchas pruebas, pues tendré mucho curro allí de limpieza y acondicionamiento, después de tantos meses sin ir, y además tengo que atender otros negocios. Encima el ISP que tengo es con WIMAX, que para uso ocasional está bien, pero para IPTV no sé... es lo que tengo que evaluar también.
Así que después del puente si que sería bueno hacer una prueba real con fibra en los dos lados. Te tomo la palabra y en cuanto pueda en mayo lo organizamos y salimos de dudas.

Gracias y saludos, maestro!

Cuando necesites cacharrear y hacer pruebas me avisas, y lo montamos.

Te paso los dos vídeos de Nikita, base para estos manuales de IKEv2, corrigiendo algún gazapo de las PPT's. El primero es el del road warrior, donde más se habla en detalle del TCP MSS. Y el segundo es el del IKEv2 site-to-site, con los dos métodos descritos: túnel sobre túnel y usando templates para políticas de IPSEC.



En los comentarios de ambos vídeos puedes localizar las URL a los PPT, están en la web del MUM. Son estos dos, respectivamente:

Saludos!

Mira, otro muy chulo. Montar lo mismo, pero sin certificados en la parte cliente, delegando la autenticación en un servidor Free Radius, y autenticar los clientes con EAP.


Saludos!

pokoyo dijo:

Mira, otro muy chulo. Montar lo mismo, pero sin certificados en la parte cliente, delegando la autenticación en un servidor Free Radius, y autenticar los clientes con EAP.

https://mum.mikrotik.com//presentations/CN19/presentation_7073_1571797375.pdf

Saludos!

Haz clic para expandir...

Fenómeno. Ya me has dado food for thought!! Como tenía poco que hacer para el puente ! jajaja! Muchas gracias!

Buenas tardes a tod@s,

Actualmente tengo montados dos túneles EOIP (gracias @pocoyo) entre el MK de casa, otro MK en la oficina y un MK en una segunda residencia, funcionando correctamente, por lo que mi intención es securizar los mismos aún más mediante certificados, tal y como @furny propone en el presente hilo.

Mi consulta es la siguiente: ¿Es viable montar más de un túnel EOIP sobre IKEv2 bajo un mismo MK "casa"?

Muchas gracias de antemano.

Saludos!

Yo independizaría los segmentos de red de las tres ubicaciones. Y, si luego quieres meter un puerto concreto en el mismo dominio de broadcast, hazlo sin problemas. Con dos túneles puedes hacer eso sin problema. Habría un router principal o HQ (headquarters) y dos routers de tipo oficina (branches).

Saludos!

Exacto. Es perfectamente posible. El router principal tiene dirección para el Ipsec IKEv2 192.168.99.1 en la configuración ejemplo subida, mientras que el "playa" tiene la 192.168.99.2. Si quieres hacer un segundo túnel desde el router principal al "playa2", lo que yo haría es asignarle 192.168.99.3. Y sobre las direcciones 99.1 y 99.3 montas un segundo EoiP con número de túnel distinto del existente entre router Casa y playa. No lo he probado, pero creo que funcionaría.
Lo que dice @pokoyo, seguro que también funciona, que es para el segundo túnel crear un segundo puente "loopback2" y direcciones de otra subred, p.e. 192.168.98.1 y 98.2. Esto último funcionaría seguro. Tampoco lo he probado, pero yo, ahora mismo, tengo desde mi router principal, el Road Warrior, el site-to-site a un hAP mini de IKEv2 de la configuración de @pokoyo y el site2site IKEv2/EoiP a un hAP, a parte de los dos EoiP/IpSEC respectivos, si bien estos últimos deshabilitados. No está todo simultáneamente, pero no preveo conflictos.

Suerte!!!