systemd iptables conflict

[K Yzxr]

On ArchLinux (and possibly other distros, haven't tested beyond Arch), iptables was no longer being started upon reboot, as explained in this thread:

https://bbs.archlinux.org/viewtopic.php?pid=1701189#p1701189

The problem was traced back to the fact iptables was changed from being named 'iptables.target' to now being named 'iptables.service'. Without the right dependency declared, sshguard doesn't properly wait for iptables to be initialized and so users were seeing that iptables would fail to load on boot, but could be loaded fine manually after kernel startup was finished.

Adding the line 'After=iptables.service' to the systemd [Unit] section resolves the issue.

[Daniel Aleksandersen]

The Unit file is only an example. Do you happen to know whether this is an upstream or a Arch specific change?

[parchd]

It looks like iptables upstream doesn't provide a systemd service, Arch adds it in packaging. From what I can see, debian doesn't add one at all, and neither does Gentoo (see https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=746c559118d7b3c95a1f78d4d7730d9ba4c8e4f6). I guess the question is, what other distros do provide a systemd unit or target for iptables?

[Daniel Aleksandersen]

Then the current example file serves it’s job. It’s not being automatically installed (exactly because of issues like this) and is only meant as an example for downstream maintainers and users.