hola,no es por ser pesado,pero he estado realizando algunas pruebas con el firewall del HGU y la xbox one
y es muy curioso porque me dicen que el firewall no afecta a la conexión de la consola y yo creo lo contrario,que afecta a que vaya peor los juegos online.
he reseteado de fabrica el HGU,a mi consola le he configurado todo manualmente,sin abrir ningun puerto en virtual server he realizado la prueba de nat y como es logico al no haber puertos abiertos da nat moderada,pero solo he tenido que ir al firewall del HGU y crear esta regla:
y mira por donde al crear la regla vuelvo a hacer la prueba de nat en xbox one y da nat abierta.
si con esta regla da nat abierta y sin la regla da nat moderada es porque estara afectando a la conexion.
todo esto sin abrir los puertos en virtual server.
por otro lado he estado mirando que es el port Triggering que hay en el ruoter,y segun parece es una caracteristica del router que tiene una firewall SPI o inspeccion de paquetes,quizas esto este afectando a la conexion y no vaya como deberia ir.
El tema del firewall te lo explicó perfectamente @Theliel en esta respuesta https://comunidad.movistar.es/t5/Soporte-T%C3%A9cnico-de-Fibra-%C3%93ptica/Xbox-live-y-Firewall-HGU/... no puedo aportar nada a esa explicación.
En cuanto al port triggering lo que hace es abrir los puertos que le configures cuando ve que se está utilizando un puerto determinado, ejemplo:
- Se configura el port triggering para que cuando haya actividad en el puerto 1500 abra los puertos 3200-5000 y 6243
Cuando el router ve que desde dentro de la LAN se establece una petición por el puerto 1500 (petición de salida) abre automáticamente los puertos 3200-5000 y 6243
Aunque seguro que tiene su campo de aplicación no se usa habitualmente -en los años que llevamos con los routers no he visto nunca a nadie que use el port triggering-, para las consolas con activar UPnP es suficiente, la propia consola abrirá los puertos que necesite y los cerrará cuando no los use, también se pueden abrir los puertos manualmente si no se quiere tener el UPnP activo.
¿Tienes algún problema con la consola? ¿Conectas por cable o por wifi?
Si necesitas soporte técnico en averías de Móvil, Fijo, Movistar+ o Internet Fijo (cobre o fibra), puedes acceder a nuestro apartado de Soporte Técnico o rellenar este formulario. También puedes contactar con nosotros llamando al 1002.
Si necesitas contratar Fibra Óptica, comprobar tu cobertura Adsl y Fibra, o ver información sobre la instalación de la fibra visita nuestra página ADSL y Fibra en movistar.es
Buenas @XxAlvRoxX
Sobre NAT abierta, NAT su padre y su madre...
No afecta en nada. El mensaje NAT abierta, NAT moderada... teniendo en cuenta la "etiqueta" que les ponen la consola, vale para poco.
Es algo muy sencillo. Para tener una NAT abierta realmente, la consola tendría que estar conectada directamente a Inet, y eso implicaría que la consola tendría que gestionar la conexión pppoe y no tendrías conexión en el resto de dispositivos. Así que si te da abierta o moderada o cualquier otra, ya ves la fiabilidad que tiene.
Como "calculan" esta NAT?? Pues lo suelen hacer con servidores STUN en el mejor de los casos, y de nuevo, fiabilidad nula. Créeme, siempre estás en NAT a menos que pongas el HGU en bridge y metas la conexión directamente en la consola.
Sobre las reglas de Firewall
Respecto a la regla creada, quiero que veas/entiendas lo absurdo de dicha regla, y el por qué carece totalmente de sentido.
Al seleccionar la interfaz ppp0.1, estás diciendo al Router que esa regla se va a aplicar al tráfico que entra por la interfaz ppp, Hasta aquí perfecto. En IP destino especificas 192.168.1.2, cierto?? Pero el tráfico que viene por ppp es el tráfico que viene de Internet, la IP 192.168.1.2 es una IP privada, ningun equipo de inet puede alcanzar un host privado, el Router jamás aplicará esa regla porque jamás existirá (en tu configuración) ningun paquete que venga por PPPoE y cuyo destino sea 192.168.1.2
En el mejor de los casos podrías especificar en IP de destino nada, o 0.0.0.0, lo que significaría que se aplicaría a cualquier destino. En ese punto la IP de destino es la IP pública del Router, con lo que no sólo no serviría de nada usar una IP local/privada como 192.168.1.2, sino que a menos que usases nada o 0.0.0.0 o la IP pública asignada en ese momento, tampoco serviría de nada. Bien, pues aun así que no especificases IP, ese filtro sólo se aplicaría al Router.
En IPv6 esto podría ser diferente porque un equipo externo sí podría alcanzar directamente un equipo "local" por IPv6 si este tuviese asignada una y sin estar nateado, pero no es tu caso, ni lo será a corto o medio plazo.
Sobre SPI
Actualmente todos (o al menos el 99%) de los Routers residenciales son SPI. Algunos tienen casillas para "habilitar" o "deshabilitar" este comportamiento, muchos otros sencillamente lo asumen, y sencillamente llaman de forma diferente ese "deshabilitar" o "habilitar".
Se llaman SPI porque el Router mantiene un seguimiento de las conexiones que se van realizando, denegando conexiones que no se han solicitado, denegando conexiones que se realizan de forma incorrecta... etc etc etc. Esto a día de hoy llevado a dispositivo residenciales no tiene mucho sentido llamarlos Firewall SPI, dado que el propio Router se comporta como un dispositivo NAT (generalmente NAT simétrico o restrictivo a puerto), y por ende como SPI. Es decir, es el comportamiento básico del 99% de este tipo de equipos:
Se bloquea absolutamente todo el tráfico entrante, permitiendo por defecto todo el tráfico saliente. Para lograr esto, el Router hace un seguimiento de todas las conexiones que se van haciendo (SPI). Así si llega un paquete que no había sido solicitado anteriormente, se filtra. Si un equipo remoto inicia conexiones extrañas no sujetas a las negociaciones TCP, se filtra. Se filtra todo lo que llega desde fuera a menos que se haya especificado por medio de otras tecnologías como upnp, dmz, port forward, trigger...
Como se puede deshabilitar el FW entonces?? Pues en nuestro caso es muy sencillo, sencillamente se cambia la regla por defecto de entrada, se cambia de DROP a ACCEPT. Así de simple. Por supuesto esto no es ni deseado ni útil, ni recomendado ni vale para lo que quieres.
Respecto a Port Triggering
Internet ha evolucionado mucho. A día de hoy NAT es imperativo debido a que es totalmente inviable (en IPv4) que cada dispositivo tenga una IP pública. Antes era infinitamente más habitual. Los servicios que se hospedaban, no se desarrollaban pensando en NAT. El ejemplo más famoso y directo es el protocolo FTP. La mayoría de servicios que podemos llegar a hospedar a día de hoy funcionan sencillamente permitiendo conexiones entrantes a un determinado puerto, y eso funciona perfectamente. Pero existen protocolos como FTP donde esto no funciona. FTP en su modo tradicional (Activo), escucha las conexiones en el puerto 21, pero una vez que se realiza una conexión entrante, el servidor "negocia" el puerto por el que va a enviar realmente los datos al cliente. Como el cliente bloquea por defecto el tráfico entrante debido al comportamiento normal NAT, el Router filtra todo el tráfico que llega por el nuevo puerto que "negoció", y la conexión es imposible. Esta imagen lo ilustra bien:
El cliente inicia la conexión en su puerto1026, el servidor le responde al mismo puerto así que el Firewall lo permite. Pero en el punto 3 el servidor envía al puerto 1027 datos, puerto que especificó el servidor en el punto 2. Pero para el Router esa conexión se bloquea, no existe ninguna entrada en NAT que diga que un equipo de la red local está esperando conexiones en ese puerto.
El puerto que se negocia en el cliente es aleatorio, generalmente dentro de un rango, pero no se conoce por regla general de antemano, con lo que hacer PortForwarding sería una barbaridad. Esto se soluciona con PortTriggering. Con Port Triggering se puede decir al Router que si detecta una conexión entrante al puerto (por ejemplo) 21, se abran al mismo equipo que se abre el 21 un rango de puertos externos adicionales.
A día de hoy no obstante, y como dice @JulioC-Movistar no se usa. FTP sigue siendo extremadamente usado, pero lo que se hace es usar el modo Pasivo en FTP, que se comporta de otro modo. Y la mayoría de protocolos que podrían ser problemáticos están en deshuso en la mayoría de los casos.
Así que, pese a que seguimos teniendo la opción y que en determinados casos concretos podría ser útil, muy muy muy rara vez vas a ver que alguien lo necesita o usa.
¿Si abres los puertos o activas el UPnP no obtienes el mismo resultado?
Si necesitas soporte técnico en averías de Móvil, Fijo, Movistar+ o Internet Fijo (cobre o fibra), puedes acceder a nuestro apartado de Soporte Técnico o rellenar este formulario. También puedes contactar con nosotros llamando al 1002.
Si necesitas contratar Fibra Óptica, comprobar tu cobertura Adsl y Fibra, o ver información sobre la instalación de la fibra visita nuestra página ADSL y Fibra en movistar.es
@Theliel@ ha escrito:Buenas @XxAlvRoxX
Sobre NAT abierta, NAT su padre y su madre...
No afecta en nada. El mensaje NAT abierta, NAT moderada... teniendo en cuenta la "etiqueta" que les ponen la consola, vale para poco.
Es algo muy sencillo. Para tener una NAT abierta realmente, la consola tendría que estar conectada directamente a Inet, y eso implicaría que la consola tendría que gestionar la conexión pppoe y no tendrías conexión en el resto de dispositivos. Así que si te da abierta o moderada o cualquier otra, ya ves la fiabilidad que tiene.
Como "calculan" esta NAT?? Pues lo suelen hacer con servidores STUN en el mejor de los casos, y de nuevo, fiabilidad nula. Créeme, siempre estás en NAT a menos que pongas el HGU en bridge y metas la conexión directamente en la consola.
Sobre las reglas de Firewall
Respecto a la regla creada, quiero que veas/entiendas lo absurdo de dicha regla, y el por qué carece totalmente de sentido.
Al seleccionar la interfaz ppp0.1, estás diciendo al Router que esa regla se va a aplicar al tráfico que entra por la interfaz ppp, Hasta aquí perfecto. En IP destino especificas 192.168.1.2, cierto?? Pero el tráfico que viene por ppp es el tráfico que viene de Internet, la IP 192.168.1.2 es una IP privada, ningun equipo de inet puede alcanzar un host privado, el Router jamás aplicará esa regla porque jamás existirá (en tu configuración) ningun paquete que venga por PPPoE y cuyo destino sea 192.168.1.2
En el mejor de los casos podrías especificar en IP de destino nada, o 0.0.0.0, lo que significaría que se aplicaría a cualquier destino. En ese punto la IP de destino es la IP pública del Router, con lo que no sólo no serviría de nada usar una IP local/privada como 192.168.1.2, sino que a menos que usases nada o 0.0.0.0 o la IP pública asignada en ese momento, tampoco serviría de nada. Bien, pues aun así que no especificases IP, ese filtro sólo se aplicaría al Router.
En IPv6 esto podría ser diferente porque un equipo externo sí podría alcanzar directamente un equipo "local" por IPv6 si este tuviese asignada una y sin estar nateado, pero no es tu caso, ni lo será a corto o medio plazo.
Sobre SPI
Actualmente todos (o al menos el 99%) de los Routers residenciales son SPI. Algunos tienen casillas para "habilitar" o "deshabilitar" este comportamiento, muchos otros sencillamente lo asumen, y sencillamente llaman de forma diferente ese "deshabilitar" o "habilitar".
Se llaman SPI porque el Router mantiene un seguimiento de las conexiones que se van realizando, denegando conexiones que no se han solicitado, denegando conexiones que se realizan de forma incorrecta... etc etc etc. Esto a día de hoy llevado a dispositivo residenciales no tiene mucho sentido llamarlos Firewall SPI, dado que el propio Router se comporta como un dispositivo NAT (generalmente NAT simétrico o restrictivo a puerto), y por ende como SPI. Es decir, es el comportamiento básico del 99% de este tipo de equipos:
Se bloquea absolutamente todo el tráfico entrante, permitiendo por defecto todo el tráfico saliente. Para lograr esto, el Router hace un seguimiento de todas las conexiones que se van haciendo (SPI). Así si llega un paquete que no había sido solicitado anteriormente, se filtra. Si un equipo remoto inicia conexiones extrañas no sujetas a las negociaciones TCP, se filtra. Se filtra todo lo que llega desde fuera a menos que se haya especificado por medio de otras tecnologías como upnp, dmz, port forward, trigger...
Como se puede deshabilitar el FW entonces?? Pues en nuestro caso es muy sencillo, sencillamente se cambia la regla por defecto de entrada, se cambia de DROP a ACCEPT. Así de simple. Por supuesto esto no es ni deseado ni útil, ni recomendado ni vale para lo que quieres.
Respecto a Port Triggering
Internet ha evolucionado mucho. A día de hoy NAT es imperativo debido a que es totalmente inviable (en IPv4) que cada dispositivo tenga una IP pública. Antes era infinitamente más habitual. Los servicios que se hospedaban, no se desarrollaban pensando en NAT. El ejemplo más famoso y directo es el protocolo FTP. La mayoría de servicios que podemos llegar a hospedar a día de hoy funcionan sencillamente permitiendo conexiones entrantes a un determinado puerto, y eso funciona perfectamente. Pero existen protocolos como FTP donde esto no funciona. FTP en su modo tradicional (Activo), escucha las conexiones en el puerto 21, pero una vez que se realiza una conexión entrante, el servidor "negocia" el puerto por el que va a enviar realmente los datos al cliente. Como el cliente bloquea por defecto el tráfico entrante debido al comportamiento normal NAT, el Router filtra todo el tráfico que llega por el nuevo puerto que "negoció", y la conexión es imposible. Esta imagen lo ilustra bien:
El cliente inicia la conexión en su puerto1026, el servidor le responde al mismo puerto así que el Firewall lo permite. Pero en el punto 3 el servidor envía al puerto 1027 datos, puerto que especificó el servidor en el punto 2. Pero para el Router esa conexión se bloquea, no existe ninguna entrada en NAT que diga que un equipo de la red local está esperando conexiones en ese puerto.
El puerto que se negocia en el cliente es aleatorio, generalmente dentro de un rango, pero no se conoce por regla general de antemano, con lo que hacer PortForwarding sería una barbaridad. Esto se soluciona con PortTriggering. Con Port Triggering se puede decir al Router que si detecta una conexión entrante al puerto (por ejemplo) 21, se abran al mismo equipo que se abre el 21 un rango de puertos externos adicionales.
A día de hoy no obstante, y como dice @JulioC-Movistar no se usa. FTP sigue siendo extremadamente usado, pero lo que se hace es usar el modo Pasivo en FTP, que se comporta de otro modo. Y la mayoría de protocolos que podrían ser problemáticos están en deshuso en la mayoría de los casos.
Así que, pese a que seguimos teniendo la opción y que en determinados casos concretos podría ser útil, muy muy muy rara vez vas a ver que alguien lo necesita o usa.
si se nota que entiendes una burrada y yo soy un cateto,yo solo puedo aportar mi experiencia en el juego
te hablare de un juego el gears of war 2,este juego lo que tiene de especial es que va por HOST,es decir
el juego busca a 10 personas para jugar online y entre esas 10 el juego elige al que mejor conexion tiene para que sea el anfitrion de la partida y es es a traves de esa persona que funciona la partida,si el se va la partida se cae.
pues bien,cuando tenia 100/10 con el comtrend y el primer firmware del router antes de que metieran mas firmwares ,yo a traves de una edicion del backup de la configuracion del router, editaba la configuracion y donde decia "firmware TRUE" ponia "FALSE" pues lo hacia asi porque era la unica manera de hacerlo,ya que no se podia editar y ni salia la opcion del firmware al crear una nueva interfaz pppoe
pues con solo hacer eso y abrir los puertos en este juego te daba como apto para ser anfitrion de las partidas,luego cuando empezaron a sacar nuevos firmwares para el comtrend empezaron los problemas,pusieron en la interfaz pppoe una casilla para desactivar el firewall ,y aun desactivandola ya no era apto para ser anfitrion de las partidas y no te daba el host,con el hgu pasa lo mismo aunque tu pongas de drop a permit,que ya lo he intentado todo
eliminando todas las reglas,desactivando el firmware y todo lo demas y nunca te da el host
pero sabes cuando te da el host,cuando creas esa regla te lo da una vez y luego ya no funciona mas,como si ya se bloqueara,entonces desactivo la regla y la vuelvo a activar y el juego te da otra vez como apto para el host
entonces yo creo que algo pasa no? tu que entiendes tanto de esto,sabrias porque pasa esto
porque te digo en el comtrend quitando el firewall de aquella manera te daba el host 10 o 20 partidas seguidas y desde que empezaron a meter firmwares y a poner el firewall para desactivarlo a traves de una casilla ya no funciona
,o no se desactiva o de alguna manera hay algo ahi que esta restringiendo paquetes que se envian al router
no lo se,pero algo se que pasa que no esta bien
pues yo lo que creo,donde esta el problema es en lo siguiente:
cuando yo al comtrend le hacia un backup de la configuracion,abria ese backup con el wordpad y editaba la linea del comando "firewall true" y ponia "firewall false" metia este backup al comtrend y luego una vez cargado ese hacia otro backup a ver si se habia editado esa linea y lo abria de nuevo y me aparecia esa linea como yo lo habia puesto
pero luego de poner los nuevos firmwares y en el hgu tambien pasa que editas el backup donde pone la linea de firewall true la pones en false lo cargas y vuelves a crear un backup y ya no aparece esa linea del codigo como que el firewall esta en false,simplemente desaparece la linea de codigo de esa regla,es decir activas la casilla del firewall y te aparece el codigo de firewall true ,desactivas la casilla en el router del firewall y por arte de magia desaparece el codigo donde deberia estar firewall false
en fin solo puedo dar mi experiencia que os aseguro es mucha en xbox live.
pues mira he hecho lo que tu me has dicho,he reiniciado el router de fabrica,y la opcion del firewall de la wan la he puesto en permit,he abierto los puertos normalmente y al hacer la prueba de conexion de nat en la consola me sale este error:
luego vuelvo a poner la wan en el firewall en drop y ya no sale este mensaje,algun problema debe tener el router para obtener ip teredo en la xbox con una configuracion manual tanto en la xbox como abriendo los puertos manualmente,el upnp obtiene una direccion teredo pero solo abre el puerto 3074 udp y al menos a mi nunca me a ido bien el online en la xbox con el upnp
edito: tambien he comprobado que con el router de fabrica y la wan en drop tambien arroja este error,yo creo que al final va a ser que este router tiene problemas para proporcionar una direccion teredo a la consola,si abres los puertos manualmente con el upnp no pasa,pero claro con el upnp no va bien lo digo por experiencia
Gracias a ti, lo damos por aclarado. 
Si necesitas soporte técnico en averías de Móvil, Fijo, Movistar+ o Internet Fijo (cobre o fibra), puedes acceder a nuestro apartado de Soporte Técnico o rellenar este formulario. También puedes contactar con nosotros llamando al 1002.
Si necesitas contratar Fibra Óptica, comprobar tu cobertura Adsl y Fibra, o ver información sobre la instalación de la fibra visita nuestra página ADSL y Fibra en movistar.es
