 |
 |
Both of these posts remind me of a similar device I saw mentioned on a FreeBSD mailing list recently: http://www.axiomtek.com/products/ViewProduct.asp?view=429 That one has 7 built in Gig ports each with its own PCI Express 1x lane (sufficient for full gig speed). If I were building more firewalls myself, I would probably investigate such devices, but keeping in mind nice features off the shelf servers can offer such as a remote graphical console, ssh-able remote serial console, and (compared to canned solutions) the ability to install commonly available network analysis or diagnostic tools at a network point where they are most useful. You may consider having extra network ports on it which get linked to various switches or devices on your network that allow you to get a remote view of your network traffic at critical points other than the firewall itself. PF has some interesting but realistic paranoia features on a low level, some of which can only be enabled when using routing instead of bridging. PF can also be used in FreeBSD or NetBSD at least; I think FreeBSD 7.0-RELEASE contains PF from OpenBSD 4.1, and earlier releases of FreeBSD contained an earlier version of PF. I believe the largest factor in how many packets per second a PC can forward is the L1 cache size. AMD tends to win here, and the Intel Quad cores are deficient in L1 size. If this is for on campus use, demands probably aren't extremely high and pretty much any reasonably modern PC should suffice. Its also worth sizing it for maximum transfer speed even if it is not realistic, so you are aware of what bottleneck the firewall may be imposing on future needs or bursts. The PC will probably not even notice a normal amount of traffic. Hard drive will be insignificant unless you plan on logging alot or logging intensively. You pretty much only use it to boot from otherwise. I'd still recommend setting up two hard drives in a software or hardware mirror AND MONITOR IT. The alternatives all seem to either offer less redundancy or more dependancies, and/or be more difficult to update if you feel like upgrading software. If you need any non-copper interfaces, you may want to consider externals means for converting a copper connection from your firewall to the uplink (fibre?). Fibre cards are expensive to fit into specific slot sizes in servers and finding drivers might be more obscure or less reliable than a standardized copper gig port. It adds another point of failure, but on the other hand, something external is easier to replace than an internal card, perhaps cheaper, and doesn't require a power cycle. On Wed, Mar 05, 2008 at 08:46:43AM -0500, Troy Murray wrote: I'm preparing to install a third and fourth Astaro Security Gateway device that offers the same functionality that you outline before. You can purchase a hardware device with their software, or, put their software on a system you have available. Their hardware devices can be found here: http://www.astaro.com/our_products/astaro_security_gateway/hardware_appliances/model_comparison -t On Mar 5, 2008, at 8:42 AM, Eric Weston wrote: >> I'm collecting opinions regarding hardware to use for a firewall. If you >> are interested in weighing in on this subject, I'm interested to hear >> your ideas. >> >> The hypothetical firewall is a purpose built OpenBSD box running OpenBSD >> Packet Filter (pf), on a box that bridges the outside world to a >> protected network of approximately 1000 nodes. The box needs to have a >> network interface for administrative access via ssh, and two >> high-throughput network interfaces to provide the "bridge" from the >> protected network to the internet. >> >> Given this general scenario, what sort of box might you purchase and/or >> assemble for this purpose? What elements would you consider critical? >> (architecture, interfaces, harddrive or alternative, CPU, etc..) >> >> >> Thanks, >> Eric Weston, Libraries -- Troy Murray Developer Michigan State University Biomedical Research and Informatics Center (BRIC) 100 Conrad Hall East Lansing, MI 48824 Phone: 517-432-4248 Fax: 517-353-9420 E-mail: [log in to unmask] Calendar HTML - http://www.icalx.com/html/troymurray72/month.php?cal=BRIC+Work iCalendar - http://www.icalx.com/public/troymurray72/BRIC%20Work.ics