Router con multiwan y failover…?
-
¡Hola!
En http://www.bellera.cat/josep/pfsense/regles_cs.html#WAN dije:
La existencia de servidores Samba/CIFS (y, lo que es lo mismo, de servicios de archivos de Windows) en la red LAN origina paquetes del examinador de equipos que llegan a la puerta de enlace por defecto del cortafuegos. pfSense los bloquea automáticamente como medida de seguridad. Estos bloqueos quedan reflejados en el log del cortafuegos. Esta regla sólo tiene la finalidad de sustituir el comportamiento estándar de pfSense y evitar así los logs.
Creo que lo que te está pasando está relacionado con esto … Prueba a poner una regla que bloquee el tráfico samba. Si sólo tienes una LAN mejor ponla en la propia LAN. Yo la puse en las WAN porque tengo varias LAN y me interesa que entre algunas de ellas pueda pasar el tráfico samba.
Saludos,
Josep Pujadas
-
Gracias, veo que bloqueas los puertos del alias "samba", podrias decirme que puertos tienes en ese alias para ahorrarme la busqueda? :D
Lo que me tiene mosca es que el error ese se de solo por cambiar el gateway de * a FailoverTC … No entiendo que puedo estar provocando con ese cambio, salvo el hecho de que los datos en lugar de mandarse directamente al router de Telefonica se esten mandando a una cola que, en condiciones normales, tambien deberia mandar el trafico directamente a ese mismo router de Telefonica (siempre que la conexion no este caida)
Tengo en la red un servidor de Samba bajo una Debian. Y en su momento tuve una regla en el firewall (era la 1a) que veo que ahora mismo la tengo desactivada que hacia que el pfsense ignorara todos los paquetes recibidos a los puertos 137-139 que son los de Netbios, ya que me parece que el log se me llenaba de "basura" por culpa de esos paquetes.
-
Segun he leido en este thread:
http://forum.pfsense.org/index.php?topic=8760.0;prev_next=next
que ese problema es debido a que el servidor de DHCP responde a las peticiones de DHCP que recibe en interfaces distintos al de LAN, aunque no este el server de DHCP activo en esos interfaces, lo cual podria tener sentido en mi caso al ser una maquina VMWARE en que todos los interfaces virtuales son realmente un unico interface fisico.
Ademas he visto antes en los logs que en efecto habia errores "raros" en status / system logs / dhcp. He hecho un clean de esos logs, y ahora incluso intentandolo no consigo que me aparezcan de nuevo…? Los errores eran de esta misma mañana cuando yo he estado haciendo pruebas, y parecia en efecto que el server de DHCP intentara asignar dos veces tanto nombre como IP a un mismo ordenador, como si primero le llegara una peticion de LAN, asignara nombre e IP, y despues le llegara una misma peticion de la misma MAC.
Pero lo que parece ser que por ahora me ha solucionado el problema ha sido simplemente volver a poner la regla en el interface LAN para que ignore todo el trafico de Netbios. Juraria que en su momento la puse porque se me llenaban los logs de basura (pfSense pensaba que le llegaba trafico Netbios en el interface WAN), pero no sabria decir porque acabe deshabilitando esa regla. Ahora al activarla de nuevo para que me haga un Block del trafico TCP/UDP en los puertos 137 a 139, el error de los PCs que me decian que ya existia un ordenador con ese nombre de red... simplemente ha desaparecido.
En resumen, no se ni por que me fallaba antes, ni por que lo he arreglado asi. Pero prometo que no estoy loco, me es algo MUY facilmente reproducible... Cambio el gateway de * a una cola Failover, y los ordenadores empiezan a protestar de que existe un equipo con ese nombre. Quito el checkmark en la regla de Block Netbios, y los ordenadores dejan de quejarse.
Misterios... ???
-
¡Hola!
Gracias, veo que bloqueas los puertos del alias "samba", podrias decirme que puertos tienes en ese alias para ahorrarme la busqueda?
http://www.bellera.cat/josep/pfsense/alies_cs.html
Segun he leido en este thread:
http://forum.pfsense.org/index.php?topic=8760.0;prev_next=next
que ese problema es debido a que el servidor de DHCP responde a las peticiones de DHCP
Igual hay alguna relación con DHCP, aunque no la veo, http://es.wikipedia.org/wiki/DHCP
Pienso que más bien es una cuestión de NetBIOS, http://es.wikipedia.org/wiki/NetBIOS
NetBIOS funciona haciendo broadcasts dentro de cada subred. Pero además hay que tener presente que si un paquete entra en pfSense lo ven el resto de interfases de pfSense. O sea que los broadcasts de la LAN son vistos por la WAN, que los detiene por defecto. Y esto no le gusta a la configuración que tu tienes. Por tanto, como bien has hecho, hay que detenerlos en la propia LAN.
Tu configuración es un tanto compleja, por lo que dices. Igual hay una interacción con los dos servicios.
Si funciona, no le demos más vueltas …
Saludos,
Josep Pujadas
-
Pues me añado por si las moscas el 445 a la lista de puertos "ignorados" por el pfSense.
Si, como dices mi setup es un tanto raro. Habra que ver si acabo por moverlo todo a una maquina fisica (sea embeded o no) para no complicarme la vida, pero lo hare solo si encuentro alguna mejora al hacerlo. De mientras esto lo empece un poco de prueba, y la verdad que al final he acabado contentisimo con el invento, creo que dificilmente lo cambiaria por ninguna otra solucion ni de router fisico, ni de pago, ni …
No tengo claro de donde venia el problema, pero vaya... me conformo con que se me haya solucionado :D Que un broadcast Netbios lo reciban mis 4 interfaces virtuales por ser realmente uno unico fisico, lo entiendo, pero no acabo de entender el porque no pasa si tengo de gateway *, y si pasa si tengo de gateway una pool.
-
Aqui estan los mensajecitos de error en System logs -> System.
Estos mensajecitos son "cortesia" de haber cambiado como explicaba antes el default gateway de * a FailoverTC. Sin hacer absolutamente ningun cambio mas…
Cada MAC ademas me devuelve 3 errores, que es el numero de interfaces WAN que tengo (WAN OPT1 OPT2). Tengo ademas todos los ordenadores con un DHCP lease para que siempre tengan la misma IP, el PC28 por ejemplo tiene la IP 192.168.1.28 prefijada, y su MAC es 00:14:85:84:51:93. Aqui abajo se ve que se le esta intentando asignar 3 veces la IP 192.168.1.168 - que pertenece al rango de IPs dinamicas a asignar.
Me da por lo tanto que por alguna razon cuando hago ese cambio en las reglas, algo estoy cambiando tambien para que las peticiones DHCP de los equipos de la red sean respuestos por los otros interfaces. Alguna sugerencia?
May 9 17:13:18 dhcpd: uid lease 192.168.1.174 for client 00:04:76:a0:ba:71 is duplicate on 192.168.1/24
May 9 17:13:47 dhcpd: uid lease 192.168.1.158 for client 00:1d:60:74:63:cf is duplicate on 192.168.1/24
May 9 17:14:06 dhcpd: uid lease 192.168.1.198 for client 00:14:85:84:51:93 is duplicate on 192.168.1/24
May 9 17:14:06 dhcpd: uid lease 192.168.1.198 for client 00:14:85:84:51:93 is duplicate on 192.168.1/24
May 9 17:14:06 dhcpd: uid lease 192.168.1.168 for client 00:0f:ea:2b:93:ed is duplicate on 192.168.1/24
May 9 17:14:06 dhcpd: uid lease 192.168.1.168 for client 00:0f:ea:2b:93:ed is duplicate on 192.168.1/24
May 9 17:14:07 dhcpd: uid lease 192.168.1.169 for client 00:14:85:84:52:20 is duplicate on 192.168.1/24
May 9 17:14:07 dhcpd: uid lease 192.168.1.169 for client 00:14:85:84:52:20 is duplicate on 192.168.1/24
May 9 17:14:09 dhcpd: uid lease 192.168.1.168 for client 00:0f:ea:2b:93:ed is duplicate on 192.168.1/24
May 9 17:14:09 dhcpd: uid lease 192.168.1.198 for client 00:14:85:84:51:93 is duplicate on 192.168.1/24
May 9 17:14:09 dhcpd: uid lease 192.168.1.169 for client 00:14:85:84:52:20 is duplicate on 192.168.1/24
May 9 17:14:13 dhcpd: uid lease 192.168.1.165 for client 00:0f:ea:2b:93:de is duplicate on 192.168.1/24
May 9 17:14:13 dhcpd: uid lease 192.168.1.165 for client 00:0f:ea:2b:93:de is duplicate on 192.168.1/24
May 9 17:14:14 dhcpd: uid lease 192.168.1.179 for client 00:0f:ea:2b:e7:2f is duplicate on 192.168.1/24
May 9 17:14:14 dhcpd: uid lease 192.168.1.179 for client 00:0f:ea:2b:e7:2f is duplicate on 192.168.1/24
May 9 17:14:16 dhcpd: uid lease 192.168.1.183 for client 00:14:85:84:52:15 is duplicate on 192.168.1/24
May 9 17:14:16 dhcpd: uid lease 192.168.1.183 for client 00:14:85:84:52:15 is duplicate on 192.168.1/24
May 9 17:14:16 dhcpd: uid lease 192.168.1.143 for client 00:0f:ea:2b:e7:34 is duplicate on 192.168.1/24
May 9 17:14:16 dhcpd: uid lease 192.168.1.143 for client 00:0f:ea:2b:e7:34 is duplicate on 192.168.1/24
May 9 17:14:16 dhcpd: uid lease 192.168.1.165 for client 00:0f:ea:2b:93:de is duplicate on 192.168.1/24
May 9 17:14:17 dhcpd: uid lease 192.168.1.179 for client 00:0f:ea:2b:e7:2f is duplicate on 192.168.1/24
May 9 17:14:17 dhcpd: uid lease 192.168.1.197 for client 00:14:85:84:52:10 is duplicate on 192.168.1/24
May 9 17:14:17 dhcpd: uid lease 192.168.1.197 for client 00:14:85:84:52:10 is duplicate on 192.168.1/24
May 9 17:14:18 dhcpd: uid lease 192.168.1.183 for client 00:14:85:84:52:15 is duplicate on 192.168.1/24
May 9 17:14:19 dhcpd: uid lease 192.168.1.143 for client 00:0f:ea:2b:e7:34 is duplicate on 192.168.1/24
May 9 17:14:19 dhcpd: uid lease 192.168.1.197 for client 00:14:85:84:52:10 is duplicate on 192.168.1/24
May 9 17:14:42 dhcpd: uid lease 192.168.1.186 for client 00:01:02:46:71:25 is duplicate on 192.168.1/24
May 9 17:14:58 dhcpd: uid lease 192.168.1.173 for client 00:01:02:46:83:d6 is duplicate on 192.168.1/24
May 9 17:16:49 dhcpd: uid lease 192.168.1.157 for client 00:1d:60:74:64:73 is duplicate on 192.168.1/24
... -
¡Hola!
¿Tienes DHCP activado en todas las interfases o sólo en una?
Intenta bloquear las peticiones DHCP en tus dos WAN (WAN y OPT1) que llegan de LAN.
Estás con una configuración virtual, no sé si este comportamiento se puede reproducir en una configuración con tres NIC (tarjetas de red) físicas. Si ello fuera así estaríamos ante un bug a reportar.
Una pregunta. ¿Las tres NIC virtuales tienen la misma MAC? Quizás pueda venir de ahí el problema. Supongo que en cada tramo tienes subredes distintas (LAN, WAN y OPT1) ya que esto es obligado para que PF (Packet Filter) funcione correctamente.
Saludos,
Josep Pujadas
-
Hola Josep,
No, obviamente tengo el DHCP activado solo en LAN, ni en OPT1 ni en OPT2. En WAN creo que ni siquiera existe opcion de activarlo (son 3 las conexiones WAN que tengo, WAN OPT1 y OPT2).
Las MAC acabo de comprobarlas y son distintas, son las creadas por VMWare al crear la maquina virtual. Cada una de ellas usa una subred distinta, si.
LAN - 00:0c:29:25:96:bc - 192.168.1.x
WAN - 00:0c:29:25:96:c6 - 192.168.4.x
OPT1 - 00:0c:29:25:96:d0 - 192.168.3.x
OPT2 - 00:0c:29:25:96:da - 192.168.2.xIntentare poner una regla en WAN/OPT1/OPT2 para que ignoren el trafico DHCP (puertos 546 y 547 si no me equivoco) a ver si sirve de algo. Lo que no se ver es porque este comportamiento pasa al cambiar el gateway de * a FailoverTC, es como si al tener * de gateway quizas ademas de estar respondiendo LAN a las peticiones DHCP de los terminales las este reenviando a uno de mis routers, y ni me entero, pero al cambiarlo por una pool Failover esas peticiones DHCP esten siendo broadcasteadas de nuevo a toda la red…?¿
Tenia planeado en un futuro pasar de una VM a un PC real si los tests de rendimiento me dan algun beneficio. Estoy pero bastante convencido que con un PC con 4 NICs el problema no deberia estar ahi...
-
¡Hola!
Intentare poner una regla en WAN/OPT1/OPT2 para que ignoren el trafico DHCP (puertos 546 y 547 si no me equivoco)
Según http://es.wikipedia.org/wiki/DHCP son UDP 67 y 68.
pero al cambiarlo por una pool Failover esas peticiones DHCP esten siendo broadcasteadas de nuevo a toda la red…?¿
Bueno, es que el montaje que tienes yo lo calificaría de laboratorio más que de real.
Hace tiempo monté un cortafuegos Kerio sobre WMware en un Windows 2000 Server y la máquina tenía tres tarjetas de red físicas: WAN, DMZ y LAN. Sobre el Windows 2000 Server funcionaban varias máquinas virtuales VMware y una de ellas tenía el Kerio.
Estoy pero bastante convencido que con un PC con 4 NICs el problema no deberia estar ahi…
Yo también creo que no ocurrirá con 4 NIC distintas …
Saludos,
Josep Pujadas
-
pero al cambiarlo por una pool Failover esas peticiones DHCP esten siendo broadcasteadas de nuevo a toda la red…?¿
Bueno, es que el montaje que tienes yo lo calificaría de laboratorio más que de real.
hehe lo se, pero, y lo que me divierto toqueteando, rompiendo, y despues arreglando cosas…? :D
Que aunque parezca mentira esto lleva ya casi un año funcionando asi, y mientras el hardware de de si... De entrada ahora mismo me basta tener un solo SAI para lo que podrian llegar a ser 4 ordenadores, y los tengo todo en uno. Siempre puedo decir que lo tengo asi por ecologismo y para ayudar a luchar contra el cambio climatico... :)
Y correcto, los puertos son el 67 y 68, he corrido demasiado antes, 546 y 547 son para IP v6. El lunes mirare a ver si puedo hacer que las 3 WANs simplemente ignoren ese trafico.
-
Bueno, empiezo a pensar que lo del DHCP no tiene ni tenia nada que ver con el problema de que los PCs me dieran error de "existe un nombre duplicado en la red"…
He puesto rules para bloquear las peticiones DHCP a los 3 interfaces de WAN, lo que me ha servido para ver que con cada ordenador que se enciende llegan dos paquetes que son descartados, supongo que el DHCPDISCOVER y el DHCPREQUEST. Lo curioso, me llegan unicamente a los interfaces WAN y OPT1, no asi al OPT2. Ni idea de porque...
Asi que con las rules puestas para ver que estos paquetes eran descartados he desactivado la regla para bloquear Netbios, y he puesto el gateway de mi regla por defecto de nuevo a * (en lugar de al Failover). La red me funciona correctamente, y sigo viendo como llegan esos paquetes a los interfaces WAN y OPT1, asi que supongo que siempre han estado ahi sin causar problema (por lo de ser una unica NIC fisica, o por lo que sea, a saber...)
En fin, que creo que como con la norma de bloquear el trafico Netbios se me soluciona el problema no voy a perder mas el tiempo ni a hacerselo perder a nadie por esto. Sigo sin entender exactamente que es lo que esta pasando, pero el caso es que me funciona bien, asi que no le voy a dar mas vueltas (a no ser que algun dia migre a un pfSense fisico, en lugar de virtual, y pueda tener mas informacion)
Muchas gracias Josep!
