DEBRIS.COMgood for a laugh, or possibly an aneurysm

Thursday, July 21st, 2005

Mini-ITX: software… finally, a firewall

Over two years ago I started building a new firewall. I foreshadowed the agony to come, in my first report: “The software is taking longer to configure… more on that later.”

It’s finally “later.”

I’d started, I think, with RedHat 8. I got sidetracked trying to make the machine work as a print server. I dislike futzing with hardware so much that I can only stand it in small doses, so I took a couple months off, by which time RedHat 9 came out. I kissed off the print-server failure and did a fresh install.

By focusing on setting the machine up as a gateway and firewall, I was able to quickly finish the configuration. But: within five minutes of booting up, the machine lost the network. A long download would pause and never restart. Outbound pings and traceroutes all failed (although inbound traffic seemed to work fine).

Other Mini-ITX owners had reported similar problems, but their solutions didn’t work for me: no amount of kernel switches or BIOS settings would enable the box to stay online for more than 5 minutes. I spent hours on APIC, ACPI, network driver debugging, network interface duplex negotiation, etc. I did dozens, literally dozens of kernel compiles. It sucked unholy penguin butt.

I asked my systems admin to take a look at the box. For him, on his home network, the machine worked fine. Argh.

I replaced network cables. I tried different ports on the switch. I even replaced the switch. No dice.

I upgraded to Fedora Core 1. Still no dice. Fedora Core 2? Ditto. Meanwhile, I’d put another two years of service on the old freight train of a 486 that I’d been using as a firewall since approximately 1975. All the time, I was thinking “what will I do if it dies?”

Finally I gave up on Linux. I’d wanted, in a (very) small way, to learn more about FreeBSD, so I tried that.

FreeBSD InsideEureka! Networking didn’t die. It was gratifying to have fixed the problem, but perhaps even more gratifying to prove that the machine didn’t have a hardware failure after all.

The next step was to learn ipfilter. Ugh, yet another obscure syntax for encoding access rules. ipchains was pretty bad, but at least it was familiar. Was I up for another round? Not really. So the fresh FreeBSD install got dusty for a few months, because except for the fact that it sounded like the test grounds at the Boeing factory, my old 486 firewall was working just fine.

Until it died, it worked just fine. On July 4, the NIC seized up. I could just make out the death rattle over the fan noise.

Configuring the ITX machine for NAT and firewalling was surprisingly easy, given this step-by-step recipe: How to Build a FreeBSD-STABLE Firewall with IPFILTER.

I needed to add a second NIC, because unlike Linux, FreeBSD isn’t able to alias a private IP (e.g. 192.168.1.1) to the same NIC used for the public IP and keep them both logically separate. The 2-NIC design is more secure anyway, and although it seemed possible that the additional hardware would max out the small power supply that came with my mini-itx case (this is one of the possible explanations for networking malfunctions), it hasn’t yet been a problem, but check back tomorrow.

In answer to the question, “why not just buy a $60 hardware firewall from CompUSA,” I’d say, first, that I’d rather eat a can of corn smut then give Comp USA another nickel, and second, that I run a DNS server and mail services on this machine. And maybe a print server too, given a couple more years to configure it.


Tags:
posted to channel: Personal
updated: 2005-07-23 04:13:57

follow recordinghacks
at http://twitter.com


Search this site



Carbon neutral for 2007.