shorewall does not start at boot

More info.

I've got this problem on all 5 Desktops at home running 15.10. The problem started when upgrading to 15.04, but I had the same issue with a fresh install of 15.04 on a laptop.

Hope this helps

Hello and thanks for the bug report. I'm going to make it a public security bug so that it'll get more attention.

As I have posted the problem in the forum first I had the following reply
----------------------------------------
I have exactly the same problem. Also in my case, upgrade to 15.10 did not help. Searching the Internet for workarounds did not help either (except that this thread and a Debian bug report showed up). So I came up with my own workaround.

Shorewall does not come with a systemd native service unit description. Such description is being generated at boot by /lib/systemd/system-generators/systemd-sysv-generator based on /etc/init.d/shorewall. I have noticed, however, that the LSB header of /etc/init.d/shorewall wants the service to be started from /etc/rcS.d, which is pretty early, and at the same time it has Required-Start: $network $remote_fs, which is a pretty strong requirement. In fact, this is the only script in /etc/rcS.d that requires $network (well, except shorewall6, which exhibits exactly the same problem). Looking into the auto-generated unit in /run/systemd/generator.late/shorewall.service shows:

DefaultDependencies=no
Before=sysinit.target shutdown.target
After=network-online.target remote-fs.target
Wants=network-online.target
Conflicts=shutdown.target

This looks problematic: sysinit.target is a very early target, most higher level services are started after it, and on many systems (including mine) various dependencies will make network-online.target available only after sysinit.target. So in the end, I wrote my own shorewall.service definition and put it in /etc/systemd/system to override the auto-generated one:

[Unit]
Documentation=man:shorewall
Description=Configure the IPv4 firewall at boot time
DefaultDependencies=no
After=local-fs.target systemd-sysctl.service
Before=network-pre.target shutdown.target
Wants=network-pre.target
Conflicts=shutdown.target

[Service]
Type=oneshot
RemainAfterExit=yes
TimeoutSec=30
Restart=no
IgnoreSIGPIPE=no
KillMode=none
ExecStart=/etc/init.d/shorewall start
ExecStop=/etc/init.d/shorewall stop
ExecReload=/etc/init.d/shorewall restart

[Install]
WantedBy=network-online.target

After that, the service is installed by:

$ sudo systemctl enable shorewall.service

This works for me, but I had very specific requirement: for security reasons, I wanted my firewall be up before any network interfaces are up. That means that no remote filesystems will be mounted yet when shorewall start runs and all shorewall config files have to be on a local filesystem. Additionally, /etc/default/shorewall does not define any wait_interfaces.

--------------------------------------------------------------------

This issue affects me as well, was driving me up the wall. Thanks for your suggested workaround Poldi it appears to work well for me as well.

Hopefully they will fix this at some point.

Kubuntu 15.10

The forum post is http://ubuntuforums.org/showthread.php?t=2282688&p=13412197#post13412197

and the credit for the workaround needs to go to BCSharp as it's his.

Given that there has been no feedback from any of the developers/security gurus despite this issue leaving the system completely unsecured after a reboot, I assume that not many users have shorewall as their firewall.

Still would like to get a fix, but not sure what else I can do.

Leo

Status changed to 'Confirmed' because the bug affects multiple users.

Can confirm this bug in 15.10, init.d script not really needed.

Correction to Poldi's workaround (didn't work for me), I pulled the Debian service file from the Shorewall tgz which appears to be fully functional, same as poldi, make the service file and enable it and you are good to go:

#
# The Shoreline Firewall (Shorewall) Packet Filtering Firewall
#
# Copyright 2011 Jonathan Underwood <email address hidden>
# Copyright 2015 Tom Eastep <email address hidden>
#
[Unit]
Description=Shorewall IPv4 firewall
Wants=network-online.target
After=network-online.target
Conflicts=iptables.service firewalld.service

[Service]
Type=oneshot
RemainAfterExit=yes
EnvironmentFile=-/etc/default/shorewall
StandardOutput=syslog
ExecStart=/sbin/shorewall $OPTIONS start $STARTOPTIONS
ExecStop=/sbin/shorewall $OPTIONS stop
ExecReload=/sbin/shorewall $OPTIONS reload $RELOADOPTIONS

[Install]
WantedBy=basic.target

@fmaster

Since you moved shorewall to start after network-online.target, there will be a brief moment that the network is up but the firewall is not configured yet. Or do you have a different solution for this?

Also I believe that the line:

ExecReload=/sbin/shorewall $OPTIONS reload $RELOADOPTIONS

should rather be:

ExecReload=/sbin/shorewall $OPTIONS restart $RESTARTOPTIONS

I pulled this as I said from the Deb service file, I cannot remember the rationale behind waiting for the network to start but I remember something to do with PPPOE connections being potentially problematic for some reason.

I ran this past a Shorewall guru in their IRC but frankly I am not too worried about a brief period of no firewall since I have my services limited to interfaces. I'll have a chat with them shortly.

Also ExecReload executes a reload of shorewall (and the rule set) as intended. Executing a restart achieves the same objective I believe, the only difference is a full restart. Unless you desire a full restart, I'm not seeing an issue as they appear to achieve the same thing.

On further inspection, the reload command in 4.6.4.3 is clearly not doing what the manpage is saying on shorewall which I will put down to not being shorewall 5.X, pre-5.X reload appears to be a reload of a remote host which was moved to a separate command (remote-restart) in 5.X

So yes, is should be:

ExecReload=/sbin/shorewall $OPTIONS restart $RESTARTOPTIONS

Quick discussion with Shorewall people says that a Shorewall-init script should close the firewall prior to networking but that this is unreliable in Ubuntu due to the favour of upstart scripts.

Having a look around to see if there is an init script locking up the firewall before networking now.

It would appear a solution to the firewall being open before shorewall start is to use the 'shorewall-init' package.

 http://shorewall.net/Shorewall-init.html

The extra init package closes the firewall prior to shorewall startup avoiding that issue (assuming you set the product in /etc/default/shorewall)

It would also be wise to set safestop=1 as per the advice on the page as Debian based systems drop the firewall before halt.

I tested my restart while pinging with shorewall blocking ICMP, never got a reply so I assume it works and blocks network before shorewall fires up.

I haven't tried testing the Deb service file using network-pre.target as the above appears to be working nicely. I may do this later if curious.

I'm on 16.04 and I tried installing shorewall-init and configuring /etc/default/shorewall-init per http://shorewall.net/Shorewall-init.html as well as setting safestop=1 in /etc/default/shorewall but was still able to ping my firewall's external IP for a couple seconds upon every reboot.

I had to change my /etc/systemd/system/shorewall.service

from

Wants=network-online.target
After=network-online.target

to

Wants=network-pre.target
Before=network-pre.target

Once that was set, I was no long able to ping my firewall while it was booting up. Thanks to everyone in this thread for contributing.

Still affects shorewall 5.0.4-1 on Ubuntu server 16.04. Besides the already mentioned workaround, (temporarily) using to ufw for firewall management is an option.

I can confirm that the solution outlined in #13 works for me on 16.04.

Thanks

Solution from #8 works on 16.04 but I would expect that the ubuntu shorewall package includes a running systemd configuration instead of leaving that up to the users ...

In 16.04 e-Vent's service file exists at /lib/systemd/system/shorewall.service. If you run:

sudo systemctl enable /lib/systemd/system/shorewall.service

a symlink will be created in /etc/systemd/system/basic.target.wants/ and shorewall will start on boot.

Ditto to #18; that solution worked for me (for both shorewall and shorewall6).

#18 : worked for me on 16.10 (yakkety)