[SOLVED] Unexpected service control behavior for iptables?

pgoetz · 2014-07-17 15:31:59

I've been experimenting with iptables and was somewhat surprised by the behavior of

# systemctl reload iptables

and

# iptables-restore < /etc/iptables/empty.rules

I understand what is happening, but am wondering if anyone can explain why. In the case of iptables-restore, I want to call this a bug, based on the man page.

If I start the system with an empty /etc/iptables/iptables.rules file, iptables starts, but reports no rules:

# iptables-save
#

I'm not sure what the state of the system is under these conditions, but it doesn't, for example, prevent remote connections or anything like this. I can then load some basic rules

# iptables-restore < /etc/iptables/some-rules.rules

or

sh iptables.rules

and if I subsequently stop and start or reload iptables.service using systemctl it appears that all the default policies are preserved. Here is an example after reboot, with the iptables service enabled and empty /etc/iptables/iptables.rules file:

[root@ibis ~]# iptables-save
[root@ibis ~]#
[root@ibis ~]# iptables-restore < /etc/iptables/empty.rules
[root@ibis ~]# iptables-save
# Generated by iptables-save v1.4.21 on Thu Jul 17 10:11:04 2014
*filter
:INPUT ACCEPT [8:836]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [4:544]
COMMIT
# Completed on Thu Jul 17 10:11:04 2014
[root@ibis ~]# systemctl stop iptables
[root@ibis ~]# systemctl start iptables
[root@ibis ~]# iptables-save
# Generated by iptables-save v1.4.21 on Thu Jul 17 10:11:54 2014
*filter
:INPUT ACCEPT [65:7437]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [34:4024]
COMMIT
# Completed on Thu Jul 17 10:11:54 2014
[root@ibis ~]#

If I have rules for other tables loaded (e.g. nat), the default policies for these tables appear to be preserved as well. This seems unintuitive to me. When I stop and start or reload a system service, my epectation is that it will load just as if I had rebooted the system. Is there a reason for preserving default policies between iptables.service restarts?

The behavior of iptables-restore is even less intuitive. From the man page one would expect that by default all rules in all tables are flushed when iptables-restore is run. This isn't how it works.

# touch empty-file
# iptables-restore < empty-file

leaves all the existing rules in place, and if I have rules in the nat and filter tables and run

iptables-restore < /etc/iptables/empty.rules

Then the filter table rules are reset to the default policies in /etc/iptables/empty.rules, but all the nat table rules are left unchanged. I have to explicitly set replacement nat table default policy in the replacement rules file in order to erase the existing (nat) chains/rules.

Neither of these is a big deal, but does add to the confusion until one figures out what is going on.

Last edited by pgoetz (2014-07-17 19:38:42)

lahwaacz · 2014-07-17 16:05:39

There is always a default behaviour, regardless of the output of iptables-save, which includes only initialized tables in its output. To fully revert to the state after reboot, you would have to unload the respective kernel modules: iptable_<table name> (e.g. iptable_filter etc.)

Similarly, iptables-save operates only on the tables specified in the input (and unless --noflush is given, the table is flushed first). IMO this is much safer than the alternative...

pgoetz · 2014-07-17 16:15:20

lahwaacz wrote:

Similarly, iptables-save operates only on the tables specified in the input (and unless --noflush is given, the table is flushed first). IMO this is much safer than the alternative...

I think you mean iptables-restore. Sure, I can see that this design is safer, but then the iptables-restore man page needs to specify that this is the behavior (i.e. only tables addressed in the replacement rules files are flushed and updated).

pgoetz · 2014-07-17 16:28:07

lahwaacz wrote:

To fully revert to the state after reboot, you would have to unload the respective kernel modules: iptable_<table name> (e.g. iptable_filter etc.)

Thanks. This provides the missing detail that systemd/systemctl is not unloading the kernel modules on

systemctl stop iptables

I'm not sure if this is optimal. Why wouldn't you also want to unload the kernel modules if they're not in use any more?

lahwaacz · 2014-07-17 16:31:09

Yes, I meant iptables-restore. Sorry for the typo...

lahwaacz · 2014-07-17 16:51:51

pgoetz wrote:

Why wouldn't you also want to unload the kernel modules if they're not in use any more?

The Linux kernel supports automatic module loading, but I don't really know if automatic unloading is also available and possibly how it works.

Arch Linux

#1 2014-07-17 15:31:59

[SOLVED] Unexpected service control behavior for iptables?

#2 2014-07-17 16:05:39

Re: [SOLVED] Unexpected service control behavior for iptables?

#3 2014-07-17 16:15:20

Re: [SOLVED] Unexpected service control behavior for iptables?

#4 2014-07-17 16:28:07

Re: [SOLVED] Unexpected service control behavior for iptables?

#5 2014-07-17 16:31:09

Re: [SOLVED] Unexpected service control behavior for iptables?

#6 2014-07-17 16:51:51

Re: [SOLVED] Unexpected service control behavior for iptables?

Board footer