Building a Transparent Firewall with Linux, Part IV

I've been writing a multipart series on building a transparent (bridging)
firewall using Linux. Specifically, I'm using the distribution OpenWrt
running on a Linksys WRT54GL broadband router, a hardware choice driven
mainly by my curiosity about the WRT54GL's built-in five-port Ethernet
switch and its ability to run OpenWrt Linux.

This month, I review the example network topology and finally begin
configuring iptables, the heart of the whole undertaking. Before I do
so, however, there are a few OpenWrt housecleaning tasks to get out of
the way: tweaking the kernel and network configurations, and disabling
OpenWrt's native firewall system.

OpenWrt Performance as a Transparent Firewall

In researching this article, I had a nasty surprise. Although in the
past I had seen articles and how-tos on making transparent firewalls
with OpenWrt, this mode of operation is not supported by default in the
Kamikaze and Backfire releases. Reportedly, running iptables in bridging
mode under OpenWrt reduces overall system performance by a whopping 40%!

I proceeded writing this series anyhow, because I wanted to see for
myself just how big an effect this is, and it seemed to me that
the series still would be useful just for the sake of explaining how
to install and use OpenWrt, and for explaining how to write iptables
rules for transparent firewalls. However, at several points, I've
written of my doubts as to the example OpenWrt/WRT54GL's suitability
for high-bandwidth/high-availability settings.

Also, hopefully without sounding too grandiose, I hoped that by
spurring greater interest in OpenWrt's flawed capability, I might
encourage someone to get to the bottom of why OpenWrt performance
plunges when run with iptables in bridging mode. Surely there's a reason
that this not terribly new kernel feature is problematic in OpenWrt!

I say all this because I want to be clear that although transparent Linux
firewalls in general constitute an interesting and useful technology,
the specific combination of a $65 broadband router plus OpenWrt running
in this mode is probably suitable only in a home or lab setting,
not for any situation where you need to move large volumes of packets
very quickly and very reliably (which is hopefully unnecessary for me
to say, given that the WRT54GL is marketed to home users in the first
place). I say it also so you understand why you have to go through the
hoops of recompiling the OpenWrt image and editing /etc/sysctl.conf to
get iptables bridging working in OpenWrt.

Kernel Parameters and a Network Tweak

Recompiling the OpenWrt image with CONFIG_BRIDGE_NETFILTER=y set in the
Linux kernel is the first of two steps in enabling iptables' bridging
mode in OpenWrt. The second step is either to delete the following
parameters in /etc/sysctl.conf or set each of them to “1”
rather than “0”:

In addition, I need to correct an error I made in the OpenWrt network
configuration I showed you last time. You may recall that I changed
OpenWrt's default configuration, such that all Ethernet ports were
assigned to a single VLAN and bridge.

But possibly due to the way the Linux kernel interacts with the bridge
hardware on my Linksys WRT54GL, with that configuration, I find that
iptables ignores inter-VLAN traffic—that is, traffic between ports
on the same VLAN. In order to get iptables to work properly on this
hardware and on OpenWrt, I actually need two VLANs: one corresponding
to my “uplink” (the Ethernet port connected to the outside world) and my
“LAN” (everything else). These two VLANs, however, are still associated
with the same bridge interface.

To create a separate VLAN for my uplink port, which is my WRT54GL's
“WAN” port (or “port 4” to OpenWrt), I issue these commands on my router:

(Port 5, you'll recall, is a virtual port associated with the kernel,
that must be included in all “ports” statements in OpenWrt network
configurations, which is why our “...ports” statement is set
to “4 5”
rather than just “4”.)

To remove the WAN port from the other VLAN (eth0_0) I set up last time,
I use this command:

root@sugartongs:/etc/config# uci set network.eth0_0.ports="0 1 2 3 5"

Next, in my bridge configuration, for the network I named
“lan”, I
associate both VLANs with the bridge:

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.