Bloqueo de conexiones por reglas de Firewall

bgsistemas · Aug 14, 2013, 11:32 PM

Hola a todos,

Estamos analizando la opción de pfsense para una implementación, sin embargo, estamos detenidos con una situacion que no podemos explicar.

A continuación les proporciono información del ambiente donde tenemos este problema.

Como existe una red en producción, de manera paralela se estan haciendo pruebas con la instalación de Pfsense y diversos equipos.
En el Pfsense se estan utilizando 3 tarjetas de red, con una de ellas con 4 VLAN´s, distribuidas de la siguiente manera

WAN (em1)
LAN (em0)
3-1) VLAN_16 (sk0)
3-2) VLAN_17 (sk0)
3-3) VLAN_20 (sk0)
3-4) VLAN_21 (sk0)

Al inicio de la configuración validamos la comunicación de todas las redes verificando su salida a Internet y funciona de manera correcta, pero al momento de utilizar conexiones por SMB en los logs aparecen registros de bloqueo de esas conexiones, sin embargo, en las reglas que agregamos, no aparece bloqueado.

De manera normal no aparecen registros en los logs, solo cuando habilito la opción "Log packets blocked by the default rule" aparecen los registros de las IP con las que estamos haciendo pruebas y coinciden cuando estamos tratando de hacer una copia de datos por SMB de una PC a otra.

De lo que podemos estar seguros es que el bloqueo es por reglas del firewall, ya que cuando habilitamos la opción "Disable all packet filtering" si podemos hacer la copia de material, aunque no podemos navegar en Internet.

Los logs que observamos en la consola del pfsense son como estos

00:00:00.000000 rule 1/0(match): block in on sk0_vlan20: 192.168.20.52.35393 > 192.168.15.18.445: [|tcp]
00:00:00.299164 rule 1/0(match): block in on sk0_vlan20: 192.168.20.52.35393 > 192.168.15.18.445: [|tcp]
00:00:00.250549 rule 1/0(match): block in on sk0_vlan20: 192.168.20.52.35393 > 192.168.15.18.445: tcp 312 [bad hdr length 0 - too short, < 20]
00:00:00.349433 rule 1/0(match): block in on sk0_vlan20: 192.168.20.52.35393 > 192.168.15.18.445: [|tcp]
00:00:01.200219 rule 1/0(match): block in on sk0_vlan20: 192.168.20.52.35393 > 192.168.15.18.445: [|tcp]
00:00:00.066188 rule 1/0(match): block in on sk0_vlan20: 192.168.20.52.35393 > 192.168.15.18.445: [|tcp]
00:00:02.326072 rule 1/0(match): block in on sk0_vlan20: 192.168.20.52.35393 > 192.168.15.18.445: [|tcp]
00:00:04.800490 rule 1/0(match): block in on sk0_vlan20: 192.168.20.52.35393 > 192.168.15.18.445: [|tcp]
00:00:09.600865 rule 1/0(match): block in on sk0_vlan20: 192.168.20.52.35393 > 192.168.15.18.445: [|tcp]
00:00:00.010365 rule 1/0(match): block in on sk0_vlan20: 192.168.20.52.35393 > 192.168.15.18.445: [|tcp]
00:00:00.000098 rule 1/0(match): block in on sk0_vlan20: 192.168.20.52.35393 > 192.168.15.18.445: [|tcp]
00:00:00.502211 rule 1/0(match): block in on sk0_vlan20: 192.168.20.52.35393 > 192.168.15.18.445: tcp 20 [bad hdr length 0 - too short, < 20]
00:00:01.020266 rule 1/0(match): block in on sk0_vlan20: 192.168.20.52.35393 > 192.168.15.18.445: [|tcp]
00:00:02.040052 rule 1/0(match): block in on sk0_vlan20: 192.168.20.52.35393 > 192.168.15.18.445: [|tcp]
00:00:04.081394 rule 1/0(match): block in on sk0_vlan20: 192.168.20.52.35393 > 192.168.15.18.445: [|tcp]

La comunicación por SMB se hace desde 2 redes distintas, en la LAN(em0) y cualquier otra de las redes.

Revisamos información relacionada con estos logs (Logs show "blocked" for traffic from a legitimate connection, why?) en el siguiente link
http://doc.pfsense.org/index.php/Logs_show_%22blocked%22_for_traffic_from_a_legitimate_connection,_why%3F
pero no aplica para este caso, ya que si existe bloqueo de comunicación.

Estos son los datos de la versión que estamos usando:

System Information
Version 2.0.3-RELEASE (i386)
built on Fri Apr 12 10:22:21 EDT 2013
FreeBSD 8.1-RELEASE-p13

You are on the latest version.
Platform pfSense
CPU Type Intel(R) Xeon(TM) CPU 2.80GHz
Uptime
Current date/time
Wed Aug 14 18:26:48 CDT 2013
DNS server(s) 127.0.0.1
192.168.15.1
Last config change Wed Aug 14 16:14:17 CDT 2013

Agradezco de antemano la orientación que puedan brindar para encontar el porque de esta situacion

bgsistemas · Aug 14, 2013, 11:49 PM

Olvide comentar que este bloqueo se presenta en cualquiera de las VLAN´s hacia la LAN. Este es el listado de la reglas en el equipo

[2.0.3-RELEASE][admin@routerpv.virtual.com]/root(6): pfctl -sr
scrub on em1 all fragment reassemble
scrub on em0 all fragment reassemble
scrub on sk0_vlan16 all fragment reassemble
scrub on sk0_vlan21 all fragment reassemble
scrub on sk0_vlan20 all fragment reassemble
scrub on sk0_vlan17 all fragment reassemble
anchor "relayd/" all
block drop in log all label "Default deny rule"
block drop out log all label "Default deny rule"
block drop in quick inet6 all
block drop out quick inet6 all
block drop quick proto tcp from any port = 0 to any
block drop quick proto tcp from any to any port = 0
block drop quick proto udp from any port = 0 to any
block drop quick proto udp from any to any port = 0
block drop quick from <snort2c>to any label "Block snort2c hosts"
block drop quick from any to <snort2c>label "Block snort2c hosts"
block drop in log quick proto tcp from <sshlockout>to any port = ssh label "sshlockout"
block drop in log quick proto tcp from <webconfiguratorlockout>to any port = http label "webConfiguratorlockout"
block drop in quick from <virusprot>to any label "virusprot overload table"
block drop in on ! em1 inet from 192.168.40.0/24 to any
block drop in inet from <__automatic_86219efe_0> to any
block drop in on ! em0 inet from 192.168.15.0/24 to any
block drop in on ! sk0_vlan16 inet from 192.168.16.0/24 to any
block drop in on ! sk0_vlan21 inet from 192.168.21.0/24 to any
block drop in on ! sk0_vlan20 inet from 192.168.20.0/24 to any
block drop in on ! sk0_vlan17 inet from 192.168.17.0/24 to any
block drop in on sk0_vlan16 inet6 from fe80::20a:5eff:fe1b:46c5 to any
block drop in on sk0_vlan21 inet6 from fe80::20a:5eff:fe1b:46c5 to any
block drop in on sk0_vlan20 inet6 from fe80::20a:5eff:fe1b:46c5 to any
block drop in on sk0_vlan17 inet6 from fe80::20a:5eff:fe1b:46c5 to any
block drop in on em1 inet6 from fe80::20e:cff:fe3d:f497 to any
block drop in on em0 inet6 from fe80::20e:cff:feb8:7307 to any
pass in on lo0 all flags S/SA keep state label "pass loopback"
pass out on lo0 all flags S/SA keep state label "pass loopback"
pass out all flags S/SA keep state allow-opts label "let out anything from firewall host itself"
pass out route-to (em1 192.168.40.254) inet from 192.168.40.5 to ! 192.168.40.0/24 flags S/SA keep state allow-opts label "let out anything from firewall host itself"
pass in quick on em0 proto tcp from any to (em0) port = http flags S/SA keep state label "anti-lockout rule"
pass in quick on em0 proto tcp from any to (em0) port = ssh flags S/SA keep state label "anti-lockout rule"
anchor "userrules/" all
pass quick on sk0_vlan20 inet proto tcp from 192.168.20.0/24 to 192.168.15.0/24 flags S/SA keep state label "USER_RULE"
pass on em0 inet proto tcp from 192.168.15.0/24 to 192.168.20.0/24 flags S/SA keep state label "USER_RULE"
pass in quick on em1 reply-to (em1 192.168.40.254) inet proto udp from 192.168.40.254 to 192.168.40.5 port = netbios-ns keep state label "USER_RULE: Easy Rule: Passed from Firewall Log View"
pass in quick on em0 inet proto tcp from 192.168.15.0/24 to 192.168.15.0/24 flags S/SA keep state label "USER_RULE"
pass in quick on em0 all flags S/SA keep state label "USER_RULE"
pass in quick on em0 inet from 192.168.15.0/24 to 192.168.15.0/24 flags S/SA keep state label "USER_RULE"
pass in quick on em0 inet from 192.168.15.0/24 to 192.168.20.0/24 flags S/SA keep state label "USER_RULE"
pass in quick on em0 inet from 192.168.15.0/24 to any flags S/SA keep state label "USER_RULE: Default allow LAN to any rule"
pass in quick on sk0_vlan16 all flags S/SA keep state label "USER_RULE"
pass in quick on sk0_vlan21 all flags S/SA keep state label "USER_RULE"
pass in quick on sk0_vlan20 all flags S/SA keep state label "USER_RULE"
pass in quick on sk0_vlan20 from <easyruleblockhostsopt3>to any flags S/SA keep state label "USER_RULE: Easy Rule: Blocked from Firewall Log View"
pass in quick on sk0_vlan20 inet from 192.168.20.0/24 to 192.168.20.0/24 flags S/SA keep state label "USER_RULE"
pass in quick on sk0_vlan20 inet from 192.168.20.0/24 to 192.168.15.0/24 flags S/SA keep state label "USER_RULE"
pass in quick on sk0_vlan17 all flags S/SA keep state label "USER_RULE"
anchor "tftp-proxy/*" all
[2.0.3-RELEASE][admin@routerpv.virtual.com]/root(7):

</easyruleblockhostsopt3></virusprot></webconfiguratorlockout></sshlockout></snort2c></snort2c>

periko · Aug 15, 2013, 12:12 AM

Puedo sugerirte hacer algo sencillo.

Mira, ejemplo

LAN 192.168.1.0/24
VLAN_20 192.168.2.0/24 Samba Server

Samba solo requiere 2 puertos TCP, 139/445.

Quiero que todo lo que esta detras de mi LAN pueda pegarle a los servidores samba que esta en la vlan_20
samba server 192.168.2.24

Borra las reglas de ambas nics al cabo estas en pruebas, si lo deseas sacas un respaldo por si ya tienes algo y no deseas hacerlo desde 0 cuando te funcione.

crea una regla en tu LAN:

TCP LAN NET TO VLAN_20_NET PUERTO 445
TCP LAN_NET TO VLAN_20_NET PUERTO 139

palomea que logie la reglas para que veas todo lo que hace…

De cualquier pc de la LAN pruebas con el buen amigo telnet:

telnet samba_ip 445/139

Te recomiendo en la VLAN_20 crees una regla que permita todo y sobre todo palomea que logie todo, para que veas tambien que esta recibiendo.

El samba creo que debe estar listo para poder permitir el trafico de otras redes verdad?

A ver como te va, saludos.

bgsistemas · Aug 15, 2013, 5:14 PM

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 · Aug 15, 2013, 5:25 PM

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

bgsistemas · Aug 15, 2013, 7:00 PM

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 · Aug 15, 2013, 7:07 PM

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 · Aug 15, 2013, 8:21 PM

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 · Aug 15, 2013, 8:32 PM

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 · Aug 15, 2013, 9:00 PM

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 · Aug 15, 2013, 10:16 PM

Oyes, verifica esta opcion en la parte avanzada:

Bypass firewall rules for traffic on the same interface.

Quitala ponla…?

bgsistemas · Aug 15, 2013, 10:47 PM

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 · Aug 16, 2013, 3:27 PM

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

bgsistemas · Aug 24, 2013, 1:22 AM

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