El día 20 de septiembre de 2013 23:50, C. L. Martinez <carlopm...@gmail.com> escribió: > 2013/9/20 Maykel Franco <maykeldeb...@gmail.com>: >> >> El 20/09/2013 23:36, "C. L. Martinez" <carlopm...@gmail.com> escribió: >> >> >>> >>> 2013/9/20 Maykel Franco <maykeldeb...@gmail.com>: >>> > >>> > El 20/09/2013 23:25, "C. L. Martinez" <carlopm...@gmail.com> escribió: >>> >> >>> >> 2013/9/20 Maykel Franco <maykeldeb...@gmail.com>: >>> >> > >>> >> > El 20/09/2013 23:12, "C. L. Martinez" <carlopm...@gmail.com> >>> >> > escribió: >>> >> > >>> >> > >>> >> >> >>> >> >> 2013/9/20 Maykel Franco <maykeldeb...@gmail.com>: >>> >> >> > >>> >> >> > El 20/09/2013 22:46, "C. L. Martinez" <carlopm...@gmail.com> >>> >> >> > escribió: >>> >> >> >> >>> >> >> >> 2013/9/20 Camaleón <noela...@gmail.com>: >>> >> >> >> > El Thu, 19 Sep 2013 10:33:22 +0200, Maykel Franco escribió: >>> >> >> >> > >>> >> >> >> > (...) >>> >> >> >> > >>> >> >> >> >> Bueno el caso, es que compartimos el firewall con unos >>> >> >> >> >> compañeros >>> >> >> >> >> que >>> >> >> >> >> hay por aquí, tenemos el mismo rango de ip publica con el >>> >> >> >> >> mismo >>> >> >> >> >> proveedor, un ejemplo: >>> >> >> >> >> >>> >> >> >> >> - Nuestra WAN --> 80.23.4.2 >>> >> >> >> >> - La WAN de ellos --> 80.23.4.3 >>> >> >> >> >> - Gateway de la WAN proveedor --> 80.23.4.1 >>> >> >> >> >> >>> >> >> >> >> Pfsense sólo te deja definir una gateway por cada wan, esto es >>> >> >> >> >> un >>> >> >> >> >> problema puesto que queremos salir con el mismo gateway. >>> >> >> >> >> >>> >> >> >> >> Antes de postear, he ido probando cosas e inclusive he buscado >>> >> >> >> >> en >>> >> >> >> >> el >>> >> >> >> >> foro de pfsense con "pfsense multiwan same gateway" pero de la >>> >> >> >> >> parte >>> >> >> >> >> de >>> >> >> >> >> soporte de pfsense dicen que no se puede... >>> >> >> >> > >>> >> >> >> > (...) >>> >> >> >> > >>> >> >> >> > Eso es lo que comentan, pero también mencionan algo sobre un >>> >> >> >> > "doble >>> >> >> >> > NAT" >>> >> >> >> > sobre la pasarela para conseguirlo. Aunque supongo que ya lo >>> >> >> >> > habrás >>> >> >> >> > visto, te lo paso por si acaso: >>> >> >> >> > >>> >> >> >> > *** >>> >> >> >> > Same gateway for two WAN interfaces (same isp) problem in >>> >> >> >> > pfsense >>> >> >> >> > 2.0 >>> >> >> >> > http://forum.pfsense.org/index.php?topic=40400.0 >>> >> >> >> > *** >>> >> >> >> > >>> >> >> >> >>> >> >> >> Iba a responder el otro día, pero me contuve ya que parece ser >>> >> >> >> que >>> >> >> >> Maykel ya encontró una solución de su agrado. Pero viendo que no >>> >> >> >> se >>> >> >> >> entendió mi respuesta, procedo a explicarme. >>> >> >> >> >>> >> >> >> Lo que plantea Maykel SI se puede hacer con PFSense (o sea PF, >>> >> >> >> packet >>> >> >> >> filter) y con linux utilizando iptables+iproute2 ... Nada de >>> >> >> >> dobles >>> >> >> >> NATs ni cosas por el estilo (de hecho se utiliza una solo regla >>> >> >> >> "mangle"). >>> >> >> >> >>> >> >> >> Ahora bien, lo que intenté hacer ver a Maykel el otro día (y no >>> >> >> >> lo >>> >> >> >> acabó de pillar me parece) es que a nivel práctico el problema >>> >> >> >> que >>> >> >> >> plantea no es tal, por el sencillo motivo de que no tiene mucho >>> >> >> >> sentido: ¿para que quieres utilizar dos interfaces con >>> >> >> >> direccionamiento del mismo segmento de red y mismo default >>> >> >> >> gateway? >>> >> >> >> respuesta simple: para nada. Otra cosa es que se quiera >>> >> >> >> experimentar >>> >> >> >> y >>> >> >> >> trastear. >>> >> >> >> >>> >> >> >> y no tiene sentido por el mero hecho de ¿que es lo que gana: >>> >> >> >> granulidad de administración, políticas de filtering adecuadas? >>> >> >> >> No , >>> >> >> >> nada de esto. Solo obtiene ventajas si utliza bonding ... y otro >>> >> >> >> tema >>> >> >> >> es cambiar un PFSense por un ClearOS, ni "jarto de cola-cao" :)) >>> >> >> >> hago >>> >> >> >> yo eso ... Pero para gustos los colores :)) Aunque existen >>> >> >> >> razones >>> >> >> >> de >>> >> >> >> peso para utilizar PFSense por delante de un linux como firewall, >>> >> >> >> empezando por el stack TCP/IP que implementan los BSD y acabando >>> >> >> >> por >>> >> >> >> la propia potencia de PF, en la que IPTables solo le supera en un >>> >> >> >> punto técnicamente: Iptables puede utilizar todos los cores de un >>> >> >> >> servidor equipado con procesadores multi-core, cosa que PF es >>> >> >> >> uni-core >>> >> >> >> ... Pero eso cambiará en el momento que sea liberada la versión >>> >> >> >> estable de FreeBSD 10, en la que PF ya es multi-core. >>> >> >> >> >>> >> >> >> No sé si ahora me he conseguido explicar. >>> >> >> >> >>> >> >> >> Saludos. >>> >> >> >> >>> >> >> >> >>> >> >> >> -- >>> >> >> >> To UNSUBSCRIBE, email to >>> >> >> >> debian-user-spanish-requ...@lists.debian.org >>> >> >> >> with a subject of "unsubscribe". Trouble? Contact >>> >> >> >> listmas...@lists.debian.org >>> >> >> >> Archive: >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> http://lists.debian.org/caejqa5kuljora8jkmiphbyjsgggpa0xsh+mlpeoeo9arbih...@mail.gmail.com >>> >> >> >> >>> >> >> > >>> >> >> > Por lo que veo no te has enterado de nada o bien me explico fatal >>> >> >> > tio...y si >>> >> >> > tengo 2 redes de 2 empresas y quiero salir por 2 ips publicas del >>> >> >> > mismo >>> >> >> > rango, cada una la suya aunque sea: >>> >> >> > >>> >> >> > - empresa1 80.1.2.2 >>> >> >> > - empresa2 80.1.2.3 >>> >> >> > >>> >> >> > Y quiero salir por su gateway 80.1.2.1. Tenemos un isp que nos >>> >> >> > proporciona >>> >> >> > varias ips fijas del mismo rango, y tiene su gateway de toda la >>> >> >> > vida >>> >> >> > de >>> >> >> > dios. Por motivod de que cada uno quiere salir por su ip fija, no >>> >> >> > queremos >>> >> >> > salir a internet con la misma ip fija lo ves un "capricho" o un >>> >> >> > testeo....creo que te equivoas y estas configuraciones las hemos >>> >> >> > tenido >>> >> >> > en >>> >> >> > otro firewall. >>> >> >> > >>> >> >> > Si...me explico fatal... >>> >> >> >>> >> >> Vuelvo a repetirlo: lo entendí perfectamente el otro día y lo vuelvo >>> >> >> a >>> >> >> entender ahora. Y te sigo diciendo que el planteamiento no tiene >>> >> >> ningún sentido. Vamos a ver: ¿que sentido tiene que tu discrimes >>> >> >> tráfico saliente generado en tus redes internas por una u otra >>> >> >> interfaz? Ninguno, porque os estais "pisando" el ancho de banda los >>> >> >> unos y los otros ... >>> >> >> >>> >> >> Ahora vamos con el tráfico entrante: empieza a tener sentido si >>> >> >> disponeis de DMZs separadas y utilizais servicios distintos e IP's >>> >> >> públicas distintas. Si uno de esos argumentos no sé dá, la >>> >> >> implantación carece de base. >>> >> >> >>> >> >> ¿me voy explicando tio? >>> >> >> >>> >> >> Saludos. >>> >> >> >>> >> >> >>> >> >> -- >>> >> >> To UNSUBSCRIBE, email to >>> >> >> debian-user-spanish-requ...@lists.debian.org >>> >> >> with a subject of "unsubscribe". Trouble? Contact >>> >> >> listmas...@lists.debian.org >>> >> >> Archive: >>> >> >> >>> >> >> >>> >> >> http://lists.debian.org/caejqa5kjcu9h64xi4j9pdga_jwuqfsykbvq6k5snq1mrn23...@mail.gmail.com >>> >> >> >>> >> > >>> >> > Perfectamente pero tenemos clientes, los cuales tienen servicios de >>> >> > acceso >>> >> > que tienen reglas como por ejemplo ip publica origen que si no se >>> >> > lanzan >>> >> > con >>> >> > una ip publica establecida no funciona. Que te parece bro?? >>> >> > >>> >> > Saludos. >>> >> >>> >> Que eso no es ningún problema si utilizas tanto bonding bajo linux com >>> >> llagg bajo PFSense: a ambas interfaces les puedes asignar IP's via >>> >> proxy-arp o ip alias, como más te guste ... Y para las reglas de NAT >>> >> de tráfico saliente saldrás con la que tu indiques .. >>> > >>> > Lo probare. >>> > >>> >> >>> >> No hace falta montarse el follón con reglas de polcy routing con n >>> >> NATS de por medio y reglas de filtrado maquiavelicas ... Simplificas >>> >> todo con un simple bonding/llagg ... Oye, y si tan preocupados están, >>> >> que se utilicen dos fws .... >>> >> >>> >> En resumen: lo que tú querias hacer lo hace PFSense (y cualquier BSD >>> >> con PF) y lo hacen ClearOS (y obviamente cualquier linux con >>> >> iptables+iproute2), pero te estás complicando la vida de mala manera >>> >> cuando no hay porqué ... Solo espero que no sea un fw de más de 700 >>> >> reglas, porque pobre de ti para administrar eso :)) >>> > >>> > Llevas razon, porque no utilizar 2 pfsense...porque necesitamos usar el >>> > mismo firewall para garantizar el QoS sip mediante un enlace trunk. >>> >> >>> >> Saludos. >>> > >>> > Saludos y gracias. >>> >>> Si dispones de 3 o más IP públicas ya puedes aplicar QoS a los >>> servicios que desees ... >>> >>> Saludos. >>> >>> >>> -- >>> To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org >>> with a subject of "unsubscribe". Trouble? Contact >>> listmas...@lists.debian.org >>> Archive: >>> http://lists.debian.org/caejqa5+uwc1uebc6mkyyja7z+f3x1a9r+nwqmdu2yvsbm...@mail.gmail.com >>> >> >> Disponemos concretamente de 8 para 2 empresas que nos unimos a traves del >> firewall cada uno por su interfaz. >> >> Saludos. > > Pues tienes mucho campo de juego: desde utilizar cluster de dos fws > hasta utilizar solo uno con bonding ... Pero tambien te adelanto que > el QoS es efectivo cuando lo configura tu ISP en su router, pero es > bastante habitual hacerlo en los fws perimetrales, más que nada por el > "estacazo economico" que te arrean los ISP .... > > Yo en tu lugar, mantendría PFsense ante un escenario así, pero aquí > tiene mucho que ver la pericia de las personas que administran dicho > fw y sus conocimientos. > > Saludos.
Para quien le interese, al final lo resolví este tema con pfsense. En vez de agregar 2 interfaces WAN con 2 ips del diferentes publicas wan del mismo ISP, lo que hice fue solo agregar una wan y meter la otra ip como virtual alias. De tal forma, que en nat outbound(nat de salida) los paquetes que vinieran de las 2 redes a su coprrespondiente ip publica que quería de salida y walaaaaaaaaa ha funcionado. Saludos y graicas sobre todo a Martinez por la ayuda. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAJ2aOA97R5gOh5-zK5uO2yZ2_OyPLb=mOL9WRRd7q+qq...@mail.gmail.com