Why I built my own homebrew Linux router

No readers like this yet.
Is Occupy Wall St. really an "open source protest?"


For the last few months, I've been talking a lot about using a bare install of standard Linux distribution as a router. I've written about it at Ars Technica, I did a presentation at Great Wide Open, and I'm doing another one at SouthEast LinuxFest next week. And I have to tell you, the homebrew router has been one of the more controversial topics I've ever written and presented about—some people love the idea, but the ones who don't seem to really, really hate it.

To be fair, setting up your own router from a generic server distro isn't a project for everyone. It certainly isn't user-friendly, both during the build process and once it's finished. While it's not terribly complex, it's definitely arcane, with absolutely no hand holding along the way. If you aren't already very experienced with Linux, you'll likely do a lot of puzzled head scratching (and maybe a little cursing). You won't get a super feature-rich build once you're done, either—unless you go on to do a lot more for your build than I have with mine, you won't have fancy quality of service features, usage graphs, or much of anything else besides a bare-bones (although extremely high performance) router that hands out IP addresses, resolves DNS records, connects to the Internet, and makes packets go where they're supposed to.

I don't have a problem with anybody pointing out any of that. Heck, I point it all out myself, and usually in the first couple of paragraphs. The common complaint that makes me shake my head, though, is, "That's going to be super insecure, and get you rooted, and that's why you should be running a purpose-built router distribution." Wait—what?

OK, let's talk about security for a moment. Security isn't something you tack on after the fact, or build on with a few thousand more lines of code. Security is a mindset, and it's a design—it's something you build in from the foundation. Heightened security is actually the entire reason why I built my own personal bare linux router.

My career forces me to be paranoid about information security, which is why I wanted to build a bare Linux router in the first place. Proprietary router firmware often goes months or years between upgrades—and when it does upgrade, it's more frequently to add some shiny to the UI—more than likely introducing more bugs—than to fix security problems. Open source firmware isn't really in much better territory. DD-WRT is one of the most popular, and while it has a new (and incredibly bug-ridden) beta release every few weeks, the project hasn't had a stable release in eight years. Eight years! pfSense is pretty much the darling of the industry, and rightly so—but it's still a big, complex pile of moving parts with web interface and pretty graphs and bits and bobs to toggle and you're never going to truly know everything that it's doing—you click the boxes in the web UI and you assume it's doing what you told it to, which is already pretty far abstracted from the reality of the underlying configs. It also goes months (or longer) between firmware updates being made available, with (again) no real guarantee that an update won't change major parts of the UI and the capabilities, not just fix bugs.

For a lot of people—and businesses, don't get me wrong—that's perfectly fine. For my own personal network, it's no longer good enough. I wanted something minimal, in which I knew every inch of the actual configurations because I'd written it myself. And I wanted truly frequent security updates, with the kind of quality assurance and testing that a major distribution brings to the table. The little specialty router distros can't help but be also-rans at this.

And that's where my homebrew router came in. No, it's not "less secure" than a router distro—it's got far, far fewer moving parts, and I know all of them well. Every single piece of it, aside from my actual config files, gets automatic security updates on a daily basis. If there's a minor security issue in dhcpd, it's not going to have its patch sit in a queue until "there's enough stuff to bother" with a full firmware upgrade release. It's going to go out and get patched automatically by the unattended-upgrades service right now, when it should.

I don't have to worry about if I accidentally exposed the web interface to the outside world by forgetting to click the right check box—there is no web interface. I similarly don't have to worry about whether a bug in the web interface does something similar despite my having checked a box—because there is no checkbox, the configurations I'm doing are the real configurations to the actual services, not an abstracted and simplified version that must be translated by a few thousand lines of PHP code that get orders of magnitude fewer eyeballs reviewing them.

So this brings us back around to the topic of who a homebrew router is or isn't right for. Is it right for a busy admin who isn't already intimately familiar with Linux networking at the command line level, including dhcpd, iptables, and bind? Probably not—they don't have time to deal with all that. Is it right for a home user who isn't a hobbyist interested in those things? Again, probably not—they'll get frustrated with the arcane (though ultimately simple) nature of the configs.

A homebrew Linux router is right for a hobbyist or junior sysadmin who is genuinely interested in how these things work under the hood, though. Setting up and managing one will teach you a lot. It's also a pretty good fit for a veteran sysadmin who already understands the majority of the systems and only has to brush up on a thing or two to get comfortable with it—the raw performance is just plain jaw-dropping, and the simple nature of the system will leave that veteran sysadmin free to manage it and back it up in the ways they're already very comfortable with. And finally, it's perfect for the incredibly tin-foil-hatted types (also, unfortunately, like me these days) since its stripped-down nature lets them be absolutely certain they understand what it is, and isn't, doing and plan around that accordingly when they're mapping out their security setup.

If you're an interested hobbyist or sysadmin who thinks this sounds like the kind of project you'd like to get your teeth into—or even the kind who thinks this sounds completely batty, but might be fun to think about for an hour—come to SouthEast LinuxFest this year in Charlotte, N.C.! The event runs June 10-12, and my talk should be on Saturday, June 11, from 9-10 a.m.

Jim Salter
I'm a mercenary systems administrator located in Columbia, SC. My first real hands-on experience with open source software was running Apache on FreeBSD webservers in the late 90s and early 2000s. Since then, I moved on to Samba, BIND, qmail, postfix, and anything and everything else that grabbed my attention.


Great article, Jim! It's well-timed for me. I've actively avoided building my own router for many years because I'd rather have something that I don't need to maintain. I could manage it, but I spend enough time arguing with computers at work, I don't necessarily want to do it at home (or at least I want to do it on my own terms). But I've grown increasingly frustrated with my router's buggy DD-WRT build lately, and your post is one more nudge toward biting the bullet and making my own.

Great article Jim. although I use IPFire; I understand why you went with the home-brew way. Simple and elegant in it's own way. You know that you know type of deal. I like it!

Thanks Jim. I 've been running DD-WRT for several months now and after reading your article maybe I should re-think that. I've got some spare hardware. This is a timely topic and I wish I was going to be at the Southeast Linux Fest to hear your presentation. You've given me some things to think about. What flavor or Linux do you use?

I personally use Ubuntu, Don - partly because I prefer Debian package management, and partly because Ubuntu offers LTS versions with explicit support cycles. I like knowing that 14.04 LTS came out in April of 2014, will expire in April of 2019, which means that in April of 2016 I can choose whether or not to look at an upgrade to 16.04 LTS, and if I choose not to, in April of 2018 I have one year during which I NEED to migrate to 18.04 LTS.

In reply to by Don Watkins

Bravo (clap hands).
I built my first linux router/home server in 1997 with slackware. At the time redhat wasn't keeping up with updates and I could use slackware build scripts to compile updates and patches. I used arbitration to allow me and my brother to share a 56K modem. It wasn't pretty but hey at least both of us could browse the internet at the same time. As I upgraded I no longer needed the arbitration and Fedora was broken off from redhat and was upgrading faster then I could keep up with build scripts. I switched to fedora and use my server as a virtual environment and a DVR(Mythtv). I bought a decent i3 that uses the graphics from the CPU with 10Gigs of ram in 2010 and it has worked reasonably well. I raided the system drives and have a drive for the recordings. If I could lower the power consumption and keep the vm's and the DVR is my only balancing act that I'm afraid of messing with. But, BIND, dhcpd and iptables (implimented with firewalld whole new learning experience). I also implimented ipv6 natting for kicks and giggles. And recently started implementing AD with samba coming soon next year to fedora. Knowing iptables is by far the most useful (firewalld is just a way to set it up and can be used to set panic modes automatically)

I would highly recommend if you're running your own to install something like ossec, doesn't need to be that but some kind of solution that deals to attacks and responds dynamically with block or temporary drop.

Not even running on a "generic server distro", for years I ran a router that I built on top of Linux From Scratch (a machine where I compiled everything manually based on instructions from the book) and it ran fine and never failed, but was a pain to administer or do anything fancy. For my next router I switched to pfSense for the convenience and ease of updating.

Go check BSDRP... it is made for anyone sharing your views. And it is a beast as far as performance is concerned.

Excellent article. I got frustrated long ago and did something similar on an old Fedora Core release 4 box. I was amazed at how functional it was. Been running it for about 10 years. However, I will need to break down and upgrade the thing. As it's kind of a AC power hog and uses standard IDE drives. Life span of IDE drives being what it is, It's time. Redoing the setup will feel like the death of a beloved pet. The article was great as I can see where I need to go. Great work guys! Thanks for the motivation.

Mine is a bit of a power hog also but since I use it as a dvr and a home server I'm not sure how much better it would be to upgrade. Granted mine is much newer than yours but I don't want to loose functionality in upgrading efficency.

In reply to by rwilcher

My homebrew runs at 9.2W, as measured by plugging it into a Kill-A-Watr.

In reply to by Jeff Sadowski (not verified)

I also too decided to build my own. i also bought a Lamobo R1 as I sure do not trust the Intel architecture. I run a minimal Debian 8 system with a 4.5.5 kernel, where I killed most of the services including video and wifi (another machine, an openwrt severely modified gives me wifi). I ran there my VPN IPsec server+asterisk+firewall+NAT+DHCP+a DNS server with RPZ that cuts malware and adverts. I also talk dnscrypt to the outside so my DNS requests cannot be logged/modified in-transit. I also run tor services once in a while on it. I do not expose ANY service to the outside except IPsec. Even to login by SSH or to use the voIP services, I have to get in via the VPN. I am pretty happy with the setup, and all updates are pretty done.

If you want software that is strong and secure, maybe you could be interested in two Ada-based projects

* Ironsides (https://news.ycombinator.com/item?id=7553019) an " authoritative/recursive DNS server pair" formally verified using SPARK (a tool for formally checking Ada programs, see http://www.spark-2014.org/)

* ADHCP (https://www.codelabs.ch/adhcp/), a DHCP implementation in Ada

To be honest, I never used those tools myself, nor I do not know how much they are actively maintained, but usually the average Ada program is much less buggy than the average C program and usually bugs are readily caught by the checks that the language inserts by default (for example, you cannot have a "buffer overflow" that smashes silently the stack). According to the web site, Ironsides should be formally proved to be free from buffer overflows, uninitialized variables and other amenities.

you are the man!

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.