shorewall does not start at boot
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| shorewall (Ubuntu) |
Undecided
|
Unassigned | ||
| shorewall6 (Ubuntu) |
Undecided
|
Unassigned |
Bug Description
Running Ubuntu
Description: Ubuntu 15.04
Release: 15.04
Running shorewall
shorewall:
Installed: 4.6.4.3-2
Candidate: 4.6.4.3-2
Version table:
*** 4.6.4.3-2 0
500 http://
100 /var/lib/
During boot I get the following warnings
Oct 31 08:56:44 MusicPc systemd[1]: shorewall.service: Found ordering cycle on shorewall.
Oct 31 08:56:44 MusicPc systemd[1]: shorewall.service: Found dependency on network-
Oct 31 08:56:44 MusicPc systemd[1]: shorewall.service: Found dependency on network.
Oct 31 08:56:44 MusicPc systemd[1]: shorewall.service: Found dependency on NetworkManager.
Oct 31 08:56:44 MusicPc systemd[1]: shorewall.service: Found dependency on basic.target/start
Oct 31 08:56:44 MusicPc systemd[1]: shorewall.service: Found dependency on sockets.
Oct 31 08:56:44 MusicPc systemd[1]: shorewall.service: Found dependency on uuidd.socket/start
Oct 31 08:56:44 MusicPc systemd[1]: shorewall.service: Found dependency on sysinit.
Oct 31 08:56:44 MusicPc systemd[1]: shorewall.service: Found dependency on shorewall.
Oct 31 08:56:44 MusicPc systemd[1]: shorewall.service: Breaking ordering cycle by deleting job network-
Oct 31 08:56:44 MusicPc systemd[1]: network-
Oct 31 08:56:44 MusicPc systemd[1]: sysinit.target: Found dependency on shorewall.
Oct 31 08:56:44 MusicPc systemd[1]: sysinit.target: Breaking ordering cycle by deleting job shorewall.
Oct 31 08:56:44 MusicPc systemd[1]: shorewall.service: Job shorewall.
The above warnings stop shorewall from starting at boot.
I can (need to) start shorewall manually and this works without a problem.
I should have reported this as a bug sonner as this problem occurred also in the two previous releases.
Poldi (poldi) wrote : | #1 |
Tyler Hicks (tyhicks) wrote : | #2 |
Hello and thanks for the bug report. I'm going to make it a public security bug so that it'll get more attention.
affects: | ifupdown (Ubuntu) → shorewall (Ubuntu) |
information type: | Private Security → Public Security |
information type: | Public Security → Public |
Poldi (poldi) wrote : | #3 |
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/
DefaultDependen
Before=
After=network-
Wants=network-
Conflicts=
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-
[Unit]
Documentation=
Description=
DefaultDependen
After=local-
Before=
Wants=network-
Conflicts=
[Service]
Type=oneshot
RemainAfterExit=yes
TimeoutSec=30
Restart=no
IgnoreSIGPIPE=no
KillMode=none
ExecStart=
ExecStop=
ExecReload=
[Install]
WantedBy=
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/
-------
John Polansky (john.polansky) wrote : | #4 |
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
Poldi (poldi) wrote : | #5 |
The forum post is http://
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
Launchpad Janitor (janitor) wrote : | #6 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in shorewall (Ubuntu): | |
status: | New → Confirmed |
Changed in shorewall6 (Ubuntu): | |
status: | New → Confirmed |
e-Vent (fmaster) wrote : | #8 |
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=
Wants=network-
After=network-
Conflicts=
[Service]
Type=oneshot
RemainAfterExit=yes
EnvironmentFile
StandardOutput=
ExecStart=
ExecStop=
ExecReload=
[Install]
WantedBy=
BCSharp (bcsharp) wrote : | #9 |
@fmaster
Since you moved shorewall to start after network-
BCSharp (bcsharp) wrote : | #10 |
Also I believe that the line:
ExecReload=
should rather be:
ExecReload=
e-Vent (fmaster) wrote : | #11 |
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.
e-Vent (fmaster) wrote : | #12 |
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=
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.
e-Vent (fmaster) wrote : | #13 |
It would appear a solution to the firewall being open before shorewall start is to use the 'shorewall-init' package.
http://
The extra init package closes the firewall prior to shorewall startup avoiding that issue (assuming you set the product in /etc/default/
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.
Snow (snowy16) wrote : | #14 |
I'm on 16.04 and I tried installing shorewall-init and configuring /etc/default/
I had to change my /etc/systemd/
from
Wants=network-
After=network-
to
Wants=network-
Before=
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.
information type: | Public → Public Security |
Poldi (poldi) wrote : | #16 |
I can confirm that the solution outlined in #13 works for me on 16.04.
Thanks
Thommie Rother (t-rother) wrote : | #17 |
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 ...
Mario Mediati (mediati) wrote : | #18 |
In 16.04 e-Vent's service file exists at /lib/systemd/
sudo systemctl enable /lib/systemd/
a symlink will be created in /etc/systemd/
Kevin P. Fleming (k.p.fleming) wrote : | #19 |
Ditto to #18; that solution worked for me (for both shorewall and shorewall6).
Janiko (janiko) wrote : | #20 |
#18 : worked for me on 16.10 (yakkety)
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