mitrastar gpt-2541gnac Guest wifi

[kitus_san]

Hola,

al habilitar guest wifi en mi router Mitrastar, los usuarios de la guest y la no guest, comparten direccionamiento, y consecuentemente se pueden hacer ping etc.

Por favor, podéis verificar si os pasa y si hay solución . Gracias 🙂

[Theliel]

Buenas @kitus_san

En primer lugar, yo no distribuyo nada, soy un cliente como tú, como cualquier otro.

En segundo lugar, no te puedo asegurar al 100% como actualmente lo hará el Mitrastar GPT debido a que la unidad que tuve hace tiempo que partió, y ahora tengo el ASKEY desde hace tiempo, pero me consta que ambos lo hacen de forma similar.

Desde hace unas cuantas actualizaciones, y debido precisamente a la necesidad de aislar totalmente la red WIFI del resto, se optó por una separación por ebtables completa, y para evitar de echo injerencias y problemas con equipos en la red, dependiendo de la configuración, se bloquea también (en el caso del ASKEY) las respuestas DHCP que vengan "aisladas". Es decir, dado que la red WIFI de invitados queda aislada del Bridge, las peticiones DHCP externas no le llegan.

Suelo ser muy muy crítico con los desarrolladores de Movistar (ASKEY y Mitrastar principalmente) porque desde mi punto de vista las cosas no las hacen como deberían, y paralelamente con Movistar por no apretar los tornillos a estos y que hagan las cosas como es debido.... pero en este caso particular, creo que el camino que tomaron es el más adecuado en cuanto a seguridad se refiere y modo de implementarse. Sí, se podría a ver sido más.. "laxo" y a ver tenido en cuenta como excepción el permitir el tráfico DHCP completo, pero entonces tendrías a otros usuarios que se quejarían precisamente por esa posibilidad.

Recuerda que son Routers residenciales, domésticos. Cuando Movistar le da al fabricante una serie de necesidades, te aseguro que el que el cliente quiera usar su propio servidor DHCP externo, no está en la lista. En este caso se prima el uso del 99% frente al uso de un 1% (si es que llega al 1%). Para cuestiones más específicas que requiera un usuario (el cual me incluyo), tenemos nuestro propio ROuter que satisface nuestras necesidades específicas.

[kitus_san]

Hola Theliel,

muchas gracias por tu respuesta. Me gustaría saber cómo hacer para conseguir una respuesta oficial de Movistar a este caso concreto. Me parece respetable -aunque no lo comparta- que no quieran involucrarse en dar soporte a configuraciones avanzadas como se ha podido ver en este thread, pero lo que sucede con el DHCP externo en mi unidad es claramente un mal funcionamiento.

Dos reflexiones:

1. Me parece muy bien lo que comentas de ebtables e iptables, pero si cuando se usa la opción de DHCP interno, se le sirven IP a las 2 redes, es porque el planteamiento de la segmentación no es equivalente con el DHCP externo e interno.  

2. Si mi DHCP ofrece una IP, es porque le está llegando un request desde la red de invitados. Otra nueva asimetría, en este caso para la respuesta versus el request.

Si el equipo que ofrece Movistar ofrece la opción de configurar un DHCP externo, ésta debe funcionar de forma correcta. No me vale lo de que seamos un mercado residencial. O es que cuando te compras un teléfono para casa, aceptas que algunos botones no funcionen? si los botones están, deben funcionar, no?

[Dracot]

Adelanto que no conozco tu modelo de router y puedo cometer algún error garrafal en lo que voy a comentar. Me baso en lo que os he leído a ti y a @Theliel

Por lo comentado, interpreto que la implementación que hace el router del la red de invitados es, resumiendo, en capa 3 en lugar de capa 2 (según modelo OSI). De ahí que la división sea por denegación en IPTABLES, y que se permita compartir un pool DCHP.

¿Qué ocurre cuando utilizas un DHCP externo (DHCP relay)? Que el router lo que hace es tramitar los mensajes Broadcast de capa 2 que recibe encapsulandolos en un paquete unicast de capa 3 para enviar la petición al Server DHCP configurado. Si por IPTABLES de hace drop de estos paquetes capa 3, falla.

Para solucionar esto habría que editar los IPTABLES (cosa que no sé si permite el router) para permitir este tráfico y denegar lo demás.

Me reitero en que esto tiene mucho de suposición por mi parte, pero sería algo a mirar.

Saludos

[Theliel]

Buenas @kitus_san

Te estás liando y es relativamente sencillo el como lo hacen, y desde mi punto de vista no es para nada de esas cosas que hagan francamente mal. Repito, esto es válido sólo al HGU ASKEY, en el Mitrastar puede variar ligeramente, diferentes desarrolladores, diferentes modos de enfocarlo, pero a groso modo debería de ser parecido.

En su configuración normal, el equipo está preparado para usar su servidor DHCP interno al bridge principal (br0), que está compuesto por los 4 puertos Ethernet, los dos adaptadores WIFI (y sus redes de invitados si están habilitadas) y la interfaz WAN por defecto. Eso hace que todo el bridge pueda tanto enviar como recibir peticiones DHCP.

Por otro lado está el "problema" de que hacer con las redes de Invitado. Como es natural y por la propia naturaleza de estas, se decide aislar las redes de invitados del resto de dispositivos, recordemos que en este punto están en bridge con el resto, con lo que en principio pueden verse otros equipos. Se podría usar un servidor DHCP alternativo para las redes de invitados con su propio direccionamiento y quedar separado por red?? Sí, también se podría a ver optado por ese modo, pero no se hizo así. Este aislamiento se completa de dos modos:

El primero, se usa ebtables para denegar todo el tráfico desde o hacia cualquiera de las redes WIFI de invitados a nivel del propio bridge. Es decir, que en este punto cualquier equipo de una red de invitado pierde toda opción de comunicarse con otro elemento del bridge, pero por supuesto mantiene el tráfico con el Router, con lo que siguen teniendo acceso al Router (DHCP, interfaz Web...)

Bridge chain: FORWARD, entries: 4, policy: ACCEPT
-j _FW_5G_FWD4_
-j _FW_2DOT4G_FWD4_
-p IPv4 --ip-proto udp --ip-dport 68 -j SKIPLOG
-p IPv4 --ip-dst 255.255.255.255 -j SKIPLOG

Bridge chain: _FW_2DOT4G_FWD4_, entries: 6, policy: ACCEPT
-i wl0.1 -j DROP
-o wl0.1 -j DROP
-i wl0.2 -j DROP
-o wl0.2 -j DROP
-i wl0.3 -j DROP
-o wl0.3 -j DROP

Bridge chain: _FW_5G_FWD4_, entries: 6, policy: ACCEPT
-i eth4.2 -j DROP
-o eth4.2 -j DROP
-i eth4.3 -j DROP
-o eth4.3 -j DROP
-i eth4.4 -j DROP
-o eth4.4 -j DROP

El segundo, se usa iptables para filtrar el tráfico de las redes WIFI de invitados hacia el Router, para impedir que puedan estas tocar los servicios internos del Router, es decir, les filtra el acceso de ftp, web, ssh... Quedando en principio las redes de invitado totalmente aisladas

Chain _FW_2DOT4G_FWD4_ (1 references)
target     prot opt source               destination
DROP       all  --  0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in wl0.1
DROP       all  --  0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in wl0.2
DROP       all  --  0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in wl0.3

Chain _FW_2DOT4G_IN4_ (1 references)
target     prot opt source               destination
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in wl0.1 tcp dpt:22
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in wl0.1 tcp dpt:23
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in wl0.1 tcp dpt:80
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in wl0.1 tcp dpt:443
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in wl0.2 tcp dpt:22
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in wl0.2 tcp dpt:23
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in wl0.2 tcp dpt:80
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in wl0.2 tcp dpt:443
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in wl0.3 tcp dpt:22
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in wl0.3 tcp dpt:23
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in wl0.3 tcp dpt:80
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in wl0.3 tcp dpt:443

Chain _FW_5G_FWD4_ (1 references)
target     prot opt source               destination
DROP       all  --  0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in eth4.2
DROP       all  --  0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in eth4.3
DROP       all  --  0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in eth4.4

Chain _FW_5G_IN4_ (1 references)
target     prot opt source               destination
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in eth4.2 tcp dpt:22
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in eth4.2 tcp dpt:23
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in eth4.2 tcp dpt:80
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in eth4.2 tcp dpt:443
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in eth4.3 tcp dpt:22
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in eth4.3 tcp dpt:23
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in eth4.3 tcp dpt:80
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in eth4.3 tcp dpt:443
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in eth4.4 tcp dpt:22
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in eth4.4 tcp dpt:23
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in eth4.4 tcp dpt:80
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in eth4.4 tcp dpt:443

Paralelamente a ello, se aplica TAMBIEN en ebtables, un filtro para bloquear las respuestas DHCP que lleguen al Bridge, que no origine como es natural el propio Router. Esto es lo que te pasa en tu caso, y Mitrastar ya lo implementó en el HGW, aunque en ese caso bloqueaba tanto las peticiones como las respuestas:

-p ipv4 --ip-proto 17 --ip-source-port 67:68 -j DROP

Askey bloquea sólo las respuestas:

-p IPv4 --ip-proto udp --ip-dport 68 -j SKIPLOG

Mitrastar GPT hace algo similar igualmente, filtra las respuestas desde un servidor DHCP conectado al Bridge, aunque por lo que dices en su caso se debe al aislamiento de las redes de invitados del propio Bridge

[kitus_san]

Theliel, no es que me esté liando. Desde hace bastantes posts tuyos he comprendido la razón por la cual no me está funcionando mi configuración. Te agradezco tu tiempo y paciencia. Lo único que digo es que no me parece bien que Movistar entregue un dispositivo que muestra en su panel de configuración la opción de utilizar un dhcp externo, y que esa opción no funcione out-of-the-box con otra opción que también está disponible en la web de configuración, como es la wifi de invitados.

Gracias de nuevo

[kitus_san]

Hola Dracot, muchas gracias por tu tiempo! 🙂

He estado investigando y he descubierto cómo acceder al shell de mi router. Esta es la configuración de iptables

iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             10.25.101.222        udp dpt:5070
ACCEPT     igmp --  anywhere             anywhere            
RMGMT_INPUT  all  --  anywhere             anywhere            
WL_INPUT   all  --  anywhere             anywhere            
FrwlInChk  all  --  anywhere             anywhere            

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             10.25.101.222        udp dpt:5070
ACCEPT     all  --  anywhere             base-address.mcast.net/4 
NAT_FORWARD  all  --  anywhere             anywhere            
DMZ_FORWARD  all  --  anywhere             anywhere            
FrwlForwardInChk  all  --  anywhere             anywhere            
FrwlForwardInChk  all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
FrwlOutChk  all  --  anywhere             anywhere            

Chain DMZ_FORWARD (1 references)
target     prot opt source               destination         
TCPMSS     tcp  --  anywhere             anywhere             tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU

Chain FrwlForwardInChk (2 references)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
FrwlOutChk  icmp --  anywhere             anywhere             icmp echo-request
LOG        tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN limit: avg 6/hour burst 5 LOG level alert prefix "Intrusion -> "
DROP       all  --  anywhere             anywhere            
DROP       tcp  --  anywhere             Broadcom             tcp dpt:telnet
DROP       udp  --  anywhere             Broadcom             udp dpt:23
DROP       tcp  --  anywhere             Broadcom             tcp dpt:ftp
DROP       udp  --  anywhere             Broadcom             udp dpt:fsp
DROP       tcp  --  anywhere             anywhere             tcp dpt:7547
DROP       udp  --  anywhere             anywhere             udp dpt:7547
DROP       tcp  --  anywhere             anywhere             tcp dpt:44401
DROP       udp  --  anywhere             anywhere             udp dpt:44401
DROP       tcp  --  anywhere             anywhere             tcp dpt:1990
DROP       udp  --  anywhere             anywhere             udp dpt:1990
FrwlOutChk  all  --  anywhere             anywhere            
FrwlOutChk  all  --  anywhere             anywhere            

Chain FrwlInChk (1 references)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DROP       udp  --  anywhere             anywhere             udp dpt:7547
DROP       tcp  --  anywhere             anywhere             tcp dpt:7547
DROP       udp  --  anywhere             anywhere             udp dpt:7547
DROP       tcp  --  anywhere             anywhere             tcp dpt:7547
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     icmp --  anywhere             anywhere             icmp echo-request
LOG        tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN limit: avg 6/hour burst 5 LOG level alert prefix "Intrusion -> "
DROP       all  --  anywhere             anywhere            
DROP       tcp  --  anywhere             anywhere             tcp dpt:16667
DROP       tcp  --  anywhere             Broadcom             tcp dpt:telnet
DROP       udp  --  anywhere             Broadcom             udp dpt:23
DROP       tcp  --  anywhere             Broadcom             tcp dpt:ftp
DROP       udp  --  anywhere             Broadcom             udp dpt:fsp
DROP       tcp  --  anywhere             anywhere             tcp dpt:7547
DROP       udp  --  anywhere             anywhere             udp dpt:7547
DROP       tcp  --  anywhere             anywhere             tcp dpt:44401
DROP       udp  --  anywhere             anywhere             udp dpt:44401
DROP       tcp  --  anywhere             anywhere             tcp dpt:1990
DROP       udp  --  anywhere             anywhere             udp dpt:1990
ACCEPT     all  --  anywhere             anywhere            

Chain FrwlOutChk (4 references)
target     prot opt source               destination         

Chain NAT_FORWARD (1 references)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             192.168.1.3          udp dpt:1194

Chain RMGMT_INPUT (1 references)
target     prot opt source               destination         
DROP       tcp  --  anywhere             anywhere             tcp dpt:telnet
DROP       tcp  --  anywhere             anywhere             tcp dpt:telnet
DROP       tcp  --  anywhere             anywhere             tcp dpt:ftp
DROP       tcp  --  anywhere             anywhere             tcp dpt:ftp

Chain WL_INPUT (1 references)
target     prot opt source               destination         
DROP       tcp  --  anywhere             anywhere             tcp dpt:https mark match 0x3000000/0x3000000
DROP       tcp  --  anywhere             anywhere             tcp dpt:www mark match 0x3000000/0x3000000
DROP       tcp  --  anywhere             anywhere             tcp dpt:16667 mark match 0x3000000/0x3000000
DROP       tcp  --  anywhere             anywhere             tcp dpt:telnet mark match 0x3000000/0x3000000
DROP       tcp  --  anywhere             anywhere             tcp dpt:ssh mark match 0x3000000/0x3000000
DROP       tcp  --  anywhere             anywhere             tcp dpt:ftp mark match 0x3000000/0x3000000
DROP       tcp  --  anywhere             anywhere             tcp dpt:69 mark match 0x3000000/0x3000000

y ebtables

ebtables -L
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 4, policy: ACCEPT
-i wl0.1 -o eth+ -j DROP 
-i eth+ -o wl0.1 -j DROP 
-i wl0.1 -o wl+ -j DROP 
-i wl+ -o wl0.1 -j DROP 

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

Sabrías tú o Theliel indicarme qué cambio realizar para habilitar el trafico DHCP hacia la red de invitados? y hacerlo de forma permanente? En mi vida he tocado iptables algunas veces sin ser un usuario muy avanzado, pero en este caso veo sintaxis que nunca antes había visto y me acojona un poco cometer un error y brickear el dispositivo.

Gracias,

[Theliel]

Buenas @kitus_san

En ebtables,

habría que ver previamente que interfaces levanta el Mitrastar, para ver exactamente que se filtra. Por ejemplo, wl0.1 puedo imaginar que es la interfaz wifi de la red de invitados 1. Pero no sé por defecto a que o cuales interfaces afecta wl+ o eth+. Sería necesario ver cuales son las interfaces de la red de 2.4Ghz, la de la red de 5GHz, y las interfaces eth, si referencian sólo a los 4 puertos Ethernet o si se incluye también la red de 5GHz o...

Obviamente, esas reglas de ebtables están destinadas a aislar el tráfico de las redes de invitados del resto del Router, estan en FORWARD, con lo que no filtran ni restringen el acceso al Router. Dependiendo de las interfaces del sistema, y donde tengas el servidor DHCP (si está conectado por cable, si está conectado por WIFI a cual de las dos redes...), sería necesario eliminar unas u otras, pero ojo, eso a su vez produciría una rotura en el aislamiento de las redes WIFIs de invitados. La solución pasaría por crear directamente una excepción para permitir precisamente el tráfico DHCP

En iptables,

Existe la entrada en WL_INPUT aplicada a INPUT que filtra las respuestas DHCP desde servidores externos, pero no debería de afectar en lo más mínimo, al margen de que no podemos verlo debido a que no has impreso el marcado de los paquetes, que debería de estar en la tabla mangle. Por el nombre de la cadena, imagino que el match será cualquier paquete que venga de alguna interfaz WIFI, pero eso es ya mucho presuponer. De todos modos repito, está en INPUT, con lo que será el aislamiento de las redes de invitados para los servicios internos del Router.

Así que en tu caso el "problema" (que realmente no es un problema) estaría en ebtables y en el aislamiento que hace de las redes de invitados. Sin tener un plano seguro de las interfaces del Router, no podría asegurarte al 100% cual de ellas. Pero... siempre podrías crear una regla genérica en ebtables, repito, para permitir el tráfico DHCP también a las redes de invitado.

Por cierto, tampoco te serviría de mucho, en el caso de que la shell reducida del GPT (que presupongo que es a la que has accedido) te permitiese insertar o eliminar reglas ebtables, los cambios se perderían al reiniciar, resetear, apagar... y dependiendo de cuando el Router las genere, incluso puede ser que los cambios se pierdan cada vez que el Router cambia la IP o restablece la interfaz WAN.

[kitus_san]

Hola  @Theliel,

me tomo la libertad de resucitar este hilo antiguo en el que discutíamos (en el sentido más positivo de dicuss en inglés) temas muy interesantes de segmentación entre redes de invitados y principal, dhcps internos y externos, etc.

Dado que este tema se complicó mucho más de lo que yo inicialmente estimaba, acabé dejando aparcado el tema. Y por supuesto, no lo dejé listo a mi gusto, sino en modo "lentejas".

Digo "lentejas" que es como mi cabeza concluye nuestra discusión previa: Mitrastar permité configurar en su interfaz el NO uso de su servicio dhcp, y a la vez no permite que la red de invitados pueda llegar al DHCP externo.

Pregunta: cómo crees que sería la mejor forma de poder utilizar mi dhcp externo utilizando el mitrastar? debería ponerlo en modo bridge y poner un router propio por detrás? Tengo un Airport Extreme por el trastero y creo que puede levantar PPPoE. Es capaz de funcionar con DCHP externo y creo que además encapsula las peticiones DHCP de la red de invitados en en vlan 1003. Me veo una buena movida haciendo que mi servidor DHCP pase a "entender" vlans, la verdad... me da una pereza importante.

¿Que por qué quiero utilizar un DCHP externo? La verdad es que me he acostumbrado a DNSMASQ en linux. Es super cómodo para organizar las asignaciones estáticas de DHCP. Mucho más agradable que la interfaz web del mitrastar. Pero reconozco que la movida que me representa, se me está empezando a hacer cuesta arriba y el ROI empieza a no salirme... 

¿Cómo lo ves? ¿Me podrías dar tu opinión? Aunque ya lo hice a título privado en su momento, aprovecho que escribo para volverte a agradecer tu tiempo, conocimientos y ganas de hacer comunidad. 

Con lo fácil que sería que la red de invitados tirase de su propio DHCP interno, y que la red principal tuviese su DCHP dedicado...

Un saludo,

[Theliel]

Buenas @kitus_san 

Recuerda que son equipos residenciales. Crees que un ISP, que pone su equipo para sus clientes, va a tener en cuenta a quien quiera usar un servidor DHCP propio? Que % de usuarios creen que usan dicha opción. Pues a menos que la respuesta sea más de un 20%+ (por decir algo), no es algo que ningún ISP vaya a tener en cuenta, y prima más otro tipo de cuestiones.

El Askey "nuevo", por ejemplo, usa dos servidores DHCP independientes para IPTV y para el resto de la red. Al final cada Router hace un poco lo que estima, sobre todo repito los que usan los ISP. Por lo general, aquellos usuarios que tienen/tenemos necesidades específicas usamos nuestro propio Router, porque de lo contrario vas a estar siempre limitado por lo mismo.

En absoluto voy a entrar a valorar el por qué alguien quiere o no quiere usar un servidor DHCP externo. Pero si te das cuenta el problema es el mismo, lo que te lleva a querer usar un servidor DHCP externo es el que el Router no pueda usar un servidor DHCP (y configurarlo) como a ti te gustaría.

Mi consejo, en la medida que sea importante, medio-bridge y colocar tu propio Router, que soporte las funcionalidades que necesites, lo cual por supuesto incluya un servidor DHCP por dnsmasq que puedas configurar, y te quitas además dependencia externa. Aunque obviamente implique hacer un gasto económico.

[kitus_san]

Qué router usas tu? Pánico me da toda la parte de IPTV...

[Theliel]

Buenas @kitus_san 

Todo tiene sus pros y sus contras, obviamente. Un Router propio te da un control infinitamente mejor (dependiendo de lo que quieras y el Router que cojas, obviamente), pero te obliga como es lógico a gestionar tu la red, en lo bueno y en lo malo, incluso hay quien usa su propia ONT. Cada cual tiene sus motivos... incluso cuando muchas veces son "simplemente porque me han dicho que es mejor", que a mi me parece un argumento un tanto vago, pero... cada cual sabrá.

Con un HGU, en principio IPTV/VoIP no tiene mayores problemas mientras lo mantengas conectado ambos al HGU, ya que este no puede ponerse así como asi en bridge real. Usando monopuesto... "medio-bridge", la configuración es simple, repito mientras se quiera mantener TV/Telefono en el HGU. Si se quisiese que la red local pudiese acceder a dichos servicios, si sería configurar más el Router que se pusiese abajo.

Actualmente, uso de base un Askey bastante modificado en medio-bridge, y detrás, ahora mismo, un Asus ax58u con Merlin, también bastante personalizado. Por otro lado algunas funcionalidades las tengo delegadas en un Servidor-NAS (VPN, PiHole, DLNA...)

[Técnico-Movistar]

Hola @kitus_san.

Te pedimos disculpas por las molestias ocasionadas. ¿Podrías confirmarnos si con la información facilitada por @Theliel (muchas gracias por tu aportación) se ha resuelto tu consulta, por favor?

Un saludo.

Angela.

[kitus_san]

@Theliel  he decidido comprarme un R7800 y jugármela con openwrt. Sabes de algún tutorial que pueda utilizar para seguir con la configuración de vlans, etc., para Movistar TV, etc.? No es muy critico porque uso cero la parte de TV pero todo el resto de temas sí me interesan (estoy de hecho valorando sacarme la TV del paquete...). 
Duda existencial: qué pasa con el teléfono cuando pongo el router en modo bridge? Pierdo el servicio de voz?

gracias anticipadas!!

[Theliel]

Buenas @kitus_san 

Respecto VoIP, si se parte del Mitrastar HGU, solo se puede poner en medio-bridge y el teléfono se queda en el HGU, al igual que IPTV, con lo que la configuración del Router que se ponga debajo solo gestiona internet y no tiene mayor complicación, otra cosa sería querer subir hacia arriba el tráfico VoIP/IPTV.

Si se va con ONT, si es necesario tres VLAN, una para cada servicio. En ese caso para poder conectar un teléfono, si es VoIP sin problemas una vez se configura la interfaz WAN para VoIP, si es analógico se necesita un ATA

Sobre lo de tutoriales... yo soy totalmente en contra de guías paso a paso, porque al final si cambian algo ligeramente o falla cualquier cosilla, te deja KO lo que sea que se quiera hacer. Yo prefiero primero saber que estoy haciendo, y cuando lo entiendo, ya es pelearme con el sistema que sea para ver como se hace en dicho sistema. Una guía aprendes poco y puedes liarla rápidamente, si entiendes lo que quieres que hacer por contra, es mucho más simple y rápido todo.

Respecto al R7800, yo me buscaría ya un Router 802.11ax, no contemplaría bajo ninguna circunstancia irme a 802.11ac a estas alturas

[Técnico-Movistar]

Hola @kitus_san.

Esperamos que te esté ayudando el asesoramiento aportado por  @Theliel , al cual volvemos a a agradecer su aportación) para resolver tu consulta. Dejamos el hilo abierto por si deseas aportar algo mas al mismo. 

Un saludo.

Carmen

[Técnico-Movistar]

Buenas tardes @kitus_san

No hemos recibido ninguna contestación más en estos días. Esperamos que con la información que indicaron, te hayan ayudado en tu consulta. 

De todos modos, dejaremos el hilo abierto, en caso de que quieras aportarnos cualquier información más. 

Un saludo

Griselda.