El tcping, tracetcp o cualquiera de esas herramientas no se pueden usar desde la propia red interna, porque la prueba no atravesaría el router sospechoso, sino que el tráfico realizaría un loopback local sin salir realmente a Internet. En este caso, lo que significa ese "open" es que el equipo realmente tiene un servicio "escuchando" en ese puerto, o sea, hay un servicio (tu servidor del juego) que tiene tomado ese puerto y está a la espera de la llegada de una petición entrante de conexión para responderle y establecer esa conexión. Pero sirve como prueba, porque muchas veces la gente hace las pruebas sin ningún servicio en escucha en el puerto, por lo que, aunque estén correctamente redireccionados los puertos en el router, al no haber ningún servicio detrás del puerto en el equipo que responda a la petición, el puerto da la apariencia de que no está correctamente redireccionado, cuando en realidad el problema es que no hay nada en ese puerto que envíe una respuesta a la petición entrante, aunque la petición llegue correctamente al puerto del equipo. También es algo típico de los puertos con protocolo UDP, ya que en UDP no existe el concepto de "respuesta", por lo que resulta imposible para los escáneres online determinar si los puertos están correctamente redireccionados. El resultado final no es mucho más que usar el comando de Windows netstat -a con el que puedes ver los puertos que están en modo "Listening", o sea, a la espera de recibir peticiones de conexión entrantes.
Para hacer una prueba debes hacerla con una herramienta online, por ejemplo
GRC Internet Security Detection System
www.grc.com
(usar el segundo botón Proceed, luego poner el nro de puerto en el campo, y luego el botón largo "User specified custom port probe".
Para probar desde la red interna, pero utilizando un servicio de prueba online que haga la prueba desde Internet, sin depender de terceros, una de las mejores herramientas es el test de puertos del eMule, ya que la aplicación toma el puerto en la PC, lo pone en modo "escucha", y se comunica con su servidor remoto para que se realice una prueba desde Internet, todo en uno, y lo hace tanto para TCP como para UDP.
Otra posibilidad es que tu conexión esté detrás de un CG-NAT, cosa que si no puedes entrar a la configuración del router para ver qué IP recibe en su interface WAN desde el ISP, entonces debes usar el método de verificar si hay doble salto o salto único hasta tu IP Pública:
Todo sobre CGNat, la tecnología que usan varios operadores para conectarte a Internet y que te hará compartir IP con más personas.
www.adslzone.net
Sin embargo, el hecho de que haya estado funcionando correctamente cuando el router del ISP estaba en Modo Bridge, no deja muchas dudas de que el problema está en ese router, o en la DMZ que le han configurado, ya que posiblemente siga teniendo algún tipo de bloqueo o firewall separado de la configuración del NAT.
