Problema de conexión en un dispositivo especifíco
-
Tengo un enrutador que es quien recibe la conexión, y estando en modo BRIDGE.
En ese caso es la WAN de pfSense la que tiene la IP pública. Si 192.168.32.10 es un equipo con un servicio TCP en el puerto 1916 el NAT en WAN es lo único que hace falta.
Debe haber alguna que otra cosa…
¿Qué gateway tiene configurada el equipo?
Tiene que tener la LAN de pfSense como puerta de enlace.
Prueba también TCP/UDP en el NAT (y su regla). No sea que pienses que es TCP y sea UDP.
-
Pues gateway tiene configurado la 192.168.32.1, que efectivamente es la LAN del pfsense. Es más, en el log que pase en el post de inicio, se ve en el log que si que hace un "Request who-has 192.168.32.1". Y lamentablemente, si que es TCP como he estado poniendo, pero aún así hice la prueba con cada protocolo que sale en el menú de configuración del NAT (porque ya no se por donde cogerlo..).
-
También tengo la intuición ahora que no es solo este dispositivo lo que me está fallando, porque por ejemplo estoy intentando abrir un puerto para hacer VNC con un equipo de aquí desde casa utilizando el NAT, pero tras poner esta linea en el NAT con su regla de firewall, no me comunica, llega a conectar, pedirme el loggin, pero me sale "The connection closed unexpectedly", mientras que en local no tengo problemas. Estoy usando RealVNC. Aquí pongo la linea del NAT.
-
No, no es normal. Verifica que no tengas problemas con MTU. Arriba, en Hardware - Ajuste del MTU de las placas de red.
Ten en cuenta también que los servidores VNC pueden limitarse a la subred y también a determinadas IPs de origen. Manejo una instalación acotada de esta manera para que sólo pueda hacerse la conexión desde el ordenador del administrador red.
Saludos,
Josep Pujadas
-
Una pregunta, he estado mirando pero no me aclaro.. según veo el MTU es unidad máxima de transferencia, pero no he revisado nunca esto… ¿Como puedo investigar si es la causa? No entiendo cuando dices "Arriba, en Hardware - Ajuste del MTU de las placas de red".
-
No entiendo cuando dices "Arriba, en Hardware - Ajuste del MTU de las placas de red".
Pues que en lo alto del todo de esto foro tenemos varias secciones donde se recogen las cosas que parecen más importantes.
Y hay una sección Hardware, http://forum.pfsense.org/index.php/topic,23685.0.html
con apartado titulado Ajuste del MTU de las placas de red.
Si hay cortes, puede ser uno de los motivos…
-
Hola,
Noto que en la regla especificas el puerto fuente, quitalo y selecciona any, el puerto destino si debe ser el que tiene el servicio ej: 80, 1910, 3389.
Slds
Nicanor
-
Ya tengo identificado el problema alfin, el problema es que no se como solucionarlo, os cuento.
Resulta que el dispositivo este, cuando abre el socket a través del puerto por primera vez si que llega a establecer conexión, pero llega un momento que se reinicia y no ya no puede volver a establecer. Esto parece ser que se debe a que una vez abierto el puerto, si recibe un corte repentino, intenta abrir de nuevo el puerto, y normalmente funciona como ocurre en la otra conexión que tenemos, pero al pasar por el pfsense, parece ser que el puerto se queda en un estado de espera, y ya no permitir volver a abrir de nuevo, porque ya está abierto. Hemos probado a una cambiarle el puerto y/o la IP, y si que comunica de nuevo hasta que se reinicia.
Hemos reprogramado el hardware para hacer las pruebas, sin que se tenga que reiniciar. Así si que funciona, y si le cortamos la conexión, ya no puede reabrir el puerto. El problema es que es preciso que una vez se corte la conexión con el puerto, no deje el puerto abierto a la espera, sino que se cierre para que se pueda reabrir.
El problema es, que ya no creo que halla nada configurable para habilitar esto. ¿Os suena?
-
Informandome más, he visto que el estandar del protocolo TCP basado en linux indica que especificamente una vez cerrado el puerto incorrectamente, se queda en estado waiting, y al intentar reabrir el puerto marca port reused. Así que el dispositivo actualmente no es posible implementarle el creador de puertos aleatorios que es el standar actual para estos dispositivos para así evitar esta situación, porque la circuitería que usa es incompatible con esta randomización.
En definitiva, no es posible que el dispositivo conecte, así que vamos a redireccionar el dispositivo hacia la otra red que no usa este estandar, y ya estudiaremos la optimización del firmware.
Muchas gracias a todos por vuestro tiempo, especialmente a ti Josep por seguir activamente mi hilo. Así que podemos darlo por cerrado si quereis.
Saludos!! -
¡De nada, para eso estamos!
La 2.0 y 2.0.1 permiten el ajuste del comportamiento del kernel, aunque no sé si sería matar moscas a cañonazos. Te dejo el hilo:
System - Advanced - System tunables
http://forum.pfsense.org/index.php/topic,45097.msg235105.html#msg235105Saludos,
Josep Pujadas
