Automatically restore firewall filter rules


With the manual version, you use the iptables commands and tools. The iptables-save command reads the current firewall rules. Because the program sends them to standard output, you need to redirect the output to a file by using the (>) redirection operator (Listing 2). This file has a specific, compact format.

Listing 2

iptables Manual Method


You can restore these rules later with the command iptables-restore (Listing 2, last line). This approach is simple and clear-cut, but still not automated. However, you can manage that task with the variations that follow.


Runlevels contain shell scripts that run with a system runlevel change. To load the previously stored firewall rules, you need to create an appropriate shell script. In it, you can either call iptables-restore or create a separate call to iptables in the desired order for each individual rule.

The variant presented here is far more customized. It involves expanding the entries for the network interfaces in the /etc/network/interfaces file. The entries allow you to specify a script or command that runs when the system activates or disables a network interface (Listing 3).

Listing 3



The first command in line 3 is specified after the keyword pre-up and executes the command before activating the interface. The post-down statement in line 4 refers to the time after disabling the interface. Therefore, the firewall only processes certain rules when a particular interface is switched on.

Resourceful Debian developers also identified the problem and devised a solution, which they dubbed iptables-persistent [5]. It has been included since Debian 5 "squeeze" and combines the variants featured in Listing 3.

For this to happen, iptables-persistent creates two files – /etc/iptables/rules.v4 for IPv4 and /etc/iptables/rules.v6 for IPv6 – and stores the current firewall rules during package configuration. Additionally, it creates a suitable init script named /etc/init.d/netfilter-persistent, which you can call via service netfilter with the usual switches: start, stop, reload, and restart.

Future Useful Information

In the context of iptables, several small programs facilitate everyday admin life. They include iptables-apply and iptables-xml, both of which are part of iptables, as well as iptables-converter.

The iptables-apply shell script helps you test firewall rules remotely. It allows you to roll back rule changes if they would take down the current connection.

To do this, the script asks whether the changes to the rules are okay. If you do not respond within a certain period of time, it rolls back the changes. This reduces the risk that you lock yourself out when changing the firewall rules, although you still have the option of communication via the serial interface, but only if the remote computer is set up for it, because the firewall rules do not take it into consideration under normal circumstances.

Access would also be possible via a KVM switch, which acts as a toggle switch that connects a set of devices (keyboard, video, mouse) to more than one computer. In this way, you can control multiple computers with one keyboard, mouse, and monitor.

The iptables-xml script contains firewall rules in XML format. Several graphical tools for firewalls understand and process this format. Figure 1 shows an example of an XML file generated by this tool.

Figure 1: The iptables-xml tool converts iptables rules to an XML structure that you can reuse in other applications.

The iptables-converter program is useful, as well. It converts iptables statements to the format that iptables-save and iptables-restore use. Thus, you can convert existing shell scripts with sequences of iptables statements directly to the required format. The graphical fwbuilder (Firewall Builder) tool [6] also reads the files and generates customized package checks (Figure 2).

Figure 2: Graphically editing rules in Firewall Builder. You can see the imported rules created by iptables-converter.


The author thanks Werner Heuser and Axel Beckert for their criticism and suggestions in the run-up to this article.

The Author

Frank Hofmann ( works in Berlin, Germany for Büro 2.0, an open source expert network, as a service provider specializing in printing and layout. Since 2008 he has also coordinated the regional meeting of the Berlin-Brandenburg region Linux usergroup. He is the co-author of the Debian package management book (

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • nftables

    Filter rules for firewalls can be tricky. As the successor to iptables, nftables simplifies the process of creating and maintaining firewall rules.

  • Nftables

    The nftables firewall utility offers a simpler and more consistent approach for managing firewalls in Linux.

  • Firewall Logfile Analyzers

    Netfilter firewalls create highly detailed logfiles that nobody really wants to inspectmanually. Logfile analysis tools like IPtables Log Analyzer,Wallfire Wflogs,and FWlogwatch help administrators keep track of developments and filter for importantmessages.

  • FAQ

    Nftables promises to be the future of Linux firewalls. Meet iptables' replacement.

  • KTools: KMyFirewall

    Linux has a fantastic selection of firewalls for securing stand-alone computers or whole networks. Although you can use IPTables to set up a firewall, the configuration is often the most difficult step. KMyFirewall offers a powerful, user-friendly, GUI-based approach.

comments powered by Disqus