Problema Mitrastar Gpt-2541GNAC Firewall

zooid
Yo probé el VDSL
Problema Mitrastar Gpt-2541GNAC Firewall

Buenas tardes,

 

Telefónica me acaba de cambiar el router una vez mas, así llevo desde Oct 2015 ha razón de cortes I perdida de IP y VoIP.

 

El nuevo router es el Mitrastar Gpt-2541GNAC con firmware 1.00(VNJ.0)b31 Tengo contratado Fusión-Pro 300/300

 

El Problema que tengo es que una vez que se marcho el técnico de telefónica me puse a configurara el router y descubrí que el Nat -> Virtual Server no permite especificar el RemoteHost IP Address. Un paso hacia atrás. Así que decidí que seria mejor utilizar el Firewall del router.

 

He programado el Firewall -> Rules especificando el ip externo, el puerto externo, el ip interno y el puerto interno de las reglas que necesito. He verificado por medio del fichero backupserttings.conf que la programación de las nuevas Rules del Firewall están correctas y que las ha aceptado el router.

 

EL problema es que el router no esta dando acceso al IP externo por el puerto especificado a el ip interno en el puerto especificado, es decir ignora las Rules programadas en el Firewall.

 

He incluso probado las Rules que vienen de fabrica, para ver si las obedece y he descubierto que no, que no da acceso incluso ha estas.

 

Para colmo, cunado llamo al 1002, me comentan que este tipo de servicio técnico no se recoge en el contrato y que busque en Google para una solución.

 

Si alguien sabe como forzar que el router cumpla las reglas definidas en el Firewall por favor mencionar me el truco.

 

Saludos

Daniel

Mensaje 1 de 7
3.279 Visitas
6 RESPUESTAS 6
zooid
Yo probé el VDSL

He encontrado en Advance setup -> Wan service si edito el  ppp0.1 veo que existe una opción llamada Enable Fullcone Nat 

que es justo lo que necesito ya que esta función permite definir tanto el IP del punto de origen como el IP de destino.

 

He habilitado esta opción, pero el router no permite definir estos dos ip cundo se especifica reglas en el Nat, es decir cuando creas un nuevo Virtual Server.

 

He apagado el router por si las moscas y he vuelto ha probar crear un nuevo Virtual Server, pero sigue sin dar esta opción.

 

Mi conclusión es que este router + versión firmaré tiene muchos problemas y bugs. Pero lo que me resulta más difícil entender es la aptitud de telefonica o por lo menos las dos personas con las que hable en el 1002 que me indican que me busque la vida en Google sobre un producto que me venden ellos y que no es apto para uso como router.

 

Espero que alguien en este foro tenga los conocimientos para indicarme que me estoy equivocando y me explique cómo hacer que este router agua algo tan fácil como Fullcone Nat cuando se habilita esta opción.

 

saludos

daniel

Mensaje 2 de 7
3.237 Visitas
zooid
Yo probé el VDSL

No puedo creer que soy la única persona con este router que ha descubierto que el NAT no funciona en modo full-cone cuando se activa esta opción ???

 

Tampoco me creo que soy la única persona con este router que ha creado reglas en el firewall para descubrir que el firewall no las implementa????

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

En otro hilo me han comentado que:

 

Parece ser que el FW es para uso exclusivo de los servicios internos al router.
La NAT no ofrece la posibiidad de filtrar mas aya de loque expone en la interface WEB. Pero si existe la posibilidad de aceder a la shel i configurar loas iptables.

 

 

Saludos

Daniel

Mensaje 3 de 7
3.207 Visitas
ecubamad
Mi vida cambió con el ADSL
A mi me está pasando igual. Alguien ha podido resolver?
Mensaje 4 de 7
2.995 Visitas
Theliel
Yo probé el VDSL

Buenas @ecubamad

 

Creo que el usuario anterior también llevó a la confusión, y puede auqe a ti suceda lo mismo.

 

Una cosa son las reglas del Firewall, otra cosa es el PortForwarding/VirtualServer, son dos cosas totalmente diferentes, y si no se entiende que es una cosa y la otra, hay problemas.

 

PortForwarding/VirtualServer es lo que llamamos de forma generalista apertura de puertos. Dado que el Router hace NAT y que como es natural el Firewall se configura por defecto para bloquear todo el tráfico entrante no solicitado, es necesario "abrir puertos" cuando se requiere de alguna aplicacion por parte de algún equipo de la LAN que pueda recibir tráfico sin ser solicitado antes, generalmente programas tipo servidor.

 

Estas "aperturas" o redirecciones de puertos especifican al Router que si el tráfico alcanza al Router por el puerto X, este lo envia a la IP interna que sea al puerto que sea.

 

Otra cosa totalmente diferente son las reglas del Firewall. Estas reglas no son mapeadores de puertos y no se pueden ni deben de usar de este modo. Dado que por defecto la política de los FW es de denegar todo lo que no se solicite, en todo caso es necesario permitir aquello que si se desea

 

Hay un pequeño problema de comprensión aquí de lo que es FullCone NAT. El modo de funcionamiento por defecto de la mayoría de Routers es usando NAT simétrico, es decir, que cada conexión que realice cada equipo de la red a cualquier destino, es mapeada en la tabla NAT, incluso si son difererentes conexiones al mismo sitio, asignando en cada mapeo un puerto diferente en el Router, y de aquí hacia fuera. Es el modo más seguro, dado que tan solo se aceptarán aquellas conexiones entrantes que hayan sido solicitadas con anterioridad y al puerto que fue mapeado originalmente por conexión.

 

Esto hace que sea imposible por tanto usar aplicaciones tipo servidores, así que por eso tenermos PortForwarding/Virtual Server. Cuando se hace uso de esto, lo que se está haciendo precisamente es creando una excepción en el Router para usar Full Cone NAT... es decir, sí, FullCone NAT es de facto PortForwarding, o mejor dicho... PortForwarding lo que hace es FullCone  NAT

 

Así que resumiendo... Firewall Rules para establecer filtrados, reglas... PortForwarding para mapear conexiones/puertos/redireccionar



Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 5 de 7
2.988 Visitas
ecubamad
Mi vida cambió con el ADSL

Muchas Gracias por la respuesta.

Mi dudas por partes:

1. Segun lo que me explica habilitando FullCone  NAT es suficiente para que funcione correctamente y no fue asi. Debo habilitar FullCone  NAT y al mismo tiempo hacer PortForwarding para los puertos?

2.Me dices:

El modo de funcionamiento por defecto de la mayoría de Routers es usando NAT simétrico, es decir, que cada conexión que realice cada equipo de la red a cualquier destino, es mapeada en la tabla NAT, incluso si son difererentes conexiones al mismo sitio, asignando en cada mapeo un puerto diferente en el Router, y de aquí hacia fuera. Es el modo más seguro, dado que tan solo se aceptarán aquellas conexiones entrantes que hayan sido solicitadas con anterioridad y al puerto que fue mapeado originalmente por conexión.

En esta caso al conexion SIP la inicia el cliente (un  telefono IP) , por tanto el router por defecto debe aceptar la conexion entrante del servidor.

3. Diferencias entre PortForwarding  y VirtualServer.

 

Saludos

 

 

 

 

 

Mensaje 6 de 7
2.976 Visitas
Theliel
Yo probé el VDSL

Buenas @ecubamad

 

1. No tienes que habilitar FullCone NAT, no tienes que habilitar nada. Al hacer PortForwarding/Virtual Server ya estás usando FullCone. Esa opción lo que hace es cambiar el modo de funcionamiento integral de NAT del Router, pasar de NAT simétrico a FullCone, que te puedo asegurar no es lo que quieres ni necesitas, ni recomendable para nadie por aquí

 

2. SIP es un protocolo algo especial, al igual que la mayoría de protocolos VPN. El problema con estos protocolos es que digamos son... agnósticos a puertos por lo general, y en caso de SIP/VoIP el propio funcionamiento hace que la apertura de puertos tal cual no sea adecuada. Por qué?? Porque NAT da muchas virtudes, pero evita conexiones directas.

 

En el caso de SIP por ejemplo, tu quieres que cuando alguien llame de fuera la llamada pueda ser recibida en cualquier teléfono VoIP, no en uno ni en dos, en todos y por igual. Esto con apertura de puertos "tradicional" no podría funcionar en la vida... podrías redirigir en todo caso un puerto a un dispositivo... que sucede? Que para que SIP funcione correctamente, al igual que la mayoría de túneles VPN por parte al cliente, se requieren funciones especiales en el Router que hacen que esto sea posible.

 

Por lo general a estas técnicas se llaman Passtrought coloquialmente. La mayoría de los Routers las traen implementadas o permiten activarlas/desactivarlas. SIP es un ejemplo claro de esto, PPTP/IPSEc... otros. Por lo general por tanto, nunca es necesario abrir un puerto para SIP, en todo caso usar un SIP Passtrough en el Router. Tal es la cosa que en aquellos escenarios que tampoco exista posibilidad deun Passtrought en el Router, en caso de SIP se puede usar un servidor STUN para que precisamente se pueda establecer la conexión.

 

3. Ninguna, es lo mismo, son las muchas formas que tienen los fabricantes de nombrar lo mismo



Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 7 de 7
2.969 Visitas