MANUAL: EoiP sobre IKEv2 site to site

Buenos días a tod@s,

@pokoyo, works like a charm!!!

Fácil, sencillo, y para toda la familia. Ya tengo los túneles en marcha y funcionando perfectamente. Me he dado cuenta que algún cliente MK que tengo se queda cortos para manejar el caudal IPTV y están funcionando a tope de recursos, por lo que causa que al cambiar de canal (imagino mientras llena el buffer) la imagen se pixele durante 4-5 segundos iniciales.

Pero por lo demás, impresionante funcionamiento (y muy silencioso a nivel de logs). @pocoyo, tienes varias rondas pagadas de birra, muchas gracias por prestarte siempre a echar una mano a usuarios neófitos con estos chismes, como yo.


Saludos!
Me alegro de que ya lo tengas funcionando. Para lo que comentas de los clientes que no dan más de sí, busca equipos que soporten aceleración por hardware para IPSec. Es normal que un hAP-lite se tueste, por ejemplo, no así un hAP-ac2. De cualquier forma, seguiremos investigando porque lo de montar un túnel sobre otro no me gusta. Es cómodo y funciona muy bien, pero no lo veo. Lo suyo sería poder enrutar ese tráfico multicast sobre la propia vpn IKEv2, a base de políticas dinámicas. Además, el performance del túnel EoIP no es muy bueno.

Pero bueno, para hacerte el apaño rápido, te vale.

Saludos!
 
Ah! Y las cervezas, me las he de cobrar! No se cuando ni como, pero me las tomaré a tu salud.

Un abrazo majete.
 
Buenos días a tod@s,

@pokoyo, works like a charm!!!

Fácil, sencillo, y para toda la familia. Ya tengo los túneles en marcha y funcionando perfectamente. Me he dado cuenta que algún cliente MK que tengo se queda cortos para manejar el caudal IPTV y están funcionando a tope de recursos, por lo que causa que al cambiar de canal (imagino mientras llena el buffer) la imagen se pixele durante 4-5 segundos iniciales.

Pero por lo demás, impresionante funcionamiento (y muy silencioso a nivel de logs). @pocoyo, tienes varias rondas pagadas de birra, muchas gracias por prestarte siempre a echar una mano a usuarios neófitos con estos chismes, como yo.


Saludos!

¡¡¡ Felicidades !!!
Ya que lo tienes funcionando, podrías subir al hilo las configuraciones de los routers.
Sin prisas y si es posible.

export hide-sensitive file=router-HQ
export hide-sensitive file=router-site-A

Así queda constancia y nos puede servir de ejemplo a otros.
Saludos.
 
@pocoyo, la verdad es que funcionar, funciona muy bien. Si en ambos extremos el caudal WAN es bueno (ayer estuve probando con dos extremos con fibra) es impresionante el funcionamiento, diría que no llego a apreciar diferencia con el uso en local.

Para el cliente que se "ahoga" seguramente lo cambie por un RB750Gr3, con ese debe ir más que sobrado. Es un equipo muy económico para sus prestaciones.

Un abrazo!!
 
¡¡¡ Felicidades !!!
Ya que lo tienes funcionando, podrías subir al hilo las configuraciones de los routers.
Sin prisas y si es posible.

export hide-sensitive file=router-HQ
export hide-sensitive file=router-site-A

Así queda constancia y nos puede servir de ejemplo a otros.
Saludos.
@stargate4you , sin problema, a lo largo del día subo un export tanto del HQ y de uno de los clientes para que podáis echarle un vistazo y os sirva de ejemplo.


Saludos!
 
Buenos días a tod@s

@stargate4you , disculpa el retraso, ayer por la tarde tuve jaleo y no pude organizar los export's.

Adjunto configuración tanto del HQ como de uno de los clientes EoiP.

Espero os sirva.

Saludos!!
 

Adjuntos

  • cliente_a.txt
    4.8 KB · Visitas: 24
  • router_hq.txt
    15.8 KB · Visitas: 21
@stargate4you , un placer, la verdad es que es muy sencillo de montar, tal y como @pocoyo indicaba, (incluso para iniciados en MK's como yo) y funciona realmente bien.

Algo que me gusta especialmente, es que no "marranea" los logs de los equipos mientras el túnel está en ejecución o no, en ese sentido es muy "silencioso".

Gracias al compi @pocoyo, al que, si alguna vez pasa por mi tierra....tiene una buena ronda pagada.

Saludos!!
 
Hola @roolezz

Algunos comentarios sobre tu config, para que lo mires sin prisa:

En el router HQ
  • no le pongas el protocol-mode=none al bridge IPTV. Como vas a meter túneles en él, conviene tener algún protocolo de prevención de bucles, como el que trae por defecto; r-stp. A mi me vino muy bien cuando, por ejemplo, quise probar esta misma configuración y probarla en mi casa, y creé sin querer un bucle en mi red local al pinchar el WAN de un router de branch a mi red. Como ese bridge no lleva de cualquier forma hardware offloading, al llevar el igmp-snooping activado, te puedes permitir el lujo de meterle también el r-stp. Usa únicamente el protocol-mode=none en bridge-LAN.
  • No uses 1500 como MTU/MRU en una conexión PPPoE. Como máximo, vas a poder transmitir 1492. Forzándolo a 1500, causarás fragmentación. O lo pones a 1492, o directamente no lo pones, y la propia interfaz te lo pondrá en automático a 1480.
  • En el mode-config, al road-warrior, no le des una IP concreta, sino el pool de la VPN, en tu caso, pool-vpn. Así podrás conectar más de uno. De hecho, ya lo tienes hecho más abajo, llamado "ike2-conf-road-warrior", así que la entrada del mode-config que apunta a la 192.168.65.5, sobra.
  • Borra el pool-eoip, que lo creaste de mi configuración, y no lo usas.
  • Revisa los servidores DHCP. Tienes leases times enormes (el por defecto son 10min, para que te hagas una idea, y tú tienes uno de 22h). Tampoco sé qué hace el bootp-support=dynamic, ¿para qué lo usas?
  • cuando metas los puertos del 7 al 10 en el bridge-iptv, no hace falta que les pongas el hw=no, lo va a hacer así por defecto él solito, al tener el bridge con una configuración incompatible con hardware offloading. Si quieres, eso te lo puedes ahorrar.
  • En IP->Addresses, borra la red 192.168.67.1/24, que ya no la tienes asignada a ninguna interfaz.
  • En IP -> Cloud, no hace flata que definas el intervalo de actualización, lo hace él automáticamente cada vez que detecta un cambio.
  • Como ya estás usando la URL https://1.1.1.1/dns-query para el DoH, te sobran las entradas estáticas del dominio de cloudflare, no las vas a usar, las puedes borrar.
  • Revisa las reglas del chain de input, que las de ipsec las tienes duplicadas y triplicadas en algunos casos.
  • Revisa las dos reglas de drop que tienes detrás del fasttrack, para el chain de input. No tienen mucho sentido, teniendo la de "drop all not coming from LAN"
  • quita los experimentos del tcp sync del firewall, y agrupas las reglas. Input por un lado, y forward por otro, sino es imposible leer el firewall. Si tienes dudas, básate en la configuración original del firewall, y sobre esa abre los huecos pertinentes para las reglas adicionales, como la vpn o las reglas que aceptan el tráfico de las vlans de voz y tv. Te puedes fijar del router de branch, que lo tienes mucho más limpito.
  • borra el topic ipsec del logging, ahora que lo tienes funcionando. Lo tienes repetido 7 veces.
En el router branch (mucho más limpio que el otro)
  • Ponle el protocol-mode=none en el bridge-lan, si quires trabajar con HW y ese equipo es de los que tiene problema si no lo lleva (desconozco el modelo)
  • Tienes dos redes, la .88 y la .30 asignadas al mismo bridge, y con sendos servidores dhcp. ¿no se da de hostias? Borra una de las dos, en toda la configuración (dirección, pool, dhcp, etc)
  • mete las tres reglas del firewall que diste de alta para IPSec en su sitio correcto. No van al final del firewall, sino detrás de "drop invalid" del chain de input (segunda regla). Recuerda, las reglas de input por un lado, las de forward por otro, no las mezcles, o no sabrás en qué orden van.
  • Quita el cliente dhcp para el bridge-lan, no pinta nada.

Saludos!
 
Buenos días @pokoyo, muchas gracias como siempre por las aclaraciones,

Ya imaginaba que tenía muy "marraneado" el HQ, ya que con las probaturas de túneles, firewalls, y demás..he andado cambiando muchas configuraciones... Voy a echarle un ojo tal y como me recomiendas. Gracias!!


Saludos.-
 
Buenos días a tod@s,

@pokoyo, he configurado el primer "cliente", funcionando a las mil maravillas.

El problema viene con el segundo y tercer cliente. Logro levantar en ambos casos los túneles EoiP, incluso me entrega IP del bridge-IPTV de HQ, pero no hay forma de visualizar nada con los decos conectados a esos dos clientes.

Le he dado mil vueltas a la configuración y no entiendo qué puede ocurrir. Os paso export tanto del HQ como de uno de los dos clientes en cuestión, por si veis algo raro que se me pueda estar pasando.

Como siempre, mil gracias por vuestra ayuda.


Saludos!
 

Adjuntos

  • HQ.txt
    14.5 KB · Visitas: 10
  • cliente.txt
    4.8 KB · Visitas: 10
¿Te está funcionando el script de multi-desco con más de dos dispositivos? Eso sería lo primero que habría que ver, porque desconozco si lo hace. Mira el address list y la regla de nat que se crea dinámica, a ver si funciona como debe.

Lo segundo sería saber si movistar permite más de dos descos simultáneos, que esa es otra que yo desconozco.

En tu config no veo nada raro. No usaría el protocol-mode=none en un bridge con tráfico multicast y túneles EoIP que transportan ethernet. Déjalo como viene por defeto con r-stp, total ese bridge nunca va a tener HW.

Saludos!
 
¿Te está funcionando el script de multi-desco con más de dos dispositivos? Eso sería lo primero que habría que ver, porque desconozco si lo hace. Mira el address list y la regla de nat que se crea dinámica, a ver si funciona como debe.

Lo segundo sería saber si movistar permite más de dos descos simultáneos, que esa es otra que yo desconozco.

En tu config no veo nada raro. No usaría el protocol-mode=none en un bridge con tráfico multicast y túneles EoIP que transportan ethernet. Déjalo como viene por defeto con r-stp, total ese bridge nunca va a tener HW.

Saludos!
@pokoyo, sí, el script funciona con dos o más decos. De hecho en casa tengo 3 decos instalados + el cliente con túnel EoiP que ahora mismo está funcionando con otro deco más "colgando" de él.

Voy a probar a desactivar el protocol-mode=none en el bridge.. a ver si tuviese algo que ver.

Os mantengo informados.


Saludos!!
 
¿Podría venir el problema por esto?

Código:
add address=192.168.2.200/30 comment="IPTV-bridge subnet for descos" \
    dhcp-option=option_para_deco dns-server=172.26.23.3 gateway=192.168.2.1 \
    netmask=24

Cambia ese /30 por un /29. De la manera que lo tienes, sólo estás entregando ese DNS especial, que lo necesitan todos los descos, a los 4 IPs que componenen la subred /30 (192.168.2.200-192.168.2.203). Cámbiala a /29 para meter un bit más y que se asigne a 8 equipos, y comprueba que los descos remotos cogen una IP del rango 192.168.2.200 - 192.168.2.207

Si tienes 3 en casa + el cuarto remoto que te funciona, tiene sentido que el quinto en discordia no lo haga, puesto que no le llega ese DNS.

Saludos!
 
@pokoyo, tiene todo el sentido que pueda ser eso!!

Es que es rarísimo, el túnel se levanta y entrega IP correspondiente al rango del bridge IPTV...pero no hay forma que el deco conecte...por lo que tiene toda la pinta que sea problema de la entrega del DNS específico para los decos.

Cuando llegue a casa a mediodía pruebo y comentamos.

Gracias!!

Saludos.
 
Última edición:
@pokoyo, prueba fallida. Me traje a la oficina el MK de marras y un deco para probar desde aquí.

Aunque el túnel levanta perfectamente en el segundo MK, y se asigna IP desde el bridge-IPTV de HQ dentro del rango establecido (192.168.2.200 - 192.168.2.207) no hay forma de visualizar imagen en el deco, da error constantemente de conectividad.

Voy a seguir dándole vueltas a la configuración, aunque la verdad desconozco dónde puede estar el fallo...., el primer MK "cliente" funciona a las mil maravillas y los siguientes "clientes" son clones de la configuración de éste (salvando los pertinentes parámetros de IP's y MAC's)

Si se os ocurre algo, soy todo ojos.

EDITO:

Trasteando en los logs, observo que en el MK cliente "2" me asigna para el deco la IP 192.168.2.195...fuera del rango indicado anteriormente...WTF??

Por si sirve de algo...desde terminal del MK cliente "2" hago ping a una IP de los decos de mi casa, y recibo respuesta.


Saludos!!
 
Última edición:
Si no te quieres liar y esa subred 192.168.2.X no a usas para nada más que para descos, casca un /24 en la definición de la red en el DHCP y andando, así te aseguras que a todo ese segmento de red se le va a dar ese DNS concreto.

También quita el lease time ese de 1h que tienes puesto, que es más que probable que estés fundiendo las IP's y por eso te acabe dando una de fuera. Los lease time, si funcionan bien por defecto (10min), ni los toquéis

Saludos!
 
Buenos días a tod@s,

@pokoyo, en HQ dispongo de dos DHCP Servers relativos a IPTV:

1.- IPTV Common Subnet --
Address: 192.168.2.0/24
Gateway: 192.168.2.1
Netmask: 24
DNS Servers: 192.168.1.1
Domain: lan

2.- IPTV Bridge subnet for descos (supongo que te refieres a modificar éste):
Address: 192.168.2.200/29 (si intento cambiarlo a /24 no me permite hacerlo)
Gateway: 192.168.2.1
Netmask: 24
DNS Servers: 172.26.23.3
DHCP OPTION: option_para_deco

Por otro lado, ayer estuve realizando puebas con el cliente que funciona, y me he dado cuenta, que todo el tráfico "sale" a través de bridge-LAN en vez de bridge-IPTV ¿¿??? El deco está conectado a uno de los puertos del MK que está asociado a bridge-IPTV....sin embargo...podéis observar el "pantallazo" que tomé ayer con la app de Mikrotik para Android.

Adjunto export del MK en cuestión por si observáis algo raro. Lo único extraño que veo es que hay dos DHCP servers (supongo porque arrancaría la configuración con Default configuration y se me pasó quitarlo.


Saludos!! Screenshot_20210525-203114_MikroTik.jpg
 

Adjuntos

  • cliente_funciona.txt
    5.3 KB · Visitas: 15
Deja un único servidor DHCP relativo a IPTV. Eso está así hecho por si parte lo tienes que dedicar a IPTV y, sobre ese mismo segmento, tienes otro tipo de clientes que necesitan internet tal cual. Yo dejaría un único DHCP para IPTV, con el rango completo (usando el pool desde 192.168.2.2 - 192.168.2.254) y con la seguiente definición de red:
Código:
add address=192.168.2.0/24 comment="IPTV-bridge subnet for descos" \
    dhcp-option=option_para_deco dns-server=172.26.23.3,192.168.2.1 gateway=192.168.2.1 \
    netmask=24
 
Arriba