Bloqueo de conexiones por reglas de Firewall
-
Puedo sugerirte hacer algo sencillo.
Mira, ejemplo
LAN 192.168.1.0/24
VLAN_20 192.168.2.0/24 Samba ServerSamba 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.24Borra 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 139palomea 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.
-
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.
-
Haz una regla en ambos lados, que permita todo y que logie todo, pruebas y vez que esta haciendo!!!
-
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.1VLAN:Wireless_Internos 192.168.16.0/24
Equipo : 192.168.16.48 -
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 -
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.
-
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.
-
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.
-
Oyes, verifica esta opcion en la parte avanzada:
Bypass firewall rules for traffic on the same interface.
Quitala ponla…?
-
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.
-
Men yo me hiria a el foro gabacho, no tengo un laboratorio para ver el problema real.
-
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