Bloqueo de conexiones por reglas de Firewall

bgsistemas

Muchas gracias por tus comentarios. Realize los cambios que comentas, sin embargo, persiste el bloqueo de la conexion. Pero tambien persiste el hecho que no existe ningun registro en los logs, aun especificando esta opcion en las nuevas reglas.

Lo que me llama la atención es que la unica forma de tener un registro de estos bloqueos es cuando habilitamos la opcion "Log packets blocked by the default rule" en Status: System logs: Settings.

periko

Haz una regla en ambos lados, que permita todo y que logie todo, pruebas y vez que esta haciendo!!!

bgsistemas

Pasa lo mismo el trafico se bloquea.

En este momento solo estoy probando con la la LAN(Datosy Servers) y una VLAN(Wireless_Internos) con las siguientes reglas

Con estas reglas los logs que que se registran no muestran un bloqueo

Pero cuando habilito la opcion "Log packets blocked by the default rule" se registra estos eventos que corresponden al bloqueo

Los datos de las redes y de las ips con las que estamos probando son:

LAN DatosyServers 192.168.15.0/24,
Servidor de archivos : 192.168.15.1

VLAN:Wireless_Internos 192.168.16.0/24
Equipo : 192.168.16.48

bgsistemas

Revisando los registros de los logs desde el shell lo que observo es lo siguiente, que corresponden a los bloqueos y que se registran cuando esta habilitada la opcion " Log packets blocked by the default rule"

pudieran ser estos mensajes "[bad hdr length 0 - too short, < 20]" son los que provocan el bloqueo??

login as: admin
Using keyboard-interactive authentication.
Password:
*** Welcome to pfSense 2.0.3-RELEASE-pfSense (i386) on routerpv ***

WAN (wan) -> em1 -> 192.168.40.5
DATOSYSERVERS (lan) -> em0 -> 192.168.15.10
WIRELESS_INTERNOS (opt1) -> sk0_vlan16 -> 192.168.16.10
WIRELESS_INVITADOS (opt2) -> sk0_vlan21 -> 192.168.21.10
OFFICE_INTERNET (opt3) -> sk0_vlan20 -> 192.168.20.10
WIRELESS_MOVILES (opt4) -> sk0_vlan17 -> 192.168.17.10

Logout (SSH only) 8) Shell
Assign Interfaces 9) pfTop
Set interface(s) IP address 10) Filter Logs
Reset webConfigurator password 11) Restart webConfigurator
Reset to factory defaults 12) pfSense Developer Shell
Reboot system 13) Upgrade from console
Halt system 14) Disable Secure Shell (sshd)
Ping host

Enter an option: 10

tcpdump: WARNING: pflog0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 96 bytes
00:00:00.000000 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.2857 > 192.168.15.1.445: [|tcp]
00:00:00.203480 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.2857 > 192.168.15.1.445: tcp 114 [bad hdr length 0 - too short, < 20]
00:00:00.603553 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.2857 > 192.168.15.1.445: [|tcp]
00:00:01.207120 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.2857 > 192.168.15.1.445: [|tcp]
00:00:01.207011 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.2857 > 192.168.15.1.445: [|tcp]
00:00:01.206109 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.2857 > 192.168.15.1.445: [|tcp]
00:00:02.414627 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.2857 > 192.168.15.1.445: [|tcp]
00:00:04.828546 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.2857 > 192.168.15.1.445: [|tcp]
00:00:07.923052 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.2857 > 192.168.15.1.445: [|tcp]
00:00:01.633976 rule 38/0(match): pass in on sk0_vlan16: 192.168.16.48.2859 > 192.168.15.1.445: [|tcp]
00:00:00.000063 rule 38/0(match): pass in on sk0_vlan16: 192.168.16.48.2860 > 192.168.15.1.139: [|tcp]
00:00:00.024895 rule 38/0(match): pass in on sk0_vlan16: 192.168.16.48.2861 > 192.168.15.1.80: tcp 28 [bad hdr length 0 - too short, < 20]
00:00:01.582696 rule 38/0(match): pass in on sk0_vlan16: 192.168.16.86.5353 > 224.0.0.251.5353: [|domain]
00:00:07.023755 rule 37/8(ip-option): pass in on em0: 192.168.15.254 > 224.0.0.1: igmp query v2
00:00:00.049867 rule 40/8(ip-option): pass in on sk0_vlan20: 192.168.20.5 > 224.0.0.1: igmp query v2
00:00:00.000171 rule 38/0(match): pass in on sk0_vlan16: 192.168.16.5 > 224.0.0.1: igmp query v2
00:00:00.000006 rule 38/8(ip-option): pass in on sk0_vlan16: 192.168.16.5 > 224.0.0.1: igmp query v2
00:00:00.618843 rule 40/8(ip-option): pass in on sk0_vlan20: 192.168.20.5 > 224.0.0.2: igmp v2 report 224.0.0.2
00:00:01.260035 rule 38/0(match): pass in on sk0_vlan16: 192.168.16.5 > 224.0.0.22: igmp v2 report 224.0.0.22
00:00:00.000014 rule 38/8(ip-option): pass in on sk0_vlan16: 192.168.16.5 > 224.0.0.22: igmp v2 report 224.0.0.22
00:00:00.190516 rule 40/8(ip-option): pass in on sk0_vlan20: 192.168.20.5 > 224.0.0.22: igmp v2 report 224.0.0.22

periko

Oyes, a ver si sigues en pruebas, deshabilita el firewall y observa que pasa?

system->advanced->Firewall NAT->Disable Firewall.

La option:

Log packets blocked by the default rule

Dejala habilitada.

Saludos.

bgsistemas

Deshabilitando el Firewall, si es posible la conexión y el paso de datos. En los registros del firewall no se registra ningun evento. Con ese cambio lo que no tengo en el equipo es salida a Internet, pero la comunicacion por SMB si es posible.

bgsistemas

Realize una captura de paquetes en la interfaz donde esta el equipo en pruebas, con IP 192.168.16.48.

Solo es necesario cambiar la extensión del archivo txt a cap para poder abrir el archivo y analizar la captura.

packetcapture.txt

periko

Oyes, verifica esta opcion en la parte avanzada:

Bypass firewall rules for traffic on the same interface.

Quitala ponla…?

bgsistemas

Al deshabilitar la opción que comentas persiste el bloqueo, estos son los registros que se generan

tcpdump: WARNING: pflog0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 96 bytes
00:00:00.000000 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.4139 > 192.168.15.1.445: tcp 254 [bad hdr length 0 - too short, < 20]
00:00:00.230142 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.4139 > 192.168.15.1.445: tcp 254 [bad hdr length 0 - too short, < 20]
00:00:00.546918 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.4139 > 192.168.15.1.445: tcp 254 [bad hdr length 0 - too short, < 20]
00:00:01.328000 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.4139 > 192.168.15.1.445: tcp 254 [bad hdr length 0 - too short, < 20]
00:00:01.187806 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.4139 > 192.168.15.1.445: tcp 254 [bad hdr length 0 - too short, < 20]
00:00:01.202789 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.4139 > 192.168.15.1.445: tcp 254 [bad hdr length 0 - too short, < 20]
00:00:02.406252 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.4139 > 192.168.15.1.445: tcp 254 [bad hdr length 0 - too short, < 20]
00:00:04.812515 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.4139 > 192.168.15.1.445: tcp 254 [bad hdr length 0 - too short, < 20]
00:00:02.359110 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.4139 > 192.168.15.1.445: tcp 73 [bad hdr length 0 - too short, < 20]

Al dejar habilitada la opción, como estaba de manera predeterminada, el bloqueo se mantiene y se generan los siguientes logs

tcpdump: WARNING: pflog0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 96 bytes
00:00:00.000000 rule 37/8(ip-option): pass in on em0: 192.168.15.254 > 224.0.0.1: igmp query v2
00:00:00.049853 rule 41/8(ip-option): pass in on sk0_vlan20: 192.168.20.5 > 224.0.0.1: igmp query v2
00:00:00.000773 rule 39/8(ip-option): pass in on sk0_vlan16: 192.168.16.5 > 224.0.0.1: igmp query v2
00:00:00.619286 rule 39/8(ip-option): pass in on sk0_vlan16: 192.168.16.5 > 224.0.0.22: igmp v2 report 224.0.0.22
00:00:06.443711 rule 41/8(ip-option): pass in on sk0_vlan20: 192.168.20.5 > 224.0.0.22: igmp v2 report 224.0.0.22
00:00:00.933689 rule 42/8(ip-option): pass in on sk0_vlan17: 192.168.17.5 > 224.0.0.1: igmp query v2
00:00:01.827844 rule 41/8(ip-option): pass in on sk0_vlan20: 192.168.20.5 > 224.0.0.2: igmp v2 report 224.0.0.2
00:00:01.113045 rule 42/8(ip-option): pass in on sk0_vlan17: 192.168.17.5 > 224.0.0.2: igmp v2 report 224.0.0.2
00:00:02.271259 rule 42/8(ip-option): pass in on sk0_vlan17: 192.168.17.5 > 224.0.0.22: igmp v2 report 224.0.0.22
00:00:08.237831 rule 39/8(ip-option): pass in on sk0_vlan16: 192.168.16.5 > 224.0.0.1: igmp query v2
00:00:02.854870 rule 39/8(ip-option): pass in on sk0_vlan16: 192.168.16.5 > 224.0.0.2: igmp v2 report 224.0.0.2
00:00:02.219112 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.4162 > 192.168.15.1.445: [|tcp]
00:00:17.395214 rule 40/8(ip-option): pass in on sk0_vlan21: 192.168.21.5 > 224.0.0.1: igmp query v2
00:00:03.781954 rule 40/8(ip-option): pass in on sk0_vlan21: 192.168.21.5 > 224.0.0.22: igmp v2 report 224.0.0.22
00:00:03.562673 rule 40/8(ip-option): pass in on sk0_vlan21: 192.168.21.5 > 224.0.0.2: igmp v2 report 224.0.0.2
00:00:18.919212 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.4164 > 192.168.15.1.445: [|tcp]

En ambos casos reinicie el Pfsense antes de hacer las pruebas de conexión.

periko

Men yo me hiria a el foro gabacho, no tengo un laboratorio para ver el problema real.

bgsistemas

Hola, Muchas gracias por todos los comentarios.
Finalmente encontré el problema, decidí aislar todos los componentes e ir verificando su funcionamiento y todo funciona de manera correcta hasta que inicie con pruebas con algunos servidores y el problema resulta por le trafico que maneja los servers al tener diversos gateways, al trabajar con un solo gateway funciona correctamente y al tener los dos es necesario especificar el orden de las rutas para el trafico y que no cause problemas.

Nuevamente gracias por todos sus comentarios