The Intel 10/100 card I have is also recognized by OpenBSD 3.4 as fxp0, as it was with NetBSD and FreeBSD. Which gives me an idea for possibly the best use of this Ultra 5: As a relatively fast, small, and self-contained firewall.
I found another PCI Ethernet card laying around, a 3com, so for shits and giggles I installed it in my Ultra 5 as well (there are a total of 3 PCI slots available, 2 are now full). OpenBSD also recognized that automatically and it came up as interface xl0. So for about 20 extra dollars, I've got a perfect firewall system with internal, external, and DMZ interfaces.
OpenBSD, like FreeBSD, sports a ports collection that makes compiling and installing software simpler. It's not quite as complete as FreeBSD's ports, or even NetBSD's pkg_src. For instance, OpenBSD ports didn't have mysql version 4, only 3.23.
OpenBSD also sports binary packages (which is where I got my beloved tcsh), which can be found on OpenBSD's FTP site.
Tidy Little Firewall
All of the operating systems under evaluation (FreeBSD, NetBSD, OpenBSD, and coming soon Linux and Solaris) have one or more options available to make the system an effective and secure firewall. FreeBSD, NetBSD, and of course OpenBSD have the ability to run OpenBSD's pf (packet filter). They, along with Solaris, also have the ability to run IPFilter, which is what powered OpenBSD's firewall capabilities until a very public and very nasty spat between Darren Reed (author of IP Filter) and Theo De Raadt (infamous head of the OpenBSD) over licensing issues led to OpenBSD creating its own packet filter.
Linux (2.4 and 2.6) has netfilter, which is what I currently run on my home system for a firewall/router on a dual processor x86 system.
Yet while they all have this capability, I haven't tested them as firewalls. However, since OpenBSD specializes in security, I decided to take a look at its ability to provide such functionality.
I used a fairly typical scenario for home and office users. The OpenBSD system sits with one interface (in my case, fxp0) sitting on the DSL/Cable modem connection, and another interface sitting on an internal network running an RFC 1918 network. The OpenBSD system performs one-to-many NAT, allowing several systems to share a single external IP address such as the one assigned to the Cable Modem/DSL line (Linux users often refer to this as IP masquerading).
Typical Home/Office Firewall Scenario
I've have extensive experience with Linux's netfilter and IPFilter, but none with pf. However, since pf is very similar to IPFilter in configuration, acclimating myself was quite easy.
It took me half an hour to get it working, with much of that time spent trying to figure out that it wouldn't work because (as the instructions stated) I needed to turn on IP forwarding. Doing so is a simple command with sysctl:
sysctl -w net.inet.ip.forwarding=1
The rest of the instruction, as well as the example pf.conf file (which I used) is can be found in the pf FAQ.
One of the big differences between how pf works compared to Linux's netfilter is how it handles FTP sessions. FTP is a protocol notorious for being un-firewall and un-NAT-friendly, because of the two TCP ports it uses (21 for control and 20 for data).
In Linux, there are special kernel modules for handling FTP sessions through NAT, ip_conntrack_ftp.o and ip_nat_ftp.o. OpenBSD handles this by running an FTP proxy, which you can enable by uncommenting out its entry in /etc/inetd.conf (also detailed in the instructions).
127.0.0.1:8021 stream tcp nowait root /usr/libexec/ftp-proxy ftp-proxy
Another difference between Netfilter and pf is the configuration syntax. I findthe IPFilter/pf-style syntax to be much more readable compared to Netfilter's use of iptables and its rather convoluted syntax.
I've been running my LAN off my OpenBSD system for a few days now, and it's been working great. Given the systems small size (less than 19 inches wide, about 2U, and more shallow than most rack-mount systems), relatively fast processor, easily expanded Etheret through the 3 PCI slots, it would make a great firewall/router. It may very well be that this system, once I'm done with my articles, ends up serving that purpose.
Speaking of hardware, I thought I'd respond to many comments, both in general and in reference to my articles, about the Ultra 5 being a shoddy piece of hardware. They liken it to PC construction, flimsy and plastic and generally undeserving of love and affection.
Actually, its engineering is superior to most PCs. While it's not up the quality of say an old SPARC 5 or a NeXT workstation slab/cube (possibly the most elegant hardware ever produced, I used to own a color turbo slab), it stands heads and shoulders above the quality of your average Dell or Gateway PC. It even tops much of Sun's current top-of-the line hardware, with their superfluous plastic adornments, GNDN (goes nowhere-does nothing) tabs, and razor sharp innards (seriously, the only thing modern Sun servers are missing are rotating knives inside).
The inside is well put together and the design well thought-out, the hard drives are your average IDE fair, holding up well under the rigors of time. The size fits great in a standard 19-inch rack as a 2U system on a shelf, and stacks well. The backend ports are easily accessible and their placement is well thought out.
However, a very ligitimate complaint about the Ultra 5s hardware-wise is its oft-maligned IDE controller, which is notoriously slow and buggy. Now that does indeed suck.
Despite the fact I couldn't seem to make this system a viable database system (with either PostgreSQL or MySQL), OpenBSD turned out to be a very useful system, especially as a firewall.
The combination of excellent documentation, ample pre-compiled binaries, good ports system, and plenty of resources make OpenBSD worthy of serious consideration when exploring operating systems to install on an Ultra 5.
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.