<HTML><BODY>
 I will explain more deeply. I need to deploy a firewall(s) in front of web server farm because I need to do billing - I will use CentOS with iptables + ipset to store a list if my clients so when client doesn't pay his server's IP is out of the list and he can't access the web server.<br><br>Second - I know that iptables is very heavy and it's not recommended to use it in gigabit firewall but I don't have a choice as far as I know only ipset works with iptables. I don't know can pf store 500 IPs in one list. Ipset is written for that purpose. <br><br>I can't find information is there linux or BSD distribution with effective firewall that uses optimized algorithm to store hundreds of IPs and to forward huge traffic. Any idea?  <br><br>regards<br><br><br><br><br><br><br><peter.serwe@gmail.com><centos@centos.org>I'll second damn near everything nate said, and hopefully add a tidbit or two.<br><br>If you're new to BSD, you may want to consider the pfsense project in the aforementioned active-active configuration.<br><br>It gives you a nice, intuitive gui to manage your failover firewalls, if you insist on putting a firewall in front of your web servers.<br><br>Better to secure the box, leave only the ports you need open on the public interfaces, and don't firewall them.<br><br>Also, I'd strongly consider running your firewalls with no disk at all.  A Live CD, CF card or USB Flash to boot off of, remote syslog and<br>one less subsystem (disks) to buy/fail makes for some mighty cheap 1U servers.  A single dual-core with core speeds above 3.0Ghz<br>and 4GB of RAM is to pass Gb @ line rate - ethernet overhead.  Truth be told, it's already being done on much less<br>than that.  You can also load balance your traffic, albiet somewhat primitively with it.  If you really want massive throughput, consider toying<br>around with extremely expensive 10G gear, size RAM appropriately, and see how PF performs under multi-processor, high-core speed.<br>but if you're handling over a Gb of traffic and you can't split the application into multiple farms, that's the best move.  <br><br>Akamai, for instance, runs 10G to each rack, each rack has around 20-24 servers, and they run GB to the server.<br><br><a href="http://pfsense.org">pfsense.org</a> has extensive information about hardware requirements, features, and what you're looking to do.<br><br><a href="https://calomel.org/network_performance.html">https://calomel.org/network_performance.html</a> is an excellent BSD firewall performance site.<br><br>One thing to note, you are claiming to want to deploy this as a passive bridge.  You cannot do what you want to do<br>running anything in bridge mode.  The packets need to route somehow.  Get a /29 from your colo provider and ask<br>to have your existing block routed through it once you've tested it.<br><br>Another option for a seamless failover, is to alias a different range of IP's to the server interfaces, put a /29 and whatever<br>netblock you want to end up being your public IP block on the PFSense hardware.  When you're convinced everything's<br>working through rigorous testing, put a test domain up pointing to that block, modify virtualhost entries on the servers to<br>respond to that domain with your production web site, and test some more.  Once you're convinced that's working perfectly,<br>make the changes in DNS to point your production domain at the IP's you want, and failover will happen with DNS convergence.<br><br>Peter<br><br><br><div class="gmail_quote">On Fri, Dec 18, 2009 at 9:06 AM, nate <span dir="ltr"><<a href="mailto:centos@linuxpowered.net">centos@linuxpowered.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="h5">sadas sadas wrote:<br>><br>> Hi,<br>>  I want to configure CentOS on powerful server with gigabit<br>> adapters as transparent bridge and deploy it in front of server farm.<br>> Can you tell how to optimize the OS for hight packet processing? What<br>> configurations I need to do to achieve very hight speeds and thousands of<br>>  packets?<br><br></div></div>iptables makes a TERRIBLE firewall, use pf instead<br><br><a href="http://www.openbsd.org/faq/pf/index.html" target="_blank">http://www.openbsd.org/faq/pf/index.html</a><br><br>Also consider how your going to provide redundancy, if you have a web<br>server farm you want to protect them with at least two firewalls, not<br>one.<br><br><a href="http://www.openbsd.org/faq/pf/carp.html" target="_blank">http://www.openbsd.org/faq/pf/carp.html</a><br><br>I haven't used CARP myself but did setup a pair of pf firewalls about<br>5 years ago in a large network in bridging mode, the layer 3 fault<br>tolerance was provided by OSPF on the core switches, the firewalls<br>were active-active(with pfsync) since they were layer 2 only.<br><br>Maybe someday linux will fix the overly complex iptables system to<br>something that is more manageable, not holding my breath though.<br><br>If you want really high speed(say multi GbE) though you'll want/need<br>to go with an appliance based solution.<br><br>Also since your referring to a web server farm, it is perfectly<br>acceptable to not use firewalls these days, if you have a good<br>load balancer that serves the same role as a firewall in that it<br>only passes traffic that you specifically configure it to pass. Also<br>in high traffic environments the performance of load balancers<br>destroys most firewalls, making investing in a high end firewall<br>a very expensive proposition.<br><br>I've worked for the better part of the last 10 years with<br>companies who did not have firewalls in front of their web servers<br>for this reason, it didn't make sense $ wise, because the benefit<br>wasn't there, and the added complexity, and performance implications<br>wasn't worth it either. Talk to most load balancing companies and<br>they'll tell you this themselves.<br><font color="#888888"><br>nate<br></font><div><div></div><div class="h5"><br></div></div></blockquote></div></centos@centos.org></peter.serwe@gmail.com></BODY></HTML>