Problema de conexión en un dispositivo especifíco
-
Hola, buenos dias a todos!
Quería hacer una consulta bastante rara que llevo desde el Lunes pasado con este problema. Resulta que en nuestra empresa fabricamos dispositivos a medida, encarado a comunicaciones. Tenemos un dispositivo que convierte tramas CAN para transmitir a través de LAN. Este dispositivo tiene una IP y una MAC. Nuestro problema viene porque no nos funciona a través del proxy.
Usando la aplicación Hercules, para comprobar la conectividad con puertos remotos, en esta red no tenemos ningún problema para comunicar, por lo que el pfsense las deja pasar. Haciendo más pruebas, con el packet capture del pfsense, vemos que si que se inicia la transmisión de datos, pero que no obtiene respuesta, y está configurado para que tras 5 segundos lo intenta de nuevo, sino se reinicia. Aquí os dejo un log del packet capture.
10:06:56.279192 00:50:c2:c2:ef:ee > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.32.1 tell 192.168.32.10, length 46 10:06:56.279200 00:40:63:f2:af:f5 > 00:50:c2:c2:ef:ee, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 192.168.32.1 is-at 00:40:63:f2:af:f5, length 46 10:06:56.279355 00:50:c2:c2:ef:ee > 00:40:63:f2:af:f5, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto TCP (6), length 44) 192.168.32.10.1916 > XXX.XXX.XXX.XXX.XXXXX: Flags [s], cksum 0x83b1 (correct), seq 0, win 7680, options [mss 1456], length 0 10:07:01.786977 00:50:c2:c2:ef:ee > 00:40:63:f2:af:f5, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 64, id 2, offset 0, flags [none], proto TCP (6), length 44) 192.168.32.10.1916 > XXX.XXX.XXX.XXX.XXXXX: Flags [s], cksum 0x83b1 (correct), seq 0, win 7680, options [mss 1456], length 0 10:07:14.399995 00:50:c2:c2:ef:ee > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.32.1 tell 192.168.32.10, length 46 10:07:14.400006 00:40:63:f2:af:f5 > 00:50:c2:c2:ef:ee, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 192.168.32.1 is-at 00:40:63:f2:af:f5, length 46 10:07:14.400160 00:50:c2:c2:ef:ee > 00:40:63:f2:af:f5, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto TCP (6), length 44) 192.168.32.10.1916 > XXX.XXX.XXX.XXX.XXXXX: Flags [s], cksum 0x83b1 (correct), seq 0, win 7680, options [mss 1456], length 0 10:07:19.907771 00:50:c2:c2:ef:ee > 00:40:63:f2:af:f5, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 64, id 2, offset 0, flags [none], proto TCP (6), length 44) 192.168.32.10.1916 > XXX.XXX.XXX.XXX.XXXXX: Flags [s], cksum 0x83b1 (correct), seq 0, win 7680, options [mss 1456], length 0 Estudiando más opciones, hemos descubierto que efectivamente, el mensaje sale del dispositivo, llega al pfsense, este lo envia al destino, y la respuesta del destino lleva al pfsense, pero este ya no lo deja pasar. Tenemos el pfsense con Squid, y Squidguard, pero hemos probado a poner la IP en lista blanca, e incluso a desinstalar el proxy server, pero continua sin dejarlo pasar. ¿Sabeís por donde puedo continuar a hacer pruebas? Esque se me agotaron las ideas. El dispositivo funciona, porque tenemos otra red que quiero preparar un fail-over, y por esa si que funciona, pero es necesario que valla por el pfsense. Gracias.[/s][/s][/s][/s]
-
Por favor, ¿de qué topología estamos hablando? ¿Dónde está el dispositivo? ¿Con qué IP? ¿Desde dónde (subred) hay que verlo?
Si no se especifica bien la topología no hay manera de poder analizar los temas…
Lo único que sé ver es un equipo que parece emitir paquetes desde la IP 192.168.32.10 y puerto 1916.
Saludos,
Josep Pujadas
-
Hola Josep.
Pues es una topología en estrella con el pfsense como nodo central, que distribuye la conexión, es el servidor DHCP, etc. El dispositivo está dentro de la red de la empresa (rango 192.168.32.XXX). Es la IP del log, 192.168.32.10, saliendo del puerto 1916, nuestro pfsense está en la 192.168.32.1. El equipo de destino está en otra red, a la cual se accede a través de su IP pública con la redirección de puertos a un puerto concreto, que es el que usa el dispositivo para entablar conexión. Como he comentado, el destino está accesible, porque desde nuestra red abrimos una conexión con el Hercules y vemos que todo está correcto.
Gracias de nuevo.
-
Bueno, esto no tiene nada que ver con squid.
Si lo que quereis es ver a 192.168.32.10:1916 desde Internet teneis que publicar discho servicio haciendo NAT port forward en WAN, como cualquier otro servicio que se quiera publicar.
http://www.bellera.cat/josep/pfsense/nat_cs.html#forward
Saludos,
Josep Pujadas
-
:) hola dismuntel.
muy interesante lo que comentas en tu topologia, tengo algunas consultas.
-
las redes CAN que conozco son de equipos de automatización así como de equipos de control de motores o manejo de media y alta tensión en cuanto a suicheo, ahora este equipo es para estas aplicaciones?, de ser asi entonces usa protocolo modbus tcp, lo cual es necesario revisar para que tanto el squid y el pfsense permita las tramas
-
de que año es el equipo? soporta la configuracion del ruteo, dns etc?
-
-
Gracias por las respuestas. Respecto a crear el NAT, ya está creada la regla, con la opción Filter rule association en "Create new associated filter rules", creandose una regla en RULES del firewall, pero no llega a comunicar. Lo tengo de la siguiente forma (no hace falta especificar receptor, así evito la máxima cantidad de fallos posibles, porque tampoco se puede modificar nada del dispositivo por lo que no es necesario restringir el acceso):
Efectivamente, usa protocolo modbus tcp, por eso no se si necesita un tipo de configuración específica. El equipo es bastante reciente, inferior a un año, y respecto a aceptar la configuración y demás, si que lo coje, y es capaz de funcionar, porque tenemos una linea de internet secundaria de momento en la IP 192.168.32.216 la cual, al ser programado el dispositivo con esta como puerta de enlace, si que conecta, cuya diferencia entre una red y otra es el paso por el pfsense.
Saludos.
-
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