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.
So far I've covered installing OpenWrt, recompiling a new OpenWrt image with iptables' bridging functionality enabled and configuring networking using OpenWrt's uci (Unified Configuration Interface) command.
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.
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”:
net.bridge.bridge-nf-call-arptables=0 net.bridge.bridge-nf-call-ip6tables=0 net.bridge.bridge-nf-call-iptables=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:
root@sugartongs:/etc/config# uci set network.eth0_1=switch_vlan root@sugartongs:/etc/config# uci set network.eth0_1.device="eth0" root@sugartongs:/etc/config# uci set network.eth0_1.vlan="1" root@sugartongs:/etc/config# uci set network.eth0_1.ports="4 5"
(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:
root@sugartongs:/etc/config# uci set ↪network.lan.ifname="eth0.0 eth0.1"
And finally, I list my new network configuration to make sure everything's correct, commit the changes and reboot:
root@sugartongs:/etc/config# uci show network root@sugartongs:/etc/config# uci commit root@sugartongs:/etc/config# reboot
Listing 1 shows what the resulting /etc/config/network file looks like.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released