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):
Código:
/certificate
add copy-from=~vpn-client-template name=vpn-client-playa common-name="VPN Client Playa"\
subject-alt-name=email:playa@router.pericopalotes.com

1-b) Lo firmamos:
Código:
/certificate
sign vpn-ca
{:delay 5};
sign vpn-client-playa ca=vpn-ca

1-c) ...y lo exportamos:
Código:
/certificate
export-certificate vpn-client-playa type=pkcs12 export-passphrase="MySuperVPN!" file-name=playa

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:
Código:
/interface bridge
add comment="Site-to-site dummy bridge" name=loopback

2-b) Ahora creamos una subred para el túnel y le damos una dirección al bridge "loopback":
Código:
/ip address
add address=192.168.99.1 comment="For site-to-site IkeV2 EoiP tunnel" \
    interface=loopback network=192.168.99.1

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":
Código:
/ip ipsec mode-config
add address=192.168.99.2 address-prefix-length=32 name=eoip-ike2-config \
    split-include=192.168.99.1/32 system-dns=no

3-b) Los siguientes son pasos comunes con la configuración RW, pero es imprescindible tenerlos configurados, si no lo habéis hecho previamente:
Código:
# Damos de alta un nuevo group para asociar a él las plantillas de configuración con los policies a usar
/ip ipsec policy group
add name=ike2-template-group

# Damos de alta el perfil de autenticación
/ip ipsec profile
add dh-group=modp2048,modp1536,modp1024 enc-algorithm=aes-256,aes-192,aes-128 hash-algorithm=sha256 name=ike2-profile

# Damos de alta la propuesta de negociación para el intercambio de claves IKE y SAs
# Las claves tendrán una validez de 8h para evitar renegociaciones innecesarias y el pfs-group=none para
# aumentar la compatiblidad con dispositivos moviles, tipo Apple. Restringimos el proposal a tipo de encriptación AES
/ip ipsec proposal
add auth-algorithms=sha512,sha256,sha1 enc-algorithms=aes-256-cbc,aes-256-ctr,aes-256-gcm,aes-192-ctr,aes-192-gcm,aes-128-cbc,aes-128-ctr,aes-128-gcm lifetime=8h \
name=ike2-proposal pfs-group=none

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:
Código:
/ip ipsec peer
add exchange-mode=ike2 name=ike2-peer passive=yes profile=ike2-profile send-initial-contact=no

3-d) Damos de alta la identidad del lado remoto "Playa", apuntando a su mode-config:
Código:
/ip ipsec identity
add auth-method=digital-signature certificate=vpn-server comment=router-playa generate-policy=port-strict match-by=certificate mode-config=eoip-ike2-config peer=\
    ike2-peer policy-template-group=ike2-template-group remote-certificate=vpn-client-playa

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):
Código:
/ip ipsec policy
add comment="site-to-site ike2 EoiP tunnel" dst-address=192.168.99.2/32 \
    group=ike2-template-group proposal=ike2-proposal src-address=192.168.99.1/32 \
    template=yes

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:
Código:
/interface eoip
add allow-fast-path=no disabled=yes !keepalive local-address=192.168.99.1 \
    mac-address=00:00:5E:FF:07:36 mtu=1500 name=s2s-ike2-tunnel \
    remote-address=192.168.99.2 tunnel-id=16

4-b) Ya sólo queda añadir la nueva interfaz a nuestro IPTV-bridge:
Código:
/interface bridge port
add bridge=IPTV-Bridge interface=s2s-ike2-tunnel

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:
Código:
/ip cloud
set ddns-enabled=yes ddns-update-interval=1m

5-a) Lo primero, creamos el IPTV-bridge en este router:
Código:
/interface bridge
add igmp-snooping=yes name=IPTV-Bridge

5-b) ...y lo metemos en la lista LAN:
Código:
/interface list member
add interface=IPTV-Bridge list=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:
Código:
/ip ipsec mode-config
add name=s2s-ike2-config responder=no

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
Código:
/ip ipsec policy group
add name=ike2-template-group

6-c) Perfil, idéntico al del servidor
Código:
/ip ipsec profile
add dh-group=modp2048,modp1536,modp1024 enc-algorithm=aes-256,aes-192,aes-128 \
    hash-algorithm=sha256 name=ike2-profile

6-d) Peer, apuntando a la dirección de nuestro dominio o IP estática del router HQ, con send-initial-contact=yes
Código:
/ip ipsec peer
add address=router.pericopalotes.com exchange-mode=ike2 name=s2s-peer \
    profile=ike2-profile send-initial-contact=yes

6-e) Proposal, idéntico al del router de HQ
Código:
/ip ipsec proposal
add auth-algorithms=sha512,sha256,sha1 enc-algorithms="aes-256-cbc,aes-256-ctr,a\
    es-256-gcm,aes-192-ctr,aes-192-gcm,aes-128-cbc,aes-128-ctr,aes-128-gcm" \
    lifetime=8h name=ike2-proposal pfs-group=none

6-f) Identity, en este caso especificando únicamente el certificado cliente:
Código:
/ip ipsec identity
add auth-method=digital-signature certificate=vpn-client-playa generate-policy=\
    port-strict mode-config=s2s-ike2-config peer=s2s-peer \
    policy-template-group=ike2-template-group

6-g) Y por fin, la política. La hacemos aquí en modo template, y también, poniendo las direcciones de los dos extremos:
Código:
/ip ipsec policy
add dst-address=192.168.99.1/32 group=ike2-template-group proposal=ike2-proposal \
    src-address=192.168.99.2/32 template=yes

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:
Código:
/interface eoip
add allow-fast-path=no !keepalive local-address=192.168.99.2 mac-address=\
    00:00:5E:FF:07:37 mtu=1500 name=s2s-ike2-Playa remote-address=\
    192.168.99.1 tunnel-id=16

7-b) ... añadimos esta nueva interfaz al puente:
Código:
/interface bridge port
add bridge=IPTV-Bridge interface=s2s-ike2-Playa

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:
Código:
/interface bridge port
add bridge=IPTV-Bridge interface=ether4

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:
Código:
/ip dhcp-client
add add-default-route=no disabled=no interface=IPTV-Bridge use-peer-dns=yes

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:
Código:
/ip firewall filter
add action=accept chain=input comment="allow ipsec" dst-port=500,4500 protocol=udp
add action=accept chain=input protocol=ipsec-esp
add action=accept chain=input comment=\
    "Allow decrypted IpSec traffic from Playa to router HQ" ipsec-policy=in,ipsec

10) Y en el lado remoto "Playa":
Código:
/ip firewall filter
add action=accept chain=input comment="allow ipsec" dst-port=500,4500 protocol=udp
add action=accept chain=input protocol=ipsec-esp
add action=accept chain=input comment="allow HQ access to router" ipsec-policy=in,ipsec

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!!!
 
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
 
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.
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:

Código:
# Creamos el nuevo bridge para ikeV2
/interface bridge
add name=bridge-ikeV2

# Metemos cada interfaz en su lista correspondiente
/interface list member
add interface=bridge-ikeV2 list=LAN

# Añadir la ip al bridge
/ip address
add address=192.168.77.1/24 comment="ikeV2 subnet" interface=bridge-ikeV2 network=\
    192.168.77.0

# Añadimos un nuevo pool para los descos,
# y otro para el resto de los hosts en ese bridge-ikeV2
/ip pool
add name=pool-ikeV2-hosts ranges=192.168.77.50-192.168.77.199

# Damos de alta una nueva red para los hosts del nuevo bridge-ikeV2,
# y otra específica para los descos, con una dirección /29
/ip dhcp-server network
add address=192.168.77.0/24 comment="ikeV2 subnet for hosts" gateway=192.168.77.1 \
    netmask=24

# Creamos un nuevo servidor dhcp, asociado al nuevo bridge-ikeV2
/ip dhcp-server
add address-pool=pool-ikeV2-hosts disabled=no interface=bridge-ikeV2 name=dhcp-server-ikeV2

# Además del masquerade a la lista WAN (defconf), añadimos los masquerade
# para keV2, y para los hosts conectados al bridge ikeV2
/ip firewall nat
add action=masquerade chain=srcnat comment=\
    "masq. ikeV2 hosts" src-address=192.168.77.0/24

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..
 
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.
No hombre, el MTU por defecto del túnel EoIP es 1458

1619205158513.png

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

Ver el adjunto 81450
Saludos!
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.
 
Última edición:
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.
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!
 
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).
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.
 
Última edición:
La MAC de dónde se obtiene ?
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.

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 ?
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.

Cuando salga Wireguard en la rama estable, se podrá montar también este tipo de s2s, pensando en la "casa de la playa" (TV) ?
Correcto. Sería muy parecido, primero montar el site to site de wireguard, y encima de ese túnel el EoIP.

Saludos!
 
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
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á)
 
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á)
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!
 
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.
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.

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.
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.
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.
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!
 
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!!!
 
Arriba