iptables / ip6tables on desktop with systemd - won't start

[gordonp]

Hi -

I have two desktop machines, both running systemd (and dozens of others with Gentoo / RC init, but they're not the problem). On both these systemd desktkops, I found that iptables / ip6tables won't start Here is what I see when I query about the status:

Code: Select all

# systemctl status iptables
● iptables.service - Store and restore iptables firewall rules
   Loaded: error (Reason: Invalid argument)
   Active: failed (Result: exit-code) since Mon 2016-10-31 14:13:46 PDT; 36min ago
 Main PID: 29236 (code=exited, status=203/EXEC)

Oct 31 14:13:46 pluto systemd[1]: Starting Packet Filtering Framework...
Oct 31 14:13:46 pluto systemd[1]: iptables.service: Main process exited, code=exited, status=203/EXEC
Oct 31 14:13:46 pluto systemd[1]: Failed to start Packet Filtering Framework.
Oct 31 14:13:46 pluto systemd[1]: iptables.service: Unit entered failed state.
Oct 31 14:13:46 pluto systemd[1]: iptables.service: Failed with result 'exit-code'.
Oct 31 14:13:54 pluto systemd[1]: iptables.service: Service lacks both ExecStart= and ExecStop= setting. Refusing.
Oct 31 14:38:09 pluto systemd[1]: iptables.service: Service lacks both ExecStart= and ExecStop= setting. Refusing.
Oct 31 14:41:03 pluto systemd[1]: iptables.service: Service lacks both ExecStart= and ExecStop= setting. Refusing.
Oct 31 14:41:15 pluto systemd[1]: iptables.service: Service lacks both ExecStart= and ExecStop= setting. Refusing.
pluto system # systemctl status ip6tables
● ip6tables.service - Store and restore ip6tables firewall rules
   Loaded: error (Reason: Invalid argument)
   Active: inactive (dead)

and for ip6tables, a little less wordy but about the same:

Code: Select all

# systemctl status ip6tables
● ip6tables.service - Store and restore ip6tables firewall rules
   Loaded: error (Reason: Invalid argument)
   Active: inactive (dead)

Oct 31 14:50:22 pluto systemd[1]: ip6tables.service: Service lacks both ExecStart= and ExecStop= setting. Refusing.
Oct 31 14:52:29 pluto systemd[1]: ip6tables.service: Service lacks both ExecStart= and ExecStop= setting. Refusing.

I've re-emerged both systemd and iptables. iptables is quite happy if I run it manually, as is ip6tables (by "happy" I mean that a list of rules is applied without complaint, and 'ip[6]tables -L -n' shows that my intended rules appear. Versions that I've re-merged are:

Code: Select all

[ebuild   R    ] sys-apps/systemd-226-r2:0/2::gentoo  USE="acl kdbus kmod lz4 pam policykit seccomp ssl (-apparmor) -audit -cryptsetup -curl -elfutils -gcrypt -gnuefi -http -idn -importd -lzma -nat -qrcode (-selinux) -sysv-utils {-test} -vanilla -xkb" ABI_X86="32 (64) (-x32)" 0 KiB
[ebuild   R    ] net-firewall/iptables-1.4.21-r1::gentoo  USE="conntrack ipv6 -netlink -static-libs" 0 KiB

I have browsed /usr/lib64/systemd/system and looked at both iptables.service and ip6tables.service. I've even deleted these and allowed the re-emerge to re-create them, but to no avail Both are bone-stock, and similar to each other:

Code: Select all

# cat iptables.service
[Unit]
Description=Store and restore iptables firewall rules

[Install]
Also=iptables-store.service
Also=iptables-restore.service

I've disabled and re-enabled the service, but that hasn't helped.

My Profile:

Code: Select all

default/linux/amd64/13.0/desktop/gnome/systemd *

What have I missed? What should I look at, to further figure out what's wrong?

Thank-you!

[eccerr0r]

Ok this is weird.

You should be able to just

Code: Select all

# systemctl enable iptables
# systemctl enable ip6tables

and next shutdowns it should save your settings, and next boots it will reload them.

Did you see this when you enabled them?

Code: Select all

Created symlink from /etc/systemd/system/shutdown.target.wants/iptables-store.service to /usr/lib64/systemd/system/iptables-store.service.
Created symlink from /etc/systemd/system/basic.target.wants/iptables-restore.service to /usr/lib64/systemd/system/iptables-restore.service.

It's actually iptables-store.service and iptables-restore.service that does the dirty work.

[gordonp]

Hi, @eccerr0r:

Yes, I saw/see exactly what you posted:

Code: Select all

# systemctl enable iptables
Created symlink from /etc/systemd/system/shutdown.target.wants/iptables-store.service to /usr/lib64/systemd/system/iptables-store.service.
Created symlink from /etc/systemd/system/basic.target.wants/iptables-restore.service to /usr/lib64/systemd/system/iptables-restore.service.

# systemctl enable ip6tables
Created symlink from /etc/systemd/system/shutdown.target.wants/ip6tables-store.service to /usr/lib64/systemd/system/ip6tables-store.service.
Created symlink from /etc/systemd/system/basic.target.wants/ip6tables-restore.service to /usr/lib64/systemd/system/ip6tables-restore.service.

But still no luck; at the console I still see failure:

Code: Select all

# systemctl restart iptables
Failed to restart iptables.service: Unit iptables.service failed to load: Invalid argument. See system logs and 'systemctl status iptables.service' for details.

and the logs still show:

Code: Select all

Nov 01 06:07:02 dragon systemd[1]: iptables.service: Service lacks both ExecStart= and ExecStop= setting. Refusing.

using the iptables-store and iptables-restore services does succeed, it seems (my iptables rules all look great):

Code: Select all

# systemctl start iptables-store.service

Nov 01 06:11:34 dragon systemd[1]: Starting Store iptables firewall rules...
-- Subject: Unit iptables-store.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit iptables-store.service has begun starting up.
Nov 01 06:11:34 dragon systemd[1]: Started Store iptables firewall rules.
-- Subject: Unit iptables-store.service has finished start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit iptables-store.service has finished starting up.
-- 
-- The start-up result is done.

Code: Select all

# systemctl start iptables-restore.service

Nov 01 06:13:47 dragon systemd[1]: Starting Restore iptables firewall rules...
-- Subject: Unit iptables-restore.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit iptables-restore.service has begun starting up.
Nov 01 06:13:48 dragon systemd[1]: Started Restore iptables firewall rules.
-- Subject: Unit iptables-restore.service has finished start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit iptables-restore.service has finished starting up.
-- 
-- The start-up result is done.

The thing is, while the -store and -restore seem to work fine, and my iptables-rules look great, it is scary that a reboot will leave me without any firewall until I manually do something :-O It is only the iptables.service and ip6tables.service which are unhappy and fail.

The fail-message says that there may be something missing (ExecStart= and ExecStop=). Googling also suggests there should be a [Service] section within the iptables.service file.

Overnight, I rebuilt *every single package* on one of my workstations (almost 1500 packages!!), but there was no change

Curiouser and curiouser.

[eccerr0r]

Strange, my computer seems to save iptables data upon reboot and restore them upon boot after enabling them.

I also get the same invalid argument errors when trying to "restart", "stop", or "start" the meta-service.

Does it actually work or does it just give errors when manually starting them?

[gordonp]

Does it actually work or does it just give errors when manually starting them?

This was an interesting question! So, during a lull at work, I first verified that my iptables rules were present...

...then I rebooted.

And yes - upon restarting, my iptables rules were indeed present.

I'm not convinced that things are right, and I think I'll need to verify after any restart, that my iptables rules are there :-O
For troubleshooting and debugging, I'll want absolute certainty and control over my firewall!!!

It's beginning to sound like the iptables.service / ip6tables.service files require some alteration, such that "restart", "stop" and "start" work as expected. Do you also think this is the case, @eccerr0r? Or, are there some different tests you can suggest, so that a complete, thorough and helpful bug-report can be filed?

Thank-you!

[Zucca]

Without ExecStart the service isn't ment to be "started", but enabled. It seems that the iptables.service only makes dependencies... I't kind of a meta service file.
However there should be information for systemd that it's that kind of service. RemainAfterExit=yes would be one possible. There are other that I don't remember. Systemd has TONS of different config variables for different unit files. Yeah. It's complicated.

However if you still can enable it, it'll work as a meta service that pulls and pushes required units with it.

With a quick glance, this seems like a case for a bug report...

[eccerr0r]

Yeah, it probably is a "bug" but as I don't have another non-Gentoo systemd machine to compare with, I'm not sure what it's supposed to look like.

The service, as it's written, agree with Zucca - it's a meta-service. The iptables-store and iptables-restore are the real "services" that save and restore your iptables settings. But from what I've been reading about other distributions, you're supposed to be able to start/stop this meta service, and not just enable/disable.

Don't know, maybe Gentoo is different... maybe not...

[Thistled]

Yep this seems to be a bug, and the developers look to have given up on it.

https://bugs.gentoo.org/show_bug.cgi?id=555920

No updates since August.

Does that mean we are supposed to run our systems without a firewall?

Crazy.

[eccerr0r]

The systemd iptables save/load services seems to work just fine, just it cannot start/stop the metaservice. It just looks like it doesn't work. The underlying services (-start and -restart) are what does the actual work and at least it does save them for me.

I don't know why this is different from other systemd distributions, supposedly just need to copy another distro's solution...

[Zucca]

Does that mean we are supposed to run our systems without a firewall?

Nope.
Try this:

Code: Select all

systemctl edit iptables.service

... and paste this code in:

Code: Select all

[Service]
Type=oneshot
ExecStart=/bin/false

... then

Code: Select all

systemctl daemon-reload

... and

Code: Select all

systemctl restart iptables

Yes. It's a workaround for now.

[Thistled]

Thanks for the reply Zucca, but.......

Matthias Maier gentoo-dev 2015-08-13 05:40:02 UTC
(In reply to Mike Gilbert from comment #9)
> Tweaked slightly:
>
> [Service]
> Type=oneshot
> ExecStart=/bin/false

This is worse. Please don't do that.
With ExecStart=/bin/false systemd tries to start the unit, it fails and after that the system state is "degraded":

# systemctl status
[...]
State: degraded
[...]

and the unit shows up in # systemctl

iptables.service loaded failed failed Store and restore iptables firewall rules

(In reply to Rick Harris from comment #0)
> [Service]
> ExecStart=/bin/true
> ExecStop=/bin/true

This is equally bad because it promotes iptables.service to look like a fully functional service (showing up a started, and listed in systemctl output)- but this is not the case.

The current behavior of iptables.service is to be just a short cut for

# systemctl enable iptables.service

The only "error message" it produces is a notification in the journal that it is not considered a functional service file. And as such it does not show up in systemctl output. Further, any action like

# systemctl start iptables

results in an error.

A target is also not an option because this would still require to enable both iptables-* services...

form the Bugzilla suggests that might not be a good idea.

[Zucca]

You could try to leave ExecStart line out althogether. Oneshot type of service allows that.

[Thistled]

You could try to leave ExecStart line out althogether. Oneshot type of service allows that.

I have tried this and the service fails to start.

[Zucca]

Using three files for systemd to restore and flush the rules of iptables seems strange...

If I'd do it, I'd do it this way propably:

Code: Select all

[Service]
Type=oneshot
ExecStart=<command to restore rules>
ExecReload=<flush? + restore>
ExecStop=<command to flush>
RemainAfterExit=yes

I need to see later how I have done it on my Gentoo machine.

[Logicien]

If you look at the files of the iptables package, you can see

Code: Select all

equery f iptables
...
/usr/lib/systemd/system/ip6tables-restore.service
/usr/lib/systemd/system/ip6tables-store.service
/usr/lib/systemd/system/ip6tables.service
/usr/lib/systemd/system/iptables-restore.service
/usr/lib/systemd/system/iptables-store.service
/usr/lib/systemd/system/iptables.service
...

ipt6tables.service and iptables.service are dummy files. The real services are provided by ip6tables-restore.service, ip6tables-store.service, iptables-restore.service and iptables-store.service. So, depending on if you want to restore and/or store ip6tables and/or iptables rules, you choose the service(s) to enable.

ipt6tables.service and iptables.service do not need to be enabled to restore at boot and save at shutdown the Ip6tables and Iptables rules. It's like Samba, you do not enable samba.service who will fail, you enable smbd.service and/or nmbd.service and/or other related Samba services. This is Systemd who split related services in different units.