Problemas con NAT en router Smart Wifi 7

Hola @bl1nx 

Muchas gracias por las comprobaciones que haz realizado con el fin de detectar el problema. Vamos a estudiar el caso con el área encargada para poder dar con alguna solución a este problema que has encontrado, y estaremos atentos si a más personas les ocurre la misma situación, por el momento, nos alegra saber que ya se ha dado solución a tu consulta y te agradecemos que lo hayas compartido con nosotros. Por nuestra parte procedemos a cerrar este hilo. Para cualquier otra duda o consulta ya sabes donde encontrarnos. Muchas gracias por haber contactado con nosotros.

Un saludo, Sebastián.

Buenas bl1nx​ 

Exactamente compi, pero eso te lo dije hace tiempo, que si estaba conectado a otro Router en modo repetidor, el HGU vería todas las IPs procedentes de la misma MAC, esto es habitual. Lo que efectivamente no es tan normal es que se haga la picha un lio, parece como si internalmente el mapeo de puertos en vez de "guardar" la IP guardase la MAC de la IP configurada, y claro... como la MAC es la misma pero varía la IP, pues podría ser el problema. Obviamente no es un comportamiento adecuado, la asignación debería de ser siempre por IP, y a la hora de hacer el reenvío el Router miraría la tabla ARP y enviaría el paquete a la MAC en la tabla, que esta sería la MAC del otro Router, y el otro Router la enviaría a la MAC real. Así es como por lo general se hacen los mapeos... parece que aquí no lo manda a la MAC realmente, sino que guarda la MAC y mira a que IP lo tiene que mandar... algo raro...

Saludos

Hola Theliel​ 

Haciendo más pruebas empiezo a ver la luz al final del túnel:

Acabo de ver claramente, que las IPs sobre las que va rotando el NAT, se debe a que todas vienen desde el router "repetidor".
Ya que dicha conexión no es capa 2, el router de Movistar siempre recibe la misma MAC de todos los dispositivos que existan detrás del segundo.

Por tanto, si quieres reproducir el problema, es súper fácil: Conectas 3 o 4 dispositivos al router de Movistar, haces un "MAC Spoofing" usando siempre la misma (desde el administrador de dispositivos de Windows, macchanger en Linux, si usas cualquier Hypervisor también te lo permite, etc).

Al poner un NAT a una IP, si existen N más con la misma MAC... PUM! y se convierte en Chocapic :)
Vamos, que si alguien te hace un ataque de envenenamiento ARP... te jode el NAT. Increíble pero cierto.

Como ya os comenté anteriormente, en más de 20 años nunca he visto nada igual.
Me parece increíble que el NAT se ponga a "averiguar" la IP detrás de una MAC cuando simplemente debería traducir la conexión, sin más.

Técnico-Movistar​ ya tenéis una pista clara sobre la que empezar a jugar.

Espero que os sea de ayuda, si se os ocurre alguna forma de solucionarlo... soy todo oídos.


Saludos!

Buenas bl1nx​ 

Pues para mi era lo único que quedaba como fleco suelto... si era un error específico de la 2.16. Llevo días con la 2.17 y tengo varios puertos mapeados, y no he visto ningún tipo de bailer en las IPs, y tampoco a otros usuarios que lo hayan tenido, aunque es cierto que el despliegue de la 2.17 está aun en curso, con lo que no podemos estar seguro si aparecerán mas casos... lo único que se me ocurre es algún tipo de interacción extraña en tu red con algún dipositivo o algo así... lo cual es un problema porque si es un bug muy muy específico y concreto, para poder cazarlo lo primero es poder replicar el escenario... sin eso es cuasi imposible. En lo personal he tratado de todos los medios diferentes escenarios para ver si en algún momento había algún baile con las IPs, pero nada. A ver si algún usuario ahora que la 2.17 se ha liberado y otros irán instalando, si alguien más puede reproducirlo y podemos encontrar nexos de unión

Hola a todos,

Esta noche el router se ha actualizado a la versión GL_g1.17_R8316_V2.17.

Para sorpresa de nadie, el problema sigue estando ahí. Para que lo tengáis en cuenta Técnico-Movistar​ 


Saludos!

Hola Técnico-Movistar​ 

Por desgracia no puedo hacer todas las pruebas que me habéis solicitado por varios motivos:

• Si configuro la DMZ expondría cosas a Internet que no quiero actualmente, ya que el balanceador que utilizo como servidor VPN está en un segmento intermedio y bloquear el acceso a la parte WAN me complicaría el acceso.

• Tengo muchas cosas corriendo 24/7 que no puedo desconectar de Internet, por lo que tampoco puedo permitirme dejar solo 1 PC conectado. Bueno, podría con failover a través de 5G, pero lo mismo, ahora mismo es un follón en el que no quiero meterme innecesariamente.

• Tampoco me interesa montar la VPN saliente, si no, este hilo no tendría sentido alguno. Tengo túneles de Cloudflare para otras cosas, pero no me interesa aquí tampoco.

• El otro router que uso como repetidor está lejos físicamente como para montar un bridge físico por lo que tampoco es viable.

Sin ánimo de ofender, agradezco toda la ayuda pero no tengo tiempo ni recursos para hacer de beta-tester (y menos gratuitamente).

Espero que vosotros podáis reproducir el error en vuestro laboratorio y hacer un análisis mucho mejor que el mío. Si necesitáis cualquier otro dato, haré lo que esté en mi mano por colaborar.

Muchas gracias a todos!

Hola bl1nx 

Agradecemos los aportes de parte de Theliel, nuestras respuestas se basan en nuestra operativa y en investigación de los problemas que plantean en este mismo foro. Siempre es un placer tenerte en la Comunidad haciendo aportes, y ampliando la información que se brinda a los usuarios. 

Por otro lado, bl1nx no hemos tenido respuesta de tu parte, te invitamos a revisar la información anteriormente proporcionada, y si necesitas algo más, nos lo hagas saber. Muchas gracias y una disculpa por los inconvenientes ocasionados. 

Un saludo, Sebastián.

Buenas bl1nx​ 

Lo raro del asunto no es que la firmware pueda tener algún bug, que seguro que la tiene, sobre todo la 2.16 que en mi opinión y creencia es quemada directamente en fábrica para poder dar soporte a la memoria de nuevas unidades...

Lo que me escama es que nadie haya reportado un problema así, y es altamente llamativo. Esto me hace pensar que es debido precisamente a la 2.16 única y exclusivamente, o a algo en tu red que está ocasionando un mal comportamiento realmente raro en el Router.

También se da un "problema" añadido un poco de carambola respecto al Downgrade, pero no por lo que dice el técnico Sebastian (a pesar de ser la suya una repuesta redactada por IA)

Técnicamente no debería de existir ningún problema en hacer un downgrade a la 2.11 y comprobar si funciona en ella o no, esto no es algo tan exótico, y aunque no suele ser recomendable, los técnicos lo han permitido en no pocas ocasiones. Es más, no es cierto eso de que "ahora mismo no hay opción de downgrade ni control sobre updates en este modelo...". Esto no es cierto, claro que se tiene control sobre este HGU, hacer un downgrade por lo general solo implica actualizarlo a una versión previa, y actualizarlo a una versión superior... en todo caso con un reset de por medio.

No obstante, como he dicho, ahora mismo sí existe un problema real que podría impedir hacer un downgrade, y esto es posible que no guste a algunos, por eso de que las comparaciones son odiosas. Lo que te puedo contar es que el RTF8316VW llamemos "original" posee/poseía 1GB RAM DDR4, al menos en las primeras orneadas. Por otro lado, desde hace ya algunos meses tengo razones más que fundadas para dar por sentado que, de forma temporal o permanente, Askey ha cambiado la RAM a DDR3, o lo que en ese momento les pueda entrar a un precio razonable (DDR4/DDR3). Esto estaría directamente relacionado al precio de la RAM que se ha multiplicado literalmente x4 en pocos meses.

Esto puede parecer un cambio menor, quitando que la RAM sea más rápida o lenta, pero a nivel de firmware si cambia la historia, porque el kernel/sistema tiene que inicializar la RAM, el Router no va a arrancar si los tiempos y otros parámetros no son correctos, hace falta un bootloader diferente. Y esa es la clave de todo y entenderás como encaja todo a la perfección, y el motivo por el que aun no tenemos una 2.16 para todos:

Hasta la llegada de la 2.11, vivíamos todos con unidades DDR4, todo perfecto. Se pone en marcha revisiones para meter DDR3... problema? No vale la firmware 2.11, se comienza a trabajar en ello, y culmina con la 2.16 certificada. Dado que las unidades DDR3 no pueden funcionar con una versión previa, a partir de ese momento se quema en fábrica la 2.16 a todas las unidades. La 2.16 por ende es la imagen actual de fábrica. Es posible que esta ni siquiera se pensase que llegase a los ciclos de actualización normales, o la retiraron por bugs, no lo sé. Ahora bien, no es necesario dos firmware diferentes, sea DDR3 o DDR4, la nueva 2.16+ detecta que RAM se tiene y quema un bootloader u otro en la flash del Router, sea la 2.16 o cualquier superior a ella, es de suponer que será la misma para todas las unidades, simplemente la firmware será algo más lista y tendrá que detectar el tipo de memoria. 

Si has llegado hasta aquí, entenderás el motivo por el cual, por carambola, no sería posible (sería altamente peligroso) hacer un downgrade a una unidad que viene con la 2.16. ¿Por qué? Pues porque si dicha unidad trae consigo DDR4, en teoría no sería problema alguno, quemaría el bootloader DDR4 y arreando... pero si lo hicieses en una unidad DDR3... en el mejor de los casos el downgrade fallaría porque no encontraría el bootloader correcto, en el peor de los casos tendrías un ladrillo.

La única incógnita que realmente aun tengo es el motivo por el cual la 2.16 no ha pasado de fábrica al ciclo de actualización general. Si ha sido por Bugs concretos, si ha sido porque tenían que acelerar para poder empezar a sacar las unidades nuevas a riesgo de tener luego que corregir alguna cosilla... 

Hola bl1nx 

Por lo que describes (cambio automático del host interno en la regla NAT cada 30–40 segundos, independientemente de IP, puerto o tipo de configuración), y tras haber descartado factores como DHCP, repetidores, IP estática o interfaz utilizada, todo apunta a un comportamiento anómalo del firmware más que a un problema de configuración.

Especialmente relevante es que:

• El cambio solo afecta al campo de IP interna del NAT
• Solo rota entre IPs activas en la tabla ARP
• Ocurre de forma periódica y reproducible
• Sucede en cualquier escenario probado

Esto no es un funcionamiento esperado en ningún caso, ya que, como bien indicas, una regla NAT no debería “reinterpretarse” dinámicamente según la tabla ARP.

A falta de confirmación oficial, encaja bastante con un posible fallo del firmware 2.16 en la gestión interna de asociaciones ARP/NAT (posiblemente algún proceso de sincronización o validación que reasigna dinámicamente el destino en lugar de fijarlo).

Dado que ahora mismo no hay opción de downgrade ni control sobre updates en este modelo, a nivel práctico te dejamos algunas alternativas que podrían servirte como workaround mientras se corrige en futuras versiones:

• Mantener la solución que ya has implementado (script que reescribe la regla NAT bajo demanda), que aunque no es elegante, es válida como solución temporal.
• Utilizar la DMZ apuntando a un único equipo intermedio (por ejemplo, el router secundario o un host dedicado) y gestionar el acceso desde ahí. Esto evita depender de reglas NAT individuales en el HGU.
• Configurar la VPN en modo cliente saliente (por ejemplo, usando un túnel hacia un VPS o servidor externo), eliminando la necesidad de apertura de puertos entrantes.
• Si dispones de un router neutro propio, valorar poner el HGU en modo monopuesto/bridge (si tu escenario lo permite) y gestionar NAT/puertos desde tu propio equipo, evitando completamente este comportamiento.
• Como prueba adicional (aunque ya has hecho bastantes), dejar una única máquina conectada directamente al router y sin más dispositivos en red, para verificar si el comportamiento persiste en un entorno completamente limpio (esto ayudaría a confirmar al 100% que no interviene ninguna tabla de red interna).

Por nuestra parte, vamos a dejar constancia de lo que has reportado como comportamiento anómalo, incluyendo el patrón de rotación basado en ARP que has identificado, ya que es una información muy valiosa para análisis interno. No podemos garantizar un cambio inmediato, pero sí que quede registrado para revisión en firmware.

Agradecemos mucho el nivel de detalle técnico que has aportado y el tiempo invertido en aislar el problema. Si detectas cualquier cambio de comportamiento o encuentras un patrón adicional, será de gran ayuda que lo compartas.

Un saludo, Sebastián.