MANUAL: EoiP sobre IKEv2 site to site

Buenas.
He montado el site-to site y el eoip según el manual.
He probado igual que furny un segundo deco en el branch.
La conexión la establece pero no me carga la información el deco y no se ve nada.
He mirado el log y esto es lo que me aparece. En el lado del HQ tambien da el mismo error.

Captura de pantalla_2021-04-29_10-05-37.png


Captura de pantalla_2021-04-29_09-55-11.png


Captura de pantalla_2021-04-29_09-58-59.png

Saludos.
 
manda un export. A ser posible, de ambos equipos.

Saludos!
 
Gracias @pokoyo .
Adjunto las dos configuraciones en un momento.
 

Adjuntos

  • hq-router.txt
    19.1 KB · Visitas: 34
  • branch-router.txt
    10.9 KB · Visitas: 23
Buenas, @pokoyo . Buscando información para diseñar los valores adecuados de la regla mangle, me he topado con este hilo en el foro MK del gurú Sindy. No solo corrobora nuestro entendimiento del asunto, sino que propone una solución bien interesante cuando el PMTUD se rompe, no por algún router en el camino, sino como consecuencia de la propia configuración, la mayoría de las veces, por tener que incluir en la policy a la vez la dirección de origen y destino de la misma subred: la solución que propone es meter una curiosa regla action=none al principio de las "policies". La conclusión es que hay que evaluar si este tipo de túnel se topa precisamente con este posible problema (si detectasemos que el MTU no se estuviera autoajustando bien) y entonces aplicar este "desatascador". Léetelo, que merece la pena (aunque al principio, trata de otro caso) y me cuentas que te parece.
 
Buenas, @pokoyo . Buscando información para diseñar los valores adecuados de la regla mangle, me he topado con este hilo en el foro MK del gurú Sindy. No solo corrobora nuestro entendimiento del asunto, sino que propone una solución bien interesante cuando el PMTUD se rompe, no por algún router en el camino, sino como consecuencia de la propia configuración, la mayoría de las veces, por tener que incluir en la policy a la vez la dirección de origen y destino de la misma subred: la solución que propone es meter una curiosa regla action=none al principio de las "policies". La conclusión es que hay que evaluar si este tipo de túnel se topa precisamente con este posible problema (si detectasemos que el MTU no se estuviera autoajustando bien) y entonces aplicar este "desatascador". Léetelo, que merece la pena (aunque al principio, trata de otro caso) y me cuentas que te parece.
Pásame el enlace, porfa.

Gracias!
 
Gracias @pokoyo .
Adjunto las dos configuraciones en un momento.
Vale. Creo que el problema está en los filtros firewall. Te cuento. El túnel se establece, pero no está permitido admitir tráfico en ninguno de los extremos. Tienes en ambos está regla:

add action=accept chain=input comment="accept vpn encrypted input traffic" \
ipsec-policy=in,ipsec src-address=192.168.66.0/24

yo la parte de src-address no la pongo, y por eso no lo documenté. Solo está permitiendo tráfico de la red .66, NO de otras redes, que no pueden ser más que tuyas, propias, pues van por un túnel encriptado. La solucion es quitar la parte de src-address en ambos router. Yo no la pongo porque es prácticamente imposible que alguien se meta en un túnel encriptado y, de tapadillo, meta paquetes de otra red. O sea, que si no lo pones, lo que dice es: permito TODO el tráfico que venga en un túnel encriptado. Si poner el src, diría: SOLO permito el tráfico que venga encriptado, y de una red de esa dirección; y rechaza el tráfico encriptado con origen de otras direcciones.

Mira a ver si corregido té funciona y me lo dices. Si la prueba la estás haciendo con un router desde el móvil, ya sabes que hay que tener paciencia con el desco.

suerte!,
 
Buenas, @pokoyo . Buscando información para diseñar los valores adecuados de la regla mangle, me he topado con este hilo en el foro MK del gurú Sindy. No solo corrobora nuestro entendimiento del asunto, sino que propone una solución bien interesante cuando el PMTUD se rompe, no por algún router en el camino, sino como consecuencia de la propia configuración, la mayoría de las veces, por tener que incluir en la policy a la vez la dirección de origen y destino de la misma subred: la solución que propone es meter una curiosa regla action=none al principio de las "policies". La conclusión es que hay que evaluar si este tipo de túnel se topa precisamente con este posible problema (si detectasemos que el MTU no se estuviera autoajustando bien) y entonces aplicar este "desatascador". Léetelo, que merece la pena (aunque al principio, trata de otro caso) y me cuentas que te parece.

perdona! Lo puse empotrado en el mensaje, en la palabra “hilo” pero no se porque, ha fallado. Ahí lo tienes. Ya me dices...
 
@furny
Sigue igual, no conecta.
Esto sale en el router hq.
He cambiado las reglas y reboot en el hq.
Los dos routers están conectados a la línea de fibra.
Con un simple EoIP/Ipsec si que conectan.
Gracias.

Captura de pantalla_2021-04-29_11-17-39.png
Captura de pantalla_2021-04-29_11-21-39.png
 
@furny La red 192.168.66.0/24 se usa en los dos routers para montar el pool de una VPN ikev2 del primer manual que hizo @pokoyo. Coinciden en los dos routers la misma red al aplicar el mismo manual. En principio no creo que tengan nada que ver con esta guia. Seguramente tendré que borrar la regla del firewall ya que no se aplica en el HQ al montar esta configuración junto con la de pokoyo que también aplica el road-warrior. Y de echo me conecto perfectamente con un móvil al router HQ con estos dos últimos manuales.

Para esta nueva vpn se usa la red 192.168.68.0/24 para el pool de las conexiones road-warrior en el HQ.

Saludos.
 
Última edición:
¿puedes hacer ping desde el router de HQ a la branch y viceversa? Recuerda que el ping ha de ir desde la IP del túnel, es decir, tienes que especificar desde qué IP lanzas el ping, en la terminal del router:

HQ -> BRANCH
Código:
ping 192.168.99.2 src-address=192.168.99.1

BRANCH -> HQ
Código:
ping 192.168.99.1 src-address=192.168.99.2

Tienes mal la config de IPSec del router branch. Parece que lo tengas como router servidor, en lugar de como cliente (por ejemplo, el mode-conf o el policy, creas la template pero no el túnel en sí, con el tunnel=yes). Si te resulta más sencillo, bórrale la config de IPSec a ese router y arranca de nuevo con esa config, tal y como se describe en mi manual, solo que, en lugar de hacer las policies para el LAN to LAN, las haces con las dos IP's de los extremos del túnel.

Saludos!
 
Los dos routers están conectados a la línea de fibra.
Pero, ¿tienes dos líneas de fibra distintas a dos ONTs separadas? Si no, no te va. Yo solo tengo una línea de fibra y la otra, para las pruebas, lo hago a través del móvil.

A ver. Lo que te he dicho de la modificación de la regla, es válido en cualquiera de los casos. Yo la dejaría modificada sin el src-address, pues te vale para permitir el acceso al router de tráfico desencriptado de IPsec, uses el site2site u otro. Voy a echarle un vistazo más en detalle a tu configuración, pues tienes varias vpn y puede que me esté pasando algo por alto.

Por cierto ¿has hecho "flush" en los extremos, una vez configurado y en marcha? hay veces que, al principio, las políticas se quedan un tanto tontas. Cito lo que dije en la configuración:


Después, vais a ip -> ipsec -> installed SAs y hacéis un "flush". Con esto obligáis a levantar el túnel Ike2/Ipsec.
Ya me dices. Suerte!!
 
ienes mal la config de IPSec del router branch. Parece que lo tengas como router servidor, en lugar de como cliente (por ejemplo, el mode-conf o el policy, creas la template pero no el túnel en sí, con el tunnel=yes).
mmmm!. Lo siento, discrepo, @pokoyo Para mi configuración está así bien.
Te refieres a esto:

/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

y a esto, ¿no?.

/ip ipsec mode-config
add name=s2s-ike2-config responder=no

Ahí no le veo el problema. Está idéntico a como yo lo tengo y como viene en el manual. Este lado, el branch, lo pongo como iniciador. Por eso no "da la lata" si el otro extremo está deshabilitado. Y también lo pongo a propósito como template en la "policy". Debe ser otra cosa...
 
Pero, ¿tienes dos líneas de fibra distintas a dos ONTs separadas? Si no, no te va. Yo solo tengo una línea de fibra y la otra, para las pruebas, lo hago a través del móvil.
Correcto. La línea del HQ es Movistar triple play y la otra es de O2.
Ya te digo que con un túnel EoIP-Ipsec conectan bien.
También hice el flush , la conexión se establece. Es lo que indica en los dos routers.

¿puedes hacer ping desde el router de HQ a la branch y viceversa? Recuerda que el ping ha de ir desde la IP del túnel, es decir, tienes que especificar desde qué IP lanzas el ping, en la terminal del router:

HQ -> BRANCH
Código:
ping 192.168.99.2 src-address=192.168.99.1

BRANCH -> HQ
Código:
ping 192.168.99.1 src-address=192.168.99.2

Tienes mal la config de IPSec del router branch. Parece que lo tengas como router servidor, en lugar de como cliente (por ejemplo, el mode-conf o el policy, creas la template pero no el túnel en sí, con el tunnel=yes). Si te resulta más sencillo, bórrale la config de IPSec a ese router y arranca de nuevo con esa config, tal y como se describe en mi manual, solo que, en lugar de hacer las policies para el LAN to LAN, las haces con las dos IP's de los extremos del túnel.

Saludos!
Probaré lo del ping en los dos routers.

Cuando pueda lo pruebo y comento.
A lo mejor tardo unos días.
Saludos.
 
mmmm!. Lo siento, discrepo, @pokoyo Para mi configuración está así bien.
Te refieres a esto:

/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

y a esto, ¿no?.

/ip ipsec mode-config
add name=s2s-ike2-config responder=no

Ahí no le veo el problema. Está idéntico a como yo lo tengo y como viene en el manual. Este lado, el branch, lo pongo como iniciador. Por eso no "da la lata" si el otro extremo está deshabilitado. Y también lo pongo a propósito como template en la "policy". Debe ser otra cosa...
No he dicho nada, no me había fijado en que este router estaba también haciendo de servidor VPN, y de ahí que se me fuera la vista al otro mode-config. Pero es verdad que en el identity luego lo estás haciendo correctamente. No obstante, te lo podrías ahorrar, el lado "branch" lo que necesita hacer es "pedir" el mode config al otro lado, tal que el HQ le entregue el que le ha asociado en su identity, y esto lo hacemos con el mode-config=request-only en el lado branch, cuando declaramos el identity del otro lado.

Con respecto a la template, olvida también lo que he dicho. Estás yendo por la vía de túnel encima de túnel, así que no necesitas levantar del lado del cliente nada.

Saludos!
 
Por si puedo aportar algún dato más.
Me he conectado con el móvil a los dos routers y he mirado en IP>IPsec> Active peers.

Router HQ
IMG_20210429_170552.jpg
Router branch
IMG_20210429_165956.jpg

De todas maneras cuando pueda conectarme correctamente volveré
a inyectar el flush y haré la prueba del ping.
Saludos.

PD: Flush en los dos routers. Sí tienen ping en las dos direcciones.
Me falta probar con el desco conectado a ver si enlaza y se ven los canales.. Esto para otro rato si puedo probarlo mañana. Entonces vuelvo a decir si me funciona o no.

Captura de pantalla_2021-04-29_19-34-59.pngCaptura de pantalla_2021-04-29_19-31-03.png
 
Última edición:
Buenas tardes a tod@s,

@pocoyo y @furny, una vez más, muchas gracias por vuestras aclaraciones, voy a ver cómo le doy forma para montar un par de túneles...sin morir en el intento.

Saludos!
 
Captura de pantalla_2021-04-30_07-58-06.png
Buenas pues ahora ya no da el error de ayer. El router branch y el desco tienen ip, pero siguen sin verse los canales. Los logs no muestran errores. Hay ping en los dos routers.
 

Adjuntos

  • hq-router.txt
    18.9 KB · Visitas: 15
  • branch-router.txt
    10.9 KB · Visitas: 15
Última edición:
Hola furny
Si los dos router que vamos a conectar son mikrotik. ¿No tendría mas sentido establecer un único dh-group, enc-algorithm, auth-algorithms, poniendo el que mayor rendimiento pudiera dar, o el mas seguro?


# 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
 
Arriba