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.8Cualquier 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 809109: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 0200.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 ?