Router con multiwan y failover…?
-
Ojo con el balanceo porque tiene algunas limitaciones, http://www.bellera.cat/josep/pfsense/cas_estudi_cs.html#balanceig
Josep,
Veo ahi que pones las limitaciones de usar ftp con balanceo de carga. Veo obvio que no vas a poder hacer conexiones/descargas por ftp repartiendo tu trafico por varias conexiones, que supongo es a lo que te refieres. Pones que se puede montar otro pfSense para el ftp, pero yo creo que la solucion seria mucho mas sencillo que eso, simplemente haciendo que el trafico al puerto 21 salga por una conexion concreta en lugar de por una pool con load balance/failover se solucionaria, no…?
Lo de usar los DNS de cada ISP como IP para monitorizar si una conexion esta activa o no lo he hecho despues de leer en tu pagina lo de "Se necesita, por tanto, que la IP pública de la ADSL conteste a estos ping internos". Me daba pereza tener que pensar demasiado en como hacer que mis IPs publicas respondieran a pings hechos desde dentro ya que probablemente habria tenido que tocar no solo el pfSense sino tambien los routers fisicos, y ademas mis IPs, aunque no esten cambiando cada dos por tres ya que nunca apago las conexiones, si que no son fijas, y cada x meses me cambian. De ahi que haya preferido usar los DNS de cada uno de los 3 ISPs, que deberian estar siempre ahi desde cada una de las conexiones y seran las mismas por los años de los años...
Un saludo!
-
¡Hola de nuevo!
Veo ahi que pones las limitaciones de usar ftp con balanceo de carga. Veo obvio que no vas a poder hacer conexiones/descargas por ftp repartiendo tu trafico por varias conexiones, que supongo es a lo que te refieres. Pones que se puede montar otro pfSense para el ftp, pero yo creo que la solucion seria mucho mas sencillo que eso, simplemente haciendo que el trafico al puerto 21 salga por una conexion concreta en lugar de por una pool con load balance/failover se solucionaria, no…?
Puedes probar a hacer salir a 127.0.0.1 por el pool que quieras, a ver si FTP proxy-helper admite el balanceo, aunque no lo veo claro. Pienso que irá a veces y a veces no. FTP es multicanal y es complicado gestionarlo.
Lo más fácil es lo que dices, imponer que todo el FTP vaya por una de las WAN.
Lo de usar los DNS de cada ISP como IP para monitorizar si una conexion esta activa o no lo he hecho despues de leer en tu pagina lo de "Se necesita, por tanto, que la IP pública de la ADSL conteste a estos ping internos". Me daba pereza tener que pensar demasiado en como hacer que mis IPs publicas respondieran a pings hechos desde dentro ya que probablemente habria tenido que tocar no solo el pfSense sino tambien los routers fisicos, y ademas mis IPs, aunque no esten cambiando cada dos por tres ya que nunca apago las conexiones, si que no son fijas, y cada x meses me cambian. De ahi que haya preferido usar los DNS de cada uno de los 3 ISPs, que deberian estar siempre ahi desde cada una de las conexiones y seran las mismas por los años de los años…
Es correcto. El tutorial está hecho con una versión que todavía no admitía poner como chivato un DNS externo. Sin IP estática la opción de DNS es sensacional.
Saludos,
Josep Pujadas
-
Puedes probar a hacer salir a 127.0.0.1 por el pool que quieras, a ver si FTP proxy-helper admite el balanceo, aunque no lo veo claro. Pienso que irá a veces y a veces no. FTP es multicanal y es complicado gestionarlo.
Lo más fácil es lo que dices, imponer que todo el FTP vaya por una de las WAN.
hehehe no gracias! :D
Si no pretendo complicarme la vida, si ya digo que yo NO uso balanceo de carga… No pretendo fusionar 3 conexiones en una mega conexion para descargar a lo loco, sino que el trafico de cada tipo vaya por una conexion determinada, principalmente para que el trafico que pueda saturar mas la conexion NO interfiera en el trafico que lo que necesita no es ancho de banda, sino latencia baja.
No tengo ningun filtro para el trafico de ftp, por lo que este sale por la conexion de Telefonica, que es la conexion "gorda" con mas ancho de banda y peor latencia, donde acaba todo el trafico desconocido. -
Fantastico me esta funcionando el invento este del failover.
Tan fantastico, que despues de acabar de configurarlo y testearlo esta mañana a base de apagar los routers para comprobar que el me redirigiera el trafico a la otra conexion que tocara, se me ha olvidado reconectar a la corriente uno de los tres routers, y todo el trafico de una de las conexiones ha estado saliendo por su failover sin que ni siquiera me haya dado cuenta…
Ahora al ir a cotillear que tal iba todo ha sido cuando me he dado cuenta que una de las conexiones no tenia trafico, y he conectado a la corriente de nuevo el router que se habia tomado el dia festivo :D
-
Tras una semanita con el failover funcionando, parece que todo funciona bien salvo un pequeño detalle. He intentado modificar mi ultima regla (la generica) para que el trafico de salida de esa regla en lugar de dirigirse a * (* = default, con lo que sale por WAN, la primera conexion) se dirija a FailoverTC (la cola de failover, de modo que si WAN falla, el trafico salga por OPT2), y este unico cambio me provoca efectos en la red que por decirlo de algun modo me cuestan entender.
Aqui pongo una captura de la ultima regla repetida, la que esta activa ahora mismo es la que tiene gateway *. La que esta disabled es una copia de la otra, pero con el gateway cambiado a FailoverTC.
Ese unico cambio hace que al reiniciar cualquier ordenador con XP de la red, al arrancar me salga el tipico warning en el traybar de "existe un nombre de red duplicado", como si ya existiera ese mismo ordenador en la red u otro con el mismo nombre de red. El ordenador funciona correctamente a nivel IP, pero no asi a nivel red de Windows. Si el ordenador es por ejemplo PC23 y tiene de ip 192.168.1.23, puede navegar perfectamente y puede pinguear a quien quiera. Cualquier ordenador puede pinguear a 192.168.1.23, pero NO puede pinguear a PC23 ya que el nombre no resuelve. Asi mismo, no se puede acceder a los recursos compartidos de ese ordenador, como por ejemplo \pc23\discod
En resumen, el simple cambio del gateway de * a FailoverTC por alguna razon que no entiendo hace que la red de Windows deje de funcionar.
Alguna sugerencia de como hacer que el trafico que no cumpla ninguna de mis reglas anteriores use de gateway una cola de failover en lugar de un simple gateway? Como cambiar el gateway por defecto, que ahora mismo es el gateway de WAN, por Pool de failover?
-
¡Hola!
¿Estás con Active Directory? o simplemente tienes las estaciones Windows en grupo/s de trabajo?
¿Quién hace de DNS para las máquinas Windows? ¿Hay algún servidor WINS en tu red? ¿Cuál, si es afirmativo?
Saludos,
Josep Pujadas
-
Hola Josep,
No tengo active directory, ni dominio, ni practicamente nada… Estan todos los ordenadores en un mismo grupo de trabajo, pero vaya, que este hace poca cosa.
No hay servidor WINS en mi red. El propio pfSense es quien me hace de servidor de DHCP en la red, y de DNS a los terminales les asigna los DNS primarios de Jazztel y Comunitel (los mismos que pingueo para ver si las conexiones estan UP)
-
¡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!
