Ubiquiti Cloud Gateway Ultra y Movistar TV

Hola EnJaume 

Vemos que has aceptado el post como solucionado, nos alegra que la información que te hemos brindado haya sido de utilidad.

No dudes en contactar de nuevo con nosotros si tienes cualquier consulta y/o problema.

¡Gracias por confiar en nosotros y participar en la Comunidad!

Un saludo.

Ronal.

Gracias por la respuesta.

Creo que lo mas sencillo sera dejar el HGU como "semi-bridge" para que gestione la vlan de voip y pasar al gateway de unifi la vlan de internet. (de hecho, asi quito 2 cacharros y dejo solo 1)

Buenas EnJaume 

Tu escenario en principio es totalmente diferente al del compañero. El compañero se vale del HGU para la configuración de las 3 VLAN, en tu caso al tener la ONT delante (si solo es la ONT), todo pasa al Router propio.

Escenario con ONT:

Las 3 VLAN se pasan al Router propio, este tiene que configurar cada VLAN de forma independiente, y cada un con sus peculiaridades. Internet como PPPoE, VoIP como cliente DHCP automático, e IPTV IP manual. Tanto en IPTV como en VoIP las rutas se deberían de obtener por RIP, el GW creo recordar que tenía Zebra, con lo que se debería de poder usar para ello, además de reconfigurar IGMP Proxy para la interfaz VLAN levantada para IPTV.

Escenario con HGU:

Sería el mismo que el anterior, de echo está puesta la configuración básica para que funcione más arriba, estableciendo las rutas necesarias manualmente. Podría ser necesario, o no, el uso igualmente de un ayudante SIP. Al igual que pasa con RTSP en IPTV, pasa algo similar con SIP. Ahora mismo si te soy sincero no recuerdo si lo traía o no, tendría que mirarlo.

Madre mia, me quito el sombrero, no solo por los conocimientos sino por la voluntad de colaborar de Theliel 

(después de los halagos, la pregunta... 😁). No sé si abrir otro hilo, o dejarlo para que quede todo "empaquetado en este"

A mi sólo me interesa la parte teléfono, no la TV. Tengo un gateway ultra + ont + ata spa122. No tengo manera que me registre correctamente (lo tenia funcionando bien en mi antiguo asus, puestos los proxys de telefonica, coge ip.... así que creo que es algo de unifi)

Hola nandex 

Agradecemos a Theliel por su colaboración y nos alegra que te haya servido de ayuda.

Nos alegramos de que ya este funcionado de forma correcta, gracias por confirmárnoslo. No dudes en contactar de nuevo con nosotros si tienes cualquier consulta y/o problema.

¡Gracias por confiar en nosotros y participar en la Comunidad!

Un saludo.

John.

Buenas nandex 

"terminado". Este es un doble post para tener la información ordenada.

Este primero, un poco de antesala, problemas/soluciones. El siguiente con la configuración válida... aunque es una ñapa y tiene alguna limitación.

Efectivamente, el último escollo es debido a que ubi no tiene implementado ningún ayudante para RTSP. Te explico rápidamente que es esto y la única solución que he encontrado, hasta que ubi quiera o no implementarlo o se pueda compilar un módulo válido... los dos que he intentado no han funcionado, posiblemente debido a no tener el código del kernel... en teoría lo tendrían que suministrar por ley.

Existen protocolos en Internet que no son amigables con NAT. NAT es el mecanismo que permite compartir tu conexión con otros dispositivos, así realmente tus dispositivos están en una red privada y no están expuestos a Internet. Esto por otro lado es positivo por seguridad.

El funcionamiento básico de NAT es sencillo. Cualquier conexión desde tu red local hacia fuera, se realiza perfectamente, y el Router realiza un seguimiento de esas conexiones, de modo que cuando el destino responde a esa conexión, el Router que hace el seguimiento de dicha conexión sabe a quien enviar dicho tráfico que le llega. Perfecto.

Pero por su propia naturaleza, si el Router recibe tráfico externo que no ha sido solicitado previamente, lo descarta. Es decir que si la conexión se inicia desde Internet, se descarta por defecto. Esto es normal por otro lado, como podría saber el Router para quien diablos es ese tráfico si no ha sido solicitado previamente. Es por esto que algunos juegos/servicios/aplicaciones requieren "apertura de puertos", es como decirle al Router que todo el tráfico que le llegue por un puerto concreto, lo reenvíe a un dispositivo de la red local específico.

El problema es que hay protocolos que no les gusta mucho esto. Por ejemplo FTP o RTSP. Ambos protocolos, usan por un lado una conexión de control y otra de datos. La conexión de control si la establece el cliente (el deco en este caso, o un PC con un cliente FTP), y ese tráfico se permite, pero en esa comunicación ambos (servidor y cliente) negocian un puerto de datos, y el servidor comienza a enviar datos a ese puerto. Problema? Que el servidor no está hablando realmente con el Router sino con el deco en este caso, y si el servidor comienza a enviar datos al puerto de datos previamente negociado con el cliente, desde el punto de vista del Router, es una conexión que se está iniciando de forma remota hacia un puerto propio que no está en su lista de redirecciones ni en el seguimiento de conexiones, y descarta el tráfico.

Dicho de otro modo

El Deco con IP 1.100 y usando el puerto 123 solicita tráfico al servidor 172.1 a su puerto 666. El servidor le dice que OK y que le va a pasar la peli por el puerto 999. Toda esa comunicación la inicia el deco y se realiza siempre por el mismo puerto del deco y del servidor.

El servidor ahora empieza a enviar la peli al puerto 999 del Router como han acordado, a veces incluso desde otro puerto diferente al 666 y a veces incluso el que lo hace es otro servidor diferente!!. El Router no reconoce el tráfico, no está en su tabla de seguimiento o de ningún mapeo... y lo descarta.

------------------

Para solucionar esto, se crearon los "ayudantes". Existen en esencia "ayudantes" para cada uno de estos protocolos un tanto díscolos. Ubi sí implemente la mayoría de ellos, puedes verlos si vas a Security y Traffic/Firewall, donde pone Contrack modules. PERO, no está RTSP. El ayudante de RTSP lo que hace es que "captura" el tráfico RTSP de control donde se negocia el puerto que se va a usar, y "crea" un mapeo de puertos dinámico hacia el dispositivo que está negociando el stream al puerto concreto que sea. 

No es la única forma de hacer esto. Otra opción sería que el cliente RTSP, en este caso el Deco, a través de NAT-T/upnp abriese de forma dinámica el puerto necesario. Es decir, que ahora funcionaría porque el cliente una vez negocia el puerto induce al Router a abrirle un puerto específico para él. Movistar podría implementar esto en el deco y se terminarían los problemas con RTSP? Absolutamente, y personalmente creo que es mejor opción porque es más universal. Eso sí, el Router requeriría tener habilitado upnp y que este funcionase adecuadamente en diferentes interfaces WAN.

Mientras que ubi no implemente este ayudante, o podamos compilar uno en condiciones que funcione, la única ñapa que se me ocurre es configurar iptables para que permita de facto todo el tráfico que viene de la red de IPTV de Movistar, y lo redirija al deco. Y sí, hará que funcione, pero tendrá algunas limitaciones:

1º. Tan solo podrá tenerse un Deco en la red

2º. Tendremos que tener fijada por DHCP la IP del deco... similar a cuando teneos que mapear un puerto a un dispositivo de nuestra red, le tenemos que poner una IP  fija.

3º. El deco puede estar recibiendo más tráfico del que debería

4º. Posiblemente oros problemas que no se me han ocurrido.

La buena noticia por otro lado es que es posible.

En el siguiente post pongo la config funcional, comprobado y testado en este UX.

NOTA: Algunos parámetros dependen de cada dispositivo específico, no existe una configuración universal. Diferentes dispositivos posen diferentes interfaces, configuraciones potenciales... e incluso las firmwares son diferentes entre los diferentes modelos. Eso sin contar con que los parámetros de configuración IPTV /VoIP son diferentes según cada uno.

Sí, se podría hacer un script de configuración guiada donde se solicitase los datos al usuario e incluso obtener las diferentes interfaces directamente desde el propio dispositivo... pero bueno eso ya es trabajo para otros 🙂

Saludos

Hola nandex 

Agradecemos a@Theliel su colaboración y nos alegra que te haya servido de ayuda. 

Por otra parte, si consideras que tu consulta está resuelta, te agradeceríamos que en el hilo que has abierto, pulsases en el botón “Aceptar como solución” del post en el que se te ha resuelto tu caso. Es importante para nosotros que vuestras consultas queden resueltas y para otros usuarios es útil utilizar estas respuestas para sus dudas.

Un saludo, Nicoll.

Menuda odisea, espero que se pueda llegar a buen puerto. Muchas gracias por tu tiempo y dedicacion Theliel . A mi con que pudiera funcionar el iptv con VOD y el 7 dias me valdria a la perfección pero es verdad que lo ideal es que funcione todo. 

graciasss

Buenas nandex 

A ver, un pequeño resumen porque no podré ponerme hasta el lunes ya, cuento rápidamente luces y sombras

No sé el resto de modelos, pero la configuración por web es bastante limitada y tediosa, eso último opinión personal. La mayoría de los ajustes no pueden hacerse por la interfaz Web debido a que por diferentes matices no permite especificar algunas cuestiones importantes. Todo aquello que no puede hacerse por la interfaz Web se requiere hacerlo manualmente por Shell.

Algunas nociones a tener claras antes de nada:

El Router en cuestión posee dos interfaces Ethernet, llamadas eth0 aka "lan" y eth1 aka "wan". Cuando creamos un marcado PPPoE, este crea como es habitual una interfaz virtual, que vamos a llamar pppoe. Esto puede variar de modelos, fabricantes.... pero espero intentar no confundir cundo hablo de WAN si es a la conexión PPPoE o a eth1. Es decir, la conexión PPPoE es una interfaz Virtual que hace uso de la interfaz física eth1. Desde el punto de vista del Router son dos interfaces diferentes.

1º. Es necesario especificar datos IP correctos a la interfaz eth1. Esto no lo permite... lo permite si configuras WAN como IP, pero no si levantas una conexión PPPoE. Sí, la conexión PPPoE recibe los datos IPs, pero el puerto físico (no la conexión PPPoE que es una interfaz virtual) no se puede. Esto requiere por ende hacerlo de forma externa.

2º. Rutas.... las rutas son necesarias y son básicas. Y sí, se pueden añadir Rutas estáticas. No obstante, al menos en este modelo, no se puede escoger una interfaz física concreta para ellas. Es decir, que si se crean, estas son para la interfaz WAN por defecto (que será la conexión PPPoE, no el puerto físico). Por el mismo motivo que el punto primero, tenemos que hacerlo de forma externa.

3º. Enmascaramiento... exactamente lo mismo, se pueden crear enmascaramientos, pero no escoger la interfaz física... los hace sobre la conexión PPPoE...

4º. IGMP Proxy... exactamente lo mismo. IGMP Proxy se levanta sobre la interfaz PPPoE, pero el tráfico IPTV no viene desde PPPoE (Internet), sino desde el HGU, que se accede por eth1. A sí que no nos vale, otro problema a solucionar.

5º. Servidor DNS alternativo... no he rebuscado enormemente por la interfaz web porque potencialmente es posible que se pueda con el control de filtros o de algún otro modo, pero no se podría añadir de todos modos el Option240. Así que de nuevo lo tenemos que hacer de forma externa.

6º- RTSP... Houston, tenemos un problema.

------------

Ya pondré con más tiempo todo, pero analizando los puntos anteriores, se requiere obligatoriamente configuración manual por medio de la Shell. Para que esto tenga sentido debemos de permitir de algún modo que el ROuter ejecute el código al iniciarse, de lo contrario no es útil... te imaginas tener que teclear y teclear cada vez que reinicias?? No gracias.

Ubiquiti ha deshabilitado esta opción en estos modelos, curiosamente lo permite con los EdgeRouter... De forma nativa no podemos hacerlo. Por suerte no está todo perdido, y gracias a un pequeño paquete que podemos instalar por shell, nos otorga la posibilidad de poder ejecutar tantos scripts como queramos al inicio. No me detengo ahora en enlaces, códigos y otros, es solo un resumen de momento.

Solucionado el problema por tanto del poder crear scripts, el resto es poner en orden todo lo necesario. Hablo de varios pero puede ser un solo script.

1º. Un script para añadir la configuración que necesitamos al servidor DHCP del Router (dnsmasq). Por suerte el Router añade a la configuración de dnsmasq todo lo que esté en una carpeta concreta, con lo que solo tenemos que crear en tiempo de ejecución el archivo. Ahí ponemos simplemente que vamos a usar un IDVendor [IAL] al que los clientes les vamos a asignar un servidor DNS en particular y un Option240. Así que una vez creado se reinicia el servidor DHCP y listo.

2º. Un script para configurar los datos IPs de la interfaz eth1 (depende del modelo puede ser otra interfaz diferente, en mi caso WAN es eth1), se le asigna IP, máscara. Con esto pasamos a añadir las rutas estáticas. Y para terminar, en ese mismo script lo he usado para levantar IGMP Proxy... como he dicho este lo puedes habilitar en la interfaz Web, pero solo lo habilita para PPPoE, eso no nos vale de nada. Así que el mismo script crea un pequeño archivo de configuración e invoca el proceso que se hace cargo de igmp proxy.

3º. Un script para contener diferentes reglas que puedan ser necesarias para iptables... como mínimo el enmascaramiento.

------

Ok, hasta aquí todo funciona perfectamente, lo conecté pensando que estaba todo y... casi funcion todo. Llegados a este punto todo funciona como debería. La interfaz eth1 se configura bien, las rutas se añaden bien, el servidor DHCP asigna perfectamente los datos al deco e IGMP Proxy funcionando en la interfaz adecuada.

Entonces solo hace falta un archivito a copiar y listo? Nop, me temo que no, creía que estaba todo pero no... es más, creo que la primera vez funcionó tal cual pero tengo ya dudas.

Funcionan las cadenas por supuesto, funciona VOD (lo que he podido comprobar), la guía...  en principio funciona todo exceptuando el time shift y no he comprobado 7UD. No he tenido mucho tiempo de revisarlo todo, pero estoy bastante convencido de que es un problema con RTSP.

RTSP es un protocolo de transmisión de streams, y es uno de esos "maravillosos" protocolos que no son amigables con NAT... los Router si quieren funcionar bien con ellos, requieren de "ayudantes" para ello. El Router en cuestión posee unos cuantos ayudantes integrados, incluso habilitados por defecto... pero no el ayudante de RTSP. He mirado en toda la firmware para ver si quizás no estaba cargado pero si existía... y no, no está en la firmware.

Llegado a este punto estamos en complicaciones importantes. Si realmente es debido a esto, y tiene toda la pinta que sí, las opciones son limitadas:

1º. Ideal, buscar un módulo compatible (quizás en ddwrt o en alguna otra suite, incluso intentar sacarlo de los edgeRouter que sí está presente) y cargarlo. Esta opción sería rápida y efectiva... si el módulo compilado funciona, claro

2º. Hacer un remapeo de puertos brutal o DMZ hacia el deco para que reciba el tráfico RTSP... no es buena idea, no adecuado, no gusta.

3º. Intentar compilar el módulo para unifi... problema?? Pues para empezar que no veo lugar donde Ubiquiti haya publicado el código fuente del kernel, y sin él no se puede asegurar que funcione como es debido...

--------

La semana que viene intentaré asegurar de que es ese el problema, y si lo es intentaré probar algunos módulo ya compilados... pero que funcione o no es más suerte que otra cosa.

Indicar que ubiquiti ya le pasó algo similar con EdgeRouter y terminaron incluyéndolo internamente el módulo, en unifi, o al menos este modelo, no está presente. Igual está presente en otros, no lo sé, pero en este no. Puedo intentar ver una versión más vieja u otro modelo por si por casualidad lo incluyeron en algún momento, pero poco más.

Con el kernel también podríamos compilarlo, al menos intentarlo... es más, ubiquiti tiene obligación de suministrar el código GPL del kernel, en teoría si se solicita lo tienen que dar. Eso sí... a saber cuanto tiempo tardarían...

Hasta aquí por ahora!

Saludos.

Edito: He compilado un módulo de un helper para rtsp, no obstante no he podido usar el kernel 4.4.60 de ubi, sino el kernel 4.4.60 oficial con el config de ubi. El módulo se carga correctamente pero no he podido probarlo, la semana que viene ya