MANUAL: EoiP sobre IKEv2 site to site

Nada, no tengo c****** a echar a andar el "tinglado". He probado numerosas reglas de input/output para firewall, según he estado leyendo por internet, pero no hay forma que el deco. Todo va de perlas, el túnel levanta rapidísimo, conecto en remoto desde cualquier PC y navego perfectamente por mi red...pero el deco...nanai. El caso es que si reviso la config propia que recibe el deco por DHCP, es correcta (IP, puertas de enlace, DNS específica para IPTV...)

Como no se me ocurre qué mas probar...estaba pensando si sería viable montar el citado túnel EoiP sobre Wireguard, y dejar Ikev2 para conectar en remoto desde PC's/Móviles a HQ. ¿Cómo lo veis? ¿Sería viable?

Como siempre, mil gracias!


Saludos.-
 
Nada, no tengo c****** a echar a andar el "tinglado". He probado numerosas reglas de input/output para firewall, según he estado leyendo por internet, pero no hay forma que el deco. Todo va de perlas, el túnel levanta rapidísimo, conecto en remoto desde cualquier PC y navego perfectamente por mi red...pero el deco...nanai. El caso es que si reviso la config propia que recibe el deco por DHCP, es correcta (IP, puertas de enlace, DNS específica para IPTV...)

Como no se me ocurre qué mas probar...estaba pensando si sería viable montar el citado túnel EoiP sobre Wireguard, y dejar Ikev2 para conectar en remoto desde PC's/Móviles a HQ. ¿Cómo lo veis? ¿Sería viable?

Como siempre, mil gracias!


Saludos.-
Tu problema no es el túnel que soporta el EoIP, ese ya has comprobado que funciona. Tu problema es que el tráfico multicast, por lo que sea, no está fluyendo.

Has probado a modificar la regla de firewall que acepta el tráfico multicast en input en el router HQ? Para probar, yo eliminaría los filtros y aceptaría todo tráfico de la vlan2&3.

De igual forma, revisaría las reglas de NAT, y haría una específica, a mano, para la IP que coja el desco al otro lado, sola y específicamente para la vlan de tv. Te puede estar pasando que el tráfico se esté colando por una regla previa de NAT, antes de entrar por la que tú quieres que entre. Juega con el orden de las mismas.

Saludos!
 
@pokoyo, ahora mismo tengo estas reglas relativas a Vlan2&3:

/ip firewall filter
add action=accept chain=input comment="Accept vlan2 Iptv IGMP packets" \
in-interface=Iptv-vlan2 protocol=igmp
add action=accept chain=input comment=\
"Accept vlan2 & 3 (Iptv & Voip) multicast & broadcast traffic" \
dst-address-type=!unicast in-interface-list=Vlan2&3
add action=drop chain=forward comment=\
"Drop all new unicast traffic from vlan3 & 2 (Voip & Iptv) not DSTNATed" \
connection-nat-state=!dstnat connection-state=new dst-address-type=\
unicast in-interface-list=Vlan2&3

/ip firewall mangle
add action=set-priority chain=postrouting comment="Prioritise Iptv packets" \
new-priority=4 out-interface=Iptv-vlan2 passthrough=yes
add action=add-src-to-address-list address-list=vod-receiver \
address-list-timeout=1m chain=postrouting comment="RTSP - VOD Movistar" \
dst-port=554 out-interface=Iptv-vlan2 protocol=tcp

/ip firewall nat
add action=masquerade chain=srcnat comment=\
"masq. vlan2 & vlan3 (Iptv & Voip)" out-interface-list=Vlan2&3
add action=dst-nat chain=dstnat comment="VOD Script" dst-address-type=local \ <--- Esta ya probé añadiendo reglas con otras ip's sin éxito
in-interface=Iptv-vlan2 to-addresses=192.168.2.201

Entiendo que debería quitar la regla de DROP, es así?


Saludos!
 
Yo comentaría todas esas reglas que atañen a la vlan2&3 del firewall filter, y añadiría una que acepte todo tráfico que venga de esa lista de dos interfaces, sin especificar filtrado alguno. Algo así como esto
Código:
/ip firewall filter
add action=accept chain=input comment="Accept vlan2&3 traffic" \
in-interface-list=Vlan2&3
Y la pondría justo de la regla del drop invalid, la segunda por defecto que trae el router.

Saludos!
 
Dicho y hecho, voy ahora mismo a modificarlo y a mediodía pruebo en casa. Os voy contando.

Entiendo que debe ir antes del drop-invalid, no?

@pokoyo, mil gracias como siempre por tu paciencia!!

Saludos.-
 
Dicho y hecho, voy ahora mismo a modificarlo y a mediodía pruebo en casa. Os voy contando.

Entiendo que debe ir antes del drop-invalid, no?

@pokoyo, mil gracias como siempre por tu paciencia!!

Saludos.-
No; justo despues. Las dos primeras reglas deben ser siempre la del “accept established,related,untracked” y el “drop invalid”. Luego metería la del “accept ICMP” y, tras esa, la que te digo.

También haría un arranque en frío de los descos, desenchufándolos para dejar que arranquen “en frio”. Van a tardar más en arrancar (hasta 10min), pero así te aseguras de que lo tienes correcto.

Saludos!
 
Perfecto, ya he dejado la regla en HQ en el orden que indicas, de hecho ya veo tráfico a través de la nueva regla (me habré dejado algún deco encendido seguramente...)

En los branch entiendo que no habría que poner ninguna regla más, no?

Saludos.-
 
Juraría que no, que en la branch no necesitas nada más.

Saludos!
 
Nada, seguimos en las mismas. En el túnel hay tráfico, pero no todo el que tendría que haber cuando se transmite multicast (7-8mb/s)

Me tiro de los pocos pelos que me quedan...


Saludos!
 
En el remoto, ¿te llega a salir algo en la tabla MDB del bridge (Bridge -> MDB) ?

Saludos!
 
También puede ser, cierto es que cuando configuro el túnel con Ipsec, por "narices" tengo que desactivarlo.

En breve os cuento, a ver si damos con la tecla, porque la verdad el Ikev2 es un cañón, ahora estoy desde la oficina conectado por VPN a mi casa y pasando cosas del NAS...y es bestial como va....


Saludos!!
 
@pokoyo, desactivado fasth-path, seguimos igual.

Adjunto pantallazos tanto de branch como de HQ, donde sí aparecen IP's en las tablas MDB de ambos routers. Ves algo raro?


Saludos.-
 

Adjuntos

  • branch.jpg
    branch.jpg
    130 KB · Visitas: 14
  • hq.jpg
    hq.jpg
    191.4 KB · Visitas: 17
Hostias; pues eso significa que el musticast sí que está pasando por el túnel EoIP. Pues tiene que ser una chorrada ya lo que le pasa, porque ya no se me ocurre mucho más.

Juraría que no hace falta en el router remoto pero, ¿tienes el paquete de multicast instalado allí también?

Otra cosa que miraría es en hacer un arranque en frío, como te comentaba esta mañana.

La regla de NAT, ¿tiene buena pinta también?

Saludos!
 
He modificado la config del EoIP y lo he puesto sin pasar por road-warrior, es decir, el EoIP "de toda la vida" apuntando cada extremo a las DDNS y con clave IPsec.

Adjunto pantallazo para que veáis comportamiento. Ahora tampoco me funciona el deco de esta forma, además el extremo "branch" no pasa a Running...sin embargo...el túnel en HQ sí.. ¿?


Saludos!
 

Adjuntos

  • Nueva imagen.jpg
    Nueva imagen.jpg
    452.5 KB · Visitas: 12
Hostias; pues eso significa que el musticast sí que está pasando por el túnel EoIP. Pues tiene que ser una chorrada ya lo que le pasa, porque ya no se me ocurre mucho más.

Juraría que no hace falta en el router remoto pero, ¿tienes el paquete de multicast instalado allí también?

Otra cosa que miraría es en hacer un arranque en frío, como te comentaba esta mañana.

La regla de NAT, ¿tiene buena pinta también?

Saludos!
Sí, he instalado el paquete multicast en branch, he realizado arranques "en frío"...y en cuanto a NAT...te paso pantallazo a ver qué opinas. Es el de HQ, en branch el NAT está limpio.

Saludos!
 

Adjuntos

  • Nueva imagen.jpg
    Nueva imagen.jpg
    131.9 KB · Visitas: 15
Me resulta raro que las reglas de NAT nuevas no muevan ningún paquete. Porque son esas últimas las que deberían tener tráfico, ¿no? Quiero decir, que son las que se generan automáticamente cuando el script detecta una nueva IP en el pool de iptv. Qué narices te estará fallando macho, si parece que esté todo bien...

Saludos!
 
Mueve la regal que creamos esta mañana, la que acepta el tráfico del firewall de la lista de interfaces Vlan2&3 arriba del todo, justo antes del drop invalid. Lo único que se me ocurre es que alguna regla de drop te esté jodiendo.

como prueba momentánea, puedes probar a deshabilitar temporalmente todas las reglas de drop en HQ, a ver qué narices hace...

No veo nada más raro tío, el resto está clavado a como lo puso @furny en su día.

Saludos!
 
Nada macho...ni por esas...

No sé si tendrá algo que ver...., el cliente DHCP entrega al router branch la IP 192.168.2.192, en tanto que al deco se asignan IP's de la .2.200 en adelante.

Es correcto? Tendrá algo que ver el NAT que genera la conexión del móvil donde tengo enganchado el branch para las pruebas? Entiendo que no, puesto que el túnel levanta y el Ikev2 va de maravilla.

Algo se tiene que estar escapando, tengo los "sesos líquidos" ya...jaja

Mil gracias por tu ayuda, @pokoyo! Solo por pesado...esto tiene que salir adelante.


Saludos!
 
Arriba