Problema de conexión en un dispositivo especifíco
-
Tu NAT Port Forward no es correcto. Adjunto imagen con lo que deber ser. Te falta que el NAT tenga como destino la IP de la WAN.
Por cierto, no quedó claro si es tu IP pública o tienes aún un enrutador detrás para conexión a Internet con LAN/WAN. Si es así también tendrás que hacer NAT en él.
Saludos,
Josep Pujadas
-
:) hola.
ok, bueno sigo consultando entonces:
-
cual es el objetivo de usar pfsense en tu red entonces?
-
si tiene sentido usar pfsense entre dos redes mejor usar openvpn entre dos pfsense y asi estableces una red privada con tus equipos de manera transparente sin tener que buscar configuraciones especiales.
-
estas usando captive portal? de ser asi activa el paso de la comunicacion con la ip especifica del equipo o con su mac de tal manera que no pase por la seguridad del captive portal
-
has usado la opcion bridge en el pfsense?
-
has habilitado el paso total entre la wan y la lan con las reglas de permitir todo en ambas direcciones?
-
puedes decirnos el modelo y marca del equipo? cumple con el estandar modbus tcp? es decir tiene el sello de aprobacion del estandar ? o es un modbus tcp cerrado?
-
-
Hola de nuevo.
Pues Josep, la verdad que ya he puesto la "WAN ADDRESS" dentro del NAT como DESTINATION, y he comprobado que halla afectado a la regla del firewall que se ha creado a raiz del NAT, esta todo correcto, pero sigue sin comunicar. Si que es verdad que tengo un enrutador que es quien recibe la conexión, y estando en modo BRIDGE como me aconsejaste en otro hilo, http://forum.pfsense.org/index.php/topic,44379.msg230202.html#msg230202, pasar la conexión al pfsense.
Sanchezluys, el objetivo de tener pfsense es que anteriormente tenia un IPCOP como proxy, pero se ha quedado obsoleto, y queriamos una alternativa gratuita y con ciertas funcionalidades, y vimos que pfsense era nuestro proxy perfecto. Necesitamos tener un proxy por el filtro por proxy de URL's, y poder hacer redirecciones de puertos sin limitaciones como pasaba en nuestro router.
En principio no es posible poner un pfsense en el otro lado porque es un servidor de un cliente, al cual no tenemos acceso, su función solo es suministrarnos el puerto al que conectarnos para establecer la conexión. Respecto a habilitar el paso de WAN a LAN, no se exactamente a que te refieres ni como hacerlo si es lo que supongo, lo que si que tengo es que dentro de la LAN no filtre nada, es decir, que esten todos los puertos abiertos mientras el mensaje venga de dentro de la LAN, ahora si, no se si está la posibilidad de decir que todo lo que venga de esa IP destino no sea filtrado, o direccionarlo directamente hacia el 192.168.32.10:1916, aparte de mediante el NAT. -
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
