PROBLEMA Trafico entrante TCP



  • Buenas, ante todo me presento :)

    Les comento el problema que estoy teniendo:

    Desde hace un día, sin cambiar nada de la configuración no puedo acceder a ningun puerto TCP del pfsense mismo (192.168.0.7 | version: 2.0.1-RELEASE) desde Internet:

    No puedo acceder a Openvpn desde Internet (TCP 1194)
    No puedo acceder al Web GUI desde Internet (TCP 809x)
    No puedo acceder al SSH desde Internet (TCP 809X)

    Lo extraño es que desde la LAN accedo a todo sin problemas, como así también los clientes usan internet vía proxy, etc.
    Inclusive siguen funcionando los Port Fordwards que tengo declarados, en síntesis:

    No puedo acceder a puertos TCP del pfsense 192.168.0.7 desde internet.
    Si puedo acceder a puertos UDP del pfsense 192.168.0.7 desde internet.
    Si puedo traficar ICMP contra el pfsense 192.168.0.7 desde internet.

    Particularidades

    La conexión wan es pppoe
    Tengo declarado un IP Alias sobre la interfaz LAN 192.168.0.8

    Cualquier ayuda me vendría barbaro !!



  • Supongo que estarás empleando la ip pública que toma tu WAN, para acceder desde internet.

    Porque como sólo hablas de la privada en LAN…

    Por cierto, OpenVPN mejor que lo afines dejándolo en UDP. Va más rápido.



  • Openvpn lo saque por udp, pero no logro reparar lo descriptiva.
    Efectivamente intento ingresar por el ip publico q me da el uso.
    Me pareció q había dos reglas de outbound nat que ya no están, podra ser?



  • NAT Outbound no interviene, en principio. ¿Lo tienes en automático?

    Lo que sí debe haber son reglas en WAN que permitan la entrada de ese tráfico con destino WAN Address y puerto configurado.

    Extraño que desaparezcan cosas. Igual entraron en tu equipo. Ya se ha dicho innumerables veces que no es aconsejable publicar directamente la administración de pfSense en internet.

    Utilízese siempre una VPN o bien un servidor SSH interno (con el puerto camuflado) tunelizando puertos.



  • No se si el acceso fue indebido, es el firewall de una empresa que administro y otra gente tiene acceso, aunque no deberían configurar nada…
    Las reglas WAN siempre anduvieron, no cambió nada en ese aspecto, solo que dejaron de funcionar las que se basan en TCP y actúan sobre pfsense, es decir, las que corresponden a Port Forwarding.
    Inclusive tengo una regla con UDP y otra con ICMP que si funcionan =/



  • [Diagnostics] [Backup/Restore] [Config History]



  • Tengo solo lo que estuve haciendo ayer, esto fue hace unos días…



  • Postea tus WAN rules… sin datos sensibles...

    ¿No será que tu ip pública ha cambiado? ¿Estás seguro de cuál tienes?



  • La IP WAN es dinámica, la tengo configurada con Dynamic DNS, efectivamente cambia, pero yo uso la actual siempre.
    De hecho estoy ingresando por esa IP WAN a un servidor publicado detrás del pfsense desde donde puedo administrarlo via WebGuI.

    Las primer regla WAN que tengo reza lo siguiente:

    Allow TCP * * * 8091 * none

    No tengo reglas de bloqueo en WAN

    *** Agrego INFO ***
    Esto veo en la captura de paquetes al intentar ingresar al Web GUI configurado en el puerto 8091

    09:56:49.219137 IP 200.89.129.***.49986 > 181.21.***.22.8091: tcp 0
    09:56:49.469209 IP 200.89.129.***.52575 > 181.21.***.22.8091: tcp 0
    09:56:49.469419 IP 200.89.129.***.52560 > 181.21.***.22.8091: tcp 0
    09:56:49.480644 IP 200.89.129.***.52561 > 181.21.***.22.8091: tcp 0

    200.89.129.*** es la IP de mi oficina.
    181.21.***.22 es la IP pública WAN del pfsense.
    8091 es el WebGUI del pfsense



  • ¿Algo en [Status] [System Logs] [Firewall], relativo al problema?

    O mejor aún, usando (en consola)

    clog /var/log/filter.log | php /usr/local/bin/filterparser.php
    
    clog -f /var/log/filter.log | php /usr/local/bin/filterparser.php
    

    Sin -f lista todo lo que haya. Con -f lista todo lo que tenga y va mostrando lo nuevo.



  • No aparece nada en el log, es rarísimo esto, uso pfsense hace ya 4 años y nunca tuve un problema de este tipo.



  • Usa pftop, filtrando los estados… Si ves los paquetes con la captura en la interfase algunos estados tendrás que ver, aunque sean fallidos.

    pftop -> Permite ver los estados de PF
    http://www.eee.metu.edu.tr/~canacar/pftop/pftop.8.html
    Posibilidad de ordenación, filtrado…
    Ejemplo: ordenar por antigüedad los estados que tengan por origen 192.168.0.10
    pftop -o age -f "src 192.168.0.10"



  • Con pftop pasa lo mismo:
    Veo las conexiones fordwardeadas a las PCs de la red.
    Veo si hago un ping al equipo desde internet, aparece el ICMP.
    No pasa nada cuando intento con TCP, ningún registro.

    Me estoy volviendo loco.



  • ¿Cableado?

    Alguien me habló algún día de que tenía un cable entre el equipo de conexión a internet y su PC que no le dejaba pasar las comunicaciones TCP.

    Me pareció raro pero…

    ¿Estados de tus interfases, enmascarando datos sensibles?
    Igual es un problema de tarjeta de red o que no afina bien el driver/configuración. Ejemplo:

    em0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
            options=209b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic>ether aa:bb:cc:dd:ee:ff
            inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
            inet6 aaaa::bbbb:cccc:dddd:eeee%em0 prefixlen 64 scopeid 0x1
            nd6 options=3 <performnud,accept_rtadv>media: Ethernet autoselect (1000baseT <full-duplex>)
            status: active</full-duplex></performnud,accept_rtadv></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic></up,broadcast,running,simplex,multicast>
    

    A ver qué driver tienes y qué opciones tiene activas…



  • pciconf -lv

    ¿para tus tarjetas de red? Ejemplo:

    em0@pci0:1:0:0: class=0x020000 card=0x00008086 chip=0x109a8086 rev=0x00 hdr=0x00
        class      = network
        subclass   = ethernet
    

    ¿Detección en el arranque de tus tarjetas de red?. Ejemplo:

    dmesg | grep em0

    em0: <intel(r) 1000="" pro="" network="" connection="" 7.2.3=""> port 0xac00-0xac1f mem 0xfe7e0000-0xfe7fffff irq 16 at device 0.0 on pci1
    em0: Using an MSI interrupt
    em0: [FILTER]
    em0: link state changed to UP
    em0: promiscuous mode enabled
    em0: promiscuous mode disabled</intel(r)>
    


  • pciconf -lv

    hostb0@pci0:0:0:0:      class=0x060000 card=0xd6128086 chip=0x2e308086 rev=0x03                                                              hdr=0x00
        class      = bridge
        subclass  = HOST-PCI
    pcib1@pci0:0:1:0:      class=0x060400 card=0xd6128086 chip=0x2e318086 rev=0x03                                                              hdr=0x01
        class      = bridge
        subclass  = PCI-PCI
    vgapci0@pci0:0:2:0:    class=0x030000 card=0xd6128086 chip=0x2e328086 rev=0x03                                                              hdr=0x00
        class      = display
        subclass  = VGA
    vgapci1@pci0:0:2:1:    class=0x038000 card=0xd6128086 chip=0x2e338086 rev=0x03                                                              hdr=0x00
        class      = display
    none0@pci0:0:27:0:      class=0x040300 card=0xd6128086 chip=0x27d88086 rev=0x01                                                              hdr=0x00
        class      = multimedia
        subclass  = HDA
    pcib2@pci0:0:28:0:      class=0x060400 card=0xd6128086 chip=0x27d08086 rev=0x01                                                              hdr=0x01
        class      = bridge
        subclass  = PCI-PCI
    pcib3@pci0:0:28:1:      class=0x060400 card=0xd6128086 chip=0x27d28086 rev=0x01                                                              hdr=0x01
        class      = bridge
        subclass  = PCI-PCI
    uhci0@pci0:0:29:0:      class=0x0c0300 card=0xd6128086 chip=0x27c88086 rev=0x01                                                              hdr=0x00
        class      = serial bus
        subclass  = USB
    uhci1@pci0:0:29:1:      class=0x0c0300 card=0xd6128086 chip=0x27c98086 rev=0x01                                                              hdr=0x00
        class      = serial bus
        subclass  = USB
    uhci2@pci0:0:29:2:      class=0x0c0300 card=0xd6128086 chip=0x27ca8086 rev=0x01                                                              hdr=0x00
        class      = serial bus
        subclass  = USB
    uhci3@pci0:0:29:3:      class=0x0c0300 card=0xd6128086 chip=0x27cb8086 rev=0x01                                                              hdr=0x00
        class      = serial bus
        subclass  = USB
    ehci0@pci0:0:29:7:      class=0x0c0320 card=0xd6128086 chip=0x27cc8086 rev=0x01                                                              hdr=0x00
        class      = serial bus
        subclass  = USB
    pcib4@pci0:0:30:0:      class=0x060401 card=0xd6128086 chip=0x244e8086 rev=0xe1                                                              hdr=0x01
        class      = bridge
        subclass  = PCI-PCI
    isab0@pci0:0:31:0:      class=0x060100 card=0xd6128086 chip=0x27b88086 rev=0x01                                                              hdr=0x00
        class      = bridge
        subclass  = PCI-ISA
    atapci0@pci0:0:31:1:    class=0x01018a card=0xd6128086 chip=0x27df8086 rev=0x01                                                              hdr=0x00
        class      = mass storage
        subclass  = ATA
    atapci1@pci0:0:31:2:    class=0x01018f card=0xd6128086 chip=0x27c08086 rev=0x01                                                              hdr=0x00
        class      = mass storage
        subclass  = ATA
    none1@pci0:0:31:3:      class=0x0c0500 card=0xd6128086 chip=0x27da8086 rev=0x01                                                              hdr=0x00
        class      = serial bus
        subclass  = SMBus
    et0@pci0:2:0:0: class=0x020000 card=0xed0011c1 chip=0xed0011c1 rev=0x02 hdr=0x00
        class      = network
        subclass  = ethernet
    re0@pci0:3:0:0: class=0x020000 card=0xd6128086 chip=0x816810ec rev=0x03 hdr=0x00
        class      = network
        subclass  = ethernet
    skc0@pci0:4:0:0:        class=0x020000 card=0x4b011186 chip=0x4b011186 rev=0x11                                                              hdr=0x00
        class      = network
        subclass  = ethernet
    rl0@pci0:4:1:0: class=0x020000 card=0x813910ec chip=0x813910ec rev=0x10 hdr=0x00
        class      = network
        subclass  = ethernet



  • et0@pci0:2:0:0: class=0x020000 card=0xed0011c1 chip=0xed0011c1 rev=0x02 hdr=0x00
        class      = network
        subclass   = ethernet
    re0@pci0:3:0:0: class=0x020000 card=0xd6128086 chip=0x816810ec rev=0x03 hdr=0x00
        class      = network
        subclass   = ethernet
    skc0@pci0:4:0:0: class=0x020000 card=0x4b011186 chip=0x4b011186 rev=0x11 hdr=0x00
        class      = network
        subclass   = ethernet
    rl0@pci0:4:1:0: class=0x020000 card=0x813910ec chip=0x813910ec rev=0x10 hdr=0x00
        class      = network
        subclass   = ethernet
    

    et
    http://www.freebsd.org/cgi/man.cgi?query=et
    No hay bugs documentados.

    re
    http://www.freebsd.org/cgi/man.cgi?query=re
    Si la tarjeta usa un slot PCI de 64 bit hay un bug que no sé si puede ser el causante.

    sk, skc
    http://www.freebsd.org/cgi/man.cgi?query=sk
    No hay bugs documentados.

    rl
    http://www.freebsd.org/cgi/man.cgi?query=rl
    Un bug documentado.

    ¿Cuál es la tarjeta afectada? Dijiste que tienes varios equipos con el mismo problema. ¿Mismo hardware?



  • No tengo varios equipos con el mismo problema, tengo varios equipos, pero todos funcionan ok.
    En cuando al adaptador de red, es el et0, justo el que no tiene bugs =/

    Aclaro que funcionaba ok desde hace 3 años hasta hace una semana…



  • No tengo varios equipos con el mismo problema, tengo varios equipos, pero todos funcionan ok.

    Ok, entendí (o recordé) mal.

    Aclaro que funcionaba ok desde hace 3 años hasta hace una semana…

    Sí, esto ya lo recordaba que lo dijiste.

    En cuanto al adaptador de red, es el et0

    sysctl -a | grep hw.et

    A ver qué tienes ahí…



  • Me da error de sintaxis, si pongo sysctl -a me lista varias cosas, pero ninguna matchea con hw.et
    Noté que me dice Debug: Urgent en pfinfo y da unos errores de sintaxis de vez en cuando en el WebGUI, podrá tener que ver ?



  • Me da error de sintaxis, si pongo sysctl -a me lista varias cosas, pero ninguna matchea con hw.et

    Disculpa. Olvidé el -a

    Bueno, si no hay nada supongo que quiere decir que toma los valores por defecto.
    http://www.freebsd.org/cgi/man.cgi?query=et
    Supongamos, pues, que son correctos…

    Noté que me dice Debug: Urgent en pfinfo

    También a mi, en una instalación que funciona correctamente. Se refiere al modo en que está el debug, nada más.

    http://www.freebsd.org/cgi/man.cgi?query=pfctl

    pfctl -s info

    Da unos errores de sintaxis de vez en cuando en el WebGUI, podrá tener que ver ?

    Eso puede ser el navegador. ¿Cuál empleas y qué versión?

    ¿Qué hacer?

    Yo intentaría cambiar la tarjeta de red y revisar el cableado que cuelga de ella. Ya sé que dices que no tocaste nada pero igual falla la placa y/o el cable.



  • Mañana me voy para la oficina a ver que puedo hacer, hoy me reiniciaron el modem pero no surtió efecto…
    De paso aprovecho a actualizar el firmware.


Log in to reply