MANUAL: EoiP sobre IKEv2 site to site

@pokoyo, gracias, acabo de borrar los dos servers que tenía y he dejado un único server para IPTV siguiendo tus indicaciones.

A mediodía pruebo y os cuento.

Mil gracias!!!!
 
@pokoyo, nada, no hay forma, el deco coge IP del rango del bridge-IPTV, puerta de enlace, IP OPCH, gateway..... pero da error de conectividad.

He probado, creo que de todo. Supongo que no tendrá nada que ver con la configuración IGMP, os paso pantallazo no obstante de HQ.

No sé si tendrá algún problema o incompatibilidad este tipo de túneles para tráfico IPTV, no obstante voy a seguir haciendo probaturas...pero ya no sé donde tocar...


Saludos!
 

Adjuntos

  • Nueva imagen.jpg
    Nueva imagen.jpg
    46.5 KB · Visitas: 25
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!!!
Hola, ante todo gracias a @furny por la info.

Estoy intentando seguir este proceso para montar un tunel site-to-site entre un RB4011 y un hAP ac2 y la verdad es que el tuto lo veo un poco lioso. He seguido al pie de la letra el proceso y no funciona (con EoIP+IPSec a la primera).

A la hora de crear los certificados, los he creado tal cual utilizando el DDNS de Mikrotik, doy por hecho que están OK.

Bash:
# Creaccion de los certificados
# Primero la CA
/certificate
add name=vpn-ca country=ES state=Tabarnia locality=Rivendel organization="ACME SA"\
common-name="VPN CA" subject-alt-name=DNS:dxxxxxxxxxx9.sn.mynetname.net key-size=2048 days-valid=3650 trusted=yes\
key-usage=digital-signature,key-encipherment,data-encipherment,key-cert-sign,crl-sign

# Luego el certificado del servidor
add name=vpn-server country=ES state=Tabarnia locality=Rivendel organization="ACME SA" unit=VPN\
common-name="VPN Server" subject-alt-name=DNS:d4xxxxxxxxxx9.sn.mynetname.net key-size=2048 days-valid=1825\
key-usage=tls-server,key-encipherment,digital-signature

# Por ultimo una template para crear certificados cliente
add name=~vpn-client-template country=ES state=Tabarnia locality=Rivendel organization="ACME SA"\
common-name="VPN Client XXX" subject-alt-name=email:xxx@dxxxxxxxxxx9.sn.mynetname.net key-size=2048\
days-valid=730 key-usage=tls-client

#Y los certificados de tipo cliente, copia de la template
add copy-from=~vpn-client-template name=vpn-client-branch common-name="VPN Client Branch"\
subject-alt-name=email:xxx@dXXXXXXXXXX9.sn.mynetname.net

# Los firmamos
/certificate
sign vpn-ca
sign vpn-server ca=vpn-ca
sign vpn-client-branch ca=vpn-ca

# Exportar la CA y los certificados cliente
/certificate
export-certificate vpn-ca file-name=ca
export-certificate vpn-client-branch type=pkcs12 export-passphrase="MyPaSSwOrD" file-name=branch

Y después importo el certificado de cliente en el router Branch (ya lleva incluido el CA) y lo renombro para facilitar su uso. Hasta ahí todo bien.

Una vez terminado con el proceso de los certificados continuo con la parte IPSec/IKEv2 y configuro las reglas de firewall pero se queda en "Phase 2" y no cambia a "established".

Un pregunta: ¿recomendáis borrar todo rastro del tunel EoIP (interfaces EoIP, reglas firewall, ip address, etc) antes de montar el tunel EoIP con IKEv2? Pueden convivir los dos tuneles?

S@lu2.
 
Última edición:
Sí, yo borraría todo lo relacionado con IPSec y empezaría de nuevo. Puedes montar EoIP a posteriori, si necesitas un enlace en capa2, sobre el propio túnel IKEv2.

Saludos!
 
Sí, yo borraría todo lo relacionado con IPSec y empezaría de nuevo. Puedes montar EoIP a posteriori, si necesitas un enlace en capa2, sobre el propio túnel IKEv2.

Saludos!
Buenos días a tod@s!

Siguiendo tus consejos, he borrado todo rastro del tunel EoIP/IPSec anterior y he empezado de nuevo siguiendo este tuto.

Señalar que yo no necesito IPTV y solo necesito tener conectado ambos extremos de tunel para poder teletrabajar desde HQ o desde Branch, pero cada router con su LAN independiente (Similar al tuto que hizo @pokoyo para EoIP/IPsec: https://www.adslzone.net/foro/mikro...-como-conectar-dos-sedes-site-to-site.525535/) pero con la velocidad/seguridad de IKEv2.

Una vez generados los certificados en la parte HQ e importados en la parte Branch, he empezado a configurar el resto.

Lado HQ
Bash:
/interface bridge
add comment="Site-to-site dummy bridge" name=loopback

/ip pool
add name=default-dhcp ranges=192.168.88.2-192.168.88.254
add name=pool-vpn ranges=192.168.68.10-192.168.68.254

/interface eoip
add allow-fast-path=no !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

/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

/ip ipsec policy group
add name=ike2-template-group

/ip ipsec profile
add dh-group=modp2048,modp1536,modp1024 enc-algorithm=aes-256,aes-192,aes-128 \
    hash-algorithm=sha256 name=ike2-profile

/ip ipsec peer
add exchange-mode=ike2 name=ike2-peer passive=yes profile=ike2-profile

/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

/ip ipsec identity
add auth-method=digital-signature certificate=vpn.ike2.xyz 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=c1@vpn.ike2.xyz

/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

/ip address
add address=192.168.99.1 comment="For site-to-site IkeV2 EoiP tunnel" \
    interface=loopback network=192.168.99.1

/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=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

/ip route
add distance=1 dst-address=192.168.2.0/24 gateway=192.168.99.2
add distance=1 dst-address=192.168.100.0/24 gateway=172.168.99.2

Lado Branch
Bash:
/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

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

/ip ipsec policy group
add name=ike2-template-group

/ip ipsec profile
add dh-group=modp2048,modp1536,modp1024 enc-algorithm=aes-256,aes-192,aes-128 \
    hash-algorithm=sha256 name=ike2-profile

/ip ipsec peer
add address=dXXXXXXXXXX9.sn.mynetname.net exchange-mode=ike2 name=s2s-peer \
    profile=ike2-profile

/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

/ip ipsec identity
add auth-method=digital-signature certificate=vpn-client generate-policy=\
    port-strict mode-config=s2s-ike2-config peer=s2s-peer \
    policy-template-group=ike2-template-group

/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

/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=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

La cuestión es que una vez finalizada la config, he pulsado en "flush" en ip -> ipsec -> installed SAs y ya levanta el tunel:

ChASIjYReb.png

MLuVtEYi64.png


Pero si hago "ping" a los hosts de la red de Branch no responde.

Los "Active Peers" parece que uno de los extremos (Branch) no adquiere la IP dinámica.

Lado Branch
CachgkRdeU.png


Lado HQ
9TCh6ejHVM.png


¿Me podéis orientar un poco que faltaría para que enlacen ambas IPs del tunel 192.168.99.1 (HQ) y 192.168.99.2 (Branch) ? mientras tanto no puedo crear las rutas estáticas para unir ambas LANs 192.168.88.0 (HQ) y 192.168.2.0 (Branch).

Gracias de antemano.

S@lu2.
 
Última edición:
Para para para. Estoy por borrar el manual de EoIP, no hace más que liaros…. Si ambos extremos son independientes, NO apliques EoIP, aplica IKEv2. Usa el último manual que hice al respecto, el de IKEv2 a fondo.

Saludos!
 
Para para para. Estoy por borrar el manual de EoIP, no hace más que liaros…. Si ambos extremos son independientes, NO apliques EoIP, aplica IKEv2. Usa el último manual que hice al respecto, el de IKEv2 a fondo.

Saludos!
Perfecto, siguiendo ese manual de IKEv2 a fondo ya está el túnel levantado y las LANs funcionando.

Una dudilla please:

En el lado Branch tengo una ruta dinámica para poder acceder a la ONT. Esa ruta se ha creado al asingar una IP al interfaz de ether1. A través de la terminal del router, Ping OK a la ONT.

Bash:
/ip address
add address=192.168.100.2/24 interface=ether1-wan network=192.168.100.0

Ahora quisiera acceder a esa ONT (branch) desde el lado HQ para controlar la potencia óptica que está un poco justilla. Para ello he creado en HQ esta ruta:

Bash:
/ip route
add distance=1 dst-address=192.168.100.0/24 gateway=192.168.68.2

99SCFsupBT.png


Pero no funciona. ¿Algún consejo?

Gracias!

S@lu2.
 
Última edición:
Olvidate de la ruta. La ruta, como bien dices, es dinámica y está creada a partir de una dirección metida en el router A. Si desde B necesitas acceder a ese elemento de red, necesitas una policy que acepte ese tráfico del otro lado, pero no una ruta en B. B sólo sabe de A vía policies, nada más. El tráfico se teletransporta de un sitio a otro, sin que pase por la tabla de rutas (no es del todo así, pero para que nos entendamos).

Haz un export de los policies que tienes a ambos lados (e identifica quien es HQ y quien branch) y te digo qué nueva policy meter para llegar a ver ese equipo.

Saludos!
 
Olvidate de la ruta. La ruta, como bien dices, es dinámica y está creada a partir de una dirección metida en el router A. Si desde B necesitas acceder a ese elemento de red, necesitas una policy que acepte ese tráfico del otro lado, pero no una ruta en B. B sólo sabe de A vía policies, nada más. El tráfico se teletransporta de un sitio a otro, sin que pase por la tabla de rutas (no es del todo así, pero para que nos entendamos).

Haz un export de los policies que tienes a ambos lados (e identifica quien es HQ y quien branch) y te digo qué nueva policy meter para llegar a ver ese equipo.

Saludos!
OK gracias por responder. Te paso los export.

Lado A (HQ)
Bash:
/ip ipsec policy
add comment=site-to-site dst-address=192.168.2.0/24 group=ike2-template-group proposal=ike2-proposal src-address=192.168.88.0/24 template=yes

Lado B (Branch)
Bash:
/ip ipsec policy
add dst-address=192.168.88.0/24 level=unique peer=ike2-hq-peer proposal=ike2-proposal src-address=192.168.2.0/24 tunnel=yes

S@lu2
 
Pues meterías estas dos nuevas:

En HQ, la template
Código:
/ip ipsec policy
add comment=access-to-branch-ont dst-address=192.168.100.0/24 group=ike2-template-group proposal=ike2-proposal src-address=192.168.88.0/24 template=yes

En Branch, el túnel
Código:
/ip ipsec policy
add dst-address=192.168.88.0/24 level=unique peer=ike2-hq-peer proposal=ike2-proposal src-address=192.168.100.0/24 tunnel=yes

Hay otra manera más sencilla de hacerlo, si montas el remoto como si fuera un road-warrior, y le chutas por configuración un split-include=0.0.0.0/0. Eso, y creando en el remoto una plantilla que se trague todo lo que le venga de HQ, haría que pudieras levantar distintas policies directamente desde HQ, sin acceder al router de branch (se irían dando de alta de manera dinámica, porque todas machearían con la plantilla remota). Pero eso ya es para nota, así que mete lo que te digo que te va a funcionar tal cual te funciona la otra política. Verás que, en lugar de un único túnel, pasas a tener dos, uno por cada segmento de red que quieres chutar de un lado al otro.

Saludos!
 
Arriba