Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have more of a Cisco background than Linux when it comes to routers. When designing my firewall rules I am used to thinking of in our out ACLs attached to specific interfaces.

I am thinking I can mimic this behavior with IP Tables by having the FORWARD chain jump to a custom chain for each interface.

For example (Default Policies will be DROP):

iptables -N INET_IN
iptables -A FORWARD -i eth0 -j INET_IN
iptables -A INET_IN -m tcp -p tcp --dport 80 -d -j ACCEPT

I will probably end up using stateful inspection but the above is the general idea.

  1. Is there any reason this might cause me trouble or just not work?
  2. If it will work, is this just not the way to do it and I need some Re-education?
share|improve this question
up vote 2 down vote accepted

Ultimately, iptables chain design is a mix of personal preference and utilization of functionality. I come it the exact opposite way as you, for example. I love the iptables "metaphor" and abhor the Cisco ACL metaphor. I like to think about stateful conversations rather than packet flows. (If I have to choose between a Cisco PIX or router w/ the firewall feature-set versus iptables, in terms of pleasure to administer, I'd take iptables any day...)

The phrase "I will probably end up using stateful inspection..." is a bit confusing. Netfilter is a stateful packet filter. You could write a ruleset that works around its "statefulness", but that would be counter productive. Writing rules based on the establishment of connections is also a lot more pleasurable, I've found, than trying to write the necessary rules and "mirror" rules to manage traffic statelessly.

You want a packet to traverse as few chains as possible, and as few rules as possible. Starting your "filter" table chains with -m state --state RELATED,ESTABLISHED -j ACCEPT will allow the stateful inspection engine to push packets for already-established connections thru the rule set without traversing the entire chain.

What you're proposing with the interface-related chains will work just fine, and it's a fairly common practice. If you have a common set of rules that need to apply to every interface I'd put them in the common chain first, then branch to other interface-specific or traffic-type-specific chains from there.

share|improve this answer
The state module as you showed in your example is exactly what I meant by adding "stateful inspection". Using the RELATED,ESTABLISHED at the top and then NEW further down the chain. – Kyle Brandt Jul 20 '10 at 13:07
Ahhh... I see. Yeah-- you definitely want that at the beginning of your chains (though, to be fair, I haven't done a real-world benchmark to see how much it would affect a production system not to have it there). I find myself yearning for iptables when I have to use other firewalls... – Evan Anderson Jul 20 '10 at 13:23

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.