This is about how to make sense of the chains found in the iptables default configuration on a typical home router running OpenWrt (a stripped down Linux for router devices), but which ultimately may not be specific to that particular system.

Let's focus on the INPUT main chain here, and disregard FORWARD and OUTPUT from the same table, as well as PREROUTING and POSTROUTING from the nat table.

Doing an iptables -L -t filter shows a large number of rules. I have rearranged the output below to make it less intimidating, and in an attempt to pinpoint the parts that hamper my understanding.

There are three built-in chains in the filter table, which appear at the top of the output. (I specified -v because I find it less confusing.)

As you can see, I snipped the chains referenced from FORWARD and OUTPUT in order to focus on INPUT. (I could have chosen any of the other two as they are built up in a similiar manner.)

INPUT has a policy of ACCEPT, and it specifies five rules. The first three ones are clear to me. First, accept stuff that is "established" or "related". (For example, accept the response from an HTTP or DNS request I made.) Seconds, accept everything going to the loopback device (127.0.0.1). (This may only come from localhost itself, and I do want that to work. Wouldn't make sense otherwise.) Third, have a synflood protection. (Which protects against a certain kind of attack.)

What is the purpose of input_lan? The other one is probably to accept packets, but it makes me wonder … the policy for INPUT is ACCEPT, so why repeat ACCEPT here?

Now, input from WAN. If you scroll up you can see that some UDP and ICMP stuff is accepted. This is for DHCP and, basically, ping. That much is clear. What is less clear, again, is the partially empty stuff following those rules:

Okay, that is input from WAN (not established or related), and yes, we probably want to reject it, and now there are two kinds of rejection here, one closing the socket (tcp-reset) for TCP connection attempts, and another one via ICMP reply (icmp-port-unreachable) for ICMP messages (think ping).

Finally, here's a list of other chains found in the filter table that aren't referenced from the built-in INPUT chain in the net table. Just for completeness, and to see that they seem to have analogous constructs.

So, well. Sorry for this long post. There were a couple questions along the way. I don't know how to put this in an easier or shorter way. This iptables configuration is not exactly easy to grasp because there are unclear details spread about here and there. Hope you can clarify this and explain the underlying rationale. Thanks for your attention.

4 Answers
4

As far as I know, the firewall is generated from some higher-level configuration file on openwrt. As a lot of different possibilities need to be supported, the actually generate rules are not optimized and can contain therefore unnecessary/unused/empty chains. See OpenWRT's wiki article for more details.

To answer some of your questions

why is "input_rule" empty

As your mentioned it could be a place where the user easily can insert custom rules. Another possibility is that "input" was originally "input_rule" and that "input_rule" is still created for backward compatibility with old scripts.

What is the purpose of input_lan/input_wan?

There you can block traffic from internal hosts on the LAN to the router (for example to protect its configuration interface) or enable access from outside.

The default for INPUT is ACCEPT, so why repeat ACCEPT here?

As you correctly noticed, this is not necessary here. But as zone_lan_REJECT exists, it seems that the script want to be independent from the policy.

This is a clear separation of concerns. The rules for access to and from the WAN should be different from those for the LAN.

The default configuration does not provide accept rules for services not necessarily offered on your network. Typically, most users should offer no services to the Internet. Adding appropriate rules to the appropriate rule sets will enable services. The OpenWrt Web interface should provide the assistance via drop downs.

The Shorewall Basic Two-Interace Firewall documentation should give you a good understanding of what is and should be happening. It is possible to replace the OpenWrt firewall with a Shorewall-lite firewall, but for a basic firewall the existing firewall will do. Some of packages will assume they are working with the default firewall and will take some work if you aren't.

Thanks, Bill. I do understand about the rules being different for LAN and WAN, and about the default configuration being restrictive. That much is clear. What is not so clear is how to work with this iptables chain configuration, where to put what and why. Relying on a web interface, hmm, okay; a bit unsatisfying. - Shorewall: Sounds like a meta-configuration on top of iptables. The docs don't make it entirely clear at first glance, though. - Both OpenWrt and Shorewall have »zones«. Sounds like helper config stuff to avoid redundant rules in chains. - Doc situation could be improved.
–
LumiNov 30 '12 at 15:51

1

@Lumi Shorewall is an tool to build rules for iptables. It uses the same model for rule sets as I see in your description above. I pointed to the documentation as it describes this sort of configuration.
–
BillThorDec 1 '12 at 2:48

By analyzing its output, I deduced that _rule chains are intended for manually-added rules.

The tool is also useful for rule diagnostics: if you reset rule counters, make a network test, then feed it the output with packet counters, you will be able to see which rules were applied to your test traffic.