Linux – Cisco ACL Style Rules for IP Tables on a Linux Router

ciscoiptableslinuxnetworkingrouter

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 12.12.12.12 -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?

Best Answer

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.

Related Topic