iptables, the standard Linux firewall, does not save rules between reboots. You have to take care of this yourself. There are many ways to do this. What is the canonical way to do this? What are best practices?

I'll answer with my own solution, but I'm interested in other / better solutions.


Here are some example rules. Save them to /etc/iptables.rules

# Generated by iptables-save v1.3.6 on Wed Oct 24 17:07:29 2007
:INPUT ACCEPT [89458:132056082]
:OUTPUT ACCEPT [263904:15667452]
-A INPUT -i lo -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT 
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7 
# Completed on Wed Oct 24 17:07:29 2007

add this line at the end of /etc/network/interfaces

pre-up iptables-restore < /etc/iptables.rules
  • 1
    I'll point out that this is Ubuntu-specific. For Red Hat and Fedora variants, you'll be looking at /etc/sysconfig/iptables instead. – esm May 15 '09 at 14:07
  • You mean instead of /etc/iptables.rules? That is not determined by Ubuntu, I chose that myself. – amarillion May 15 '09 at 19:22
  • 4
    I was referring to the addition to /etc/network/interfaces; my apologies, I should have been more clear. Fedora and RHEL have an initscript (cleverly named "iptables" ;) that, if enabled, essentially does an iptables-restore of /etc/sysconfig/iptables. – esm May 16 '09 at 0:05

We use alot of iptables rules, so in order to ease administration we do the following:

  • Rules are all called from scripts - scripts are called from /etc/init.d/firewall (custom script)
  • A file of server names / network names (ip address variables) is kept, and included in every iptables script for consistency.
  • separate scripts are kept for each subnet (ie. private / DMZ / VPN, etc) to make things easier to find. Rules that belong in 2 scripts (such as those restricting communication b/w private and DMZ) are put in the more "secure" network's script
  • wherever possible, loops and nested loops are used to keep the scripts as short as possible.
  • every new rule or change is documented with comments preceding the appropriate section of the script.

I don't know if this is the best way to do this, but it has worked well for us.


While it is true this is environment and platform dependent, I have seen two good approaches, depending on the platform:

  • RHEL / CentOS: store all rules in a single /etc/sysconfig/iptables file which is read in by the iptables startup script.

  • Debian/Ubuntu: store all rules in separate service-specific files in /etc/iptables.d/ directory. For example, /etc/iptables.d/port_http, /etc/iptables.d/port_dns, where port_service maps to a service name in /etc/services.

In either case, the file or files are managed by a configuration tool like Chef or Puppet, and read in by the 'master' startup script for iptables that runs at boot time.

  • 2
    I would be real careful with your naming in your Debian/Ubuntu example. This is the kind of place where you want to prefix your rule names with 00, 04, 22, etc. There's a lot of iptables rules that are order dependent, and if you load them in the wrong order, you're going to have broken stuff. I'd suggest storing them in a single file unless you really know what you're doing. – Christopher Cashell Jun 4 '09 at 20:20

In addition to iptables-save (and iptables-restore), complicated firewall schemes are better handled with dedicated programs. For example, we've used shorewall ("iptables made easy") to configure iptables.

Simpler tools are also available, like firestarter and kmyfirewall.

  • 6
    I disagree. The simple cases can easily be handled with the dedicated programs, but for a complex rule, I can't think of anything clearer than iptables (clearer meaning non-ambiguous, not necessary beginner friendly) – Mikeage May 11 '09 at 12:11
  • 2
    Depends on why you want to simplify the rules. I think the iptables.rules file can be perfectly readable. It's important to take advantage of the comment arguments to make sense of it all. – spoulson May 11 '09 at 12:25
  • I disagree with your disagreement. If you focus on making your iptables commands readable you won't order them or use chains so the rules are as efficient as they could be. – Zoredache May 11 '09 at 16:30
  • 1
    Zoredache - I think Mikeage is more right than wrong here. iptables rules can be pretty unambiguous, even though they would be (for a less skilled person such as myself) hard to read. I don't think Mikeage was was going for easy to read. – Michael Kohne May 15 '09 at 10:59

This is dependent on the distribution you use. Some distributions especially those based off a Red Hat distribution keep the iptables rules automatically but in there own special directory. I'm most familiar with RHEL and the iptables rules can be found at /etc/sysconfig/iptables. Becoming familiar with iptables rules syntax can be tricky at first but is quite easy once you get the hang of it.

The netfilter website has a lot of documentation on iptables including some introductions. If your up for reading a bit you can find a lot of good information here: http://www.netfilter.org/documentation/

  • On redhat you may also want to keep /etc/sysconfig/system-config-securitylevel up to date. This is where system-config-securitylevel-tui gets its rules from at startup.If you don't keep /etc/sysconfig/system-config-securitylevel up to date, if someone runs system-config-securitylevel-tui you may lose the rules stored in /etc/sysconfig/iptables. – Jason Tan May 30 '09 at 16:32

This question is very close to being a dup of 4934 and it is related to 397.

I use firehol combined with a web interface that I developed to manage the configuration file.

I really like firehol, it provides a simpler syntax then using iptables directly.

  • You can use the firehol debug command to exactly what iptables commands are generated
  • If you have an error in your configuration and you start the firewall, firehol detects the error and reverts to the previous state.
  • Firehol has a 'try' command which you can use to start the firewall remotely, if your changes kill your connection, firehol will revert to the previous state, if you didn't kill your connection then it will ask you to confirm the change.
  • Firehol has a large set of services pre-defined so you don't have to remember exactly what ports you have to have what ports to open for some obscure protocol.

We use a custom init-script, of course. I can use for-loops to iterate over a list of ports, parse other config files like the vpn-users, etc. Excellent!

And iptables-restore is surely the most "canonical" way of saving it.

What I want to add:

Please note that current version of iptables will for every single invokation ask the kernel to give it back the full list of chains. Then it will make the one change you ask it to do. Then it will upload the list again.

This is slow (O(n^2)), for us it needs 5 seconds which is too long ;-)

If you use iptables-restore, it all goes through in one quick operation.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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