Router con multiwan y failover…?
-
buenas, aca hay un tutorial sobre failover y balanceo de carga, lo realiza con dos WAN's http://doc.pfsense.org/index.php/MultiWanVersion1.2. Saludos
-
¡Hola!
Tienes que ir a [Services] [Load Balancer] [Pools] y definir un pool de tipo gateway con failover.
Una vez hecho esto, en las reglas que tu desees, pon el pool como gateway.
Buscando en Google:
pfsense load balance tutorial
se llega fácilmente a:
http://pfsense.bol2riz.com/tutorials/outgoing_loadbalancing/outgoing_loadbalancing.pdf
Ojo con el balanceo porque tiene algunas limitaciones, http://www.bellera.cat/josep/pfsense/cas_estudi_cs.html#balanceig
Saludos,
Josep Pujadas
-
Muchisimas gracias a los dos, creo que no solo lo he conseguido, sino que de estar todo bien habra sido MUCHISIMO mas facil de lo que me esperaba…
Julio, el tuto ese que me linkas me lo habia leido ayer, pero no me entere mucho del tema ni pense que me fuera a servir al hacer failover con balanceo de carga, cosa que yo no quiero hacer. No me interesa que en condiciones normales el trafico se reparta en tal proporcion entre las conexiones, sino que yo ruto el trafico por la conexion que quiero segun otros criterios (principalmente los puertos de destino). Una vez leido el otro tuto al que linka Josep, el primer tuto ya tiene mas sentido para mi. Los tiros ya iban por ahi, pero mi cola tenia que configurarla como "failover" en lugar de como "load balancing".
Aqui esta como lo he hecho por si le puede servir de ayuda a alguien, y cuando pueda intentare hacer mas pruebas con todas las conexiones (tengo un monton de gente por aqui y no me puedo ir dedicando a tirar las conexiones, o iba a tener a un monton de WOWers histericos pegando berridos porque se han caido).
En Load Balancer : Pool me he creado 3 pools, a las que he puesto de nombre FailoverCT FailoverTC y FailoverJC. El T J y C corresponden a las conexiones, en mi caso Telefonica Jazztel y Comunitel. La pool CT por ejemplo la he configurado como tipo Gateway, Failover, y en la pool he añadido opt2|212.145.4.97 y wan|80.58.61.250 , que corresponden a las conexiones de Comunitel y Telefonica con sus respectivos DNS (he usado el DNS primario de cada ISP como IP de monitoreo, no se si habra algun "contra" a hacerlo de este modo)
En Firewall : Rules he añadido 3 nuevas reglas, para que los PINGs a cada uno de esos 3 DNS salgan por el ISP que correspondan. Mas que nada porque tengo otra regla para que todo el trafico ICMP vaya por defecto por Jazztel (que es la conexion con menor latencia que tenemos), con lo que las IPs de monitoreo de Comunitel y Telefonica siempre habrian estado UP aunque se cayeran esas dos conexiones. He hecho un tracert a los 3 DNS, y he podido comprobar que el tracert a cada una de esas 3 IPs se hace por la conexion que le corresponde en lugar de por Jazztel.
Entonces he modificado uno de las normas que ya tengo predefinidas en el firewall, he utilizado de conejillo de indias el Steam, por simple comodidad y porque no tenia a nadie utilizandolo. Lo tenia configurado para que el trafico de Steam se direccionara directamente al gateway 192.168.2.112 (que corresponderia a la conexion de Comunitel), y lo he cambiado para que ahora use de gateway FailoverCT, que seria la cola de Comunitel con failover a la conexion de Telefonica. Al usar Steam todo funciona ok y veo por los estados que el trafico sale a la conexion de Comunitel. He desenchufado fisicamente de la corriente el router de Comunitel, y si bien el cambio ha tardado un rato (se ha perdido la conexion a la red de Steam, me ha tocado cerrarlo y abrirlo de nuevo) despues todo el trafico de Steam ha salido por la conexion de Telefonica sin tener que toquetear nada, que es lo que me interesa.
A la que pueda con esto vacio de gente hacer pruebas mas a fondo lo hare, pero creo que como lo he hecho ya me funciona. Ahora es simplemente cosa de cambiar todos los filtros que tengo en Firewall : Rules para las salidas, y en lugar de mandar el trafico directamente a la IP de la conexion que quiero usar, mandarlo a la pool que le toque.
Los cambios seran "bruscos" pero obviamente eso de esperar y ya me va bien. No pretendo que si cae la conexion de Jazztel los que esten jugando al WOW no se caigan y de modo milagroso pasen a jugar con la conexion de Comunitel, simplemente quiero que cuando se cae una de las conexiones cualquier dia de la semana a cualquier hora del dia, no tengan que llamarme a mi estresados para que les explique como cambiarlas hehe...
Un saludo!
-
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.
