Bug 9329 - Can't disable firewall
Summary: Can't disable firewall
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 3
Hardware: All Linux
Priority: Normal critical
Target Milestone: ---
Assignee: Thierry Vignaud
QA Contact:
URL:
Whiteboard: 3beta3
Keywords:
: 9346 10195 10308 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-03-11 10:25 CET by Lionel van den Berg
Modified: 2013-12-27 16:02 CET (History)
26 users (show)

See Also:
Source RPM: drakx-net
CVE:
Status comment:


Attachments

Description Lionel van den Berg 2013-03-11 10:25:24 CET
When I attempt to disable the firewall from MCC->Security->Setup Your Personal Firewall->Tick "Everything (no firewall)" the change does not take affect. I ran MCC from the command line and got some errors out, this is the output from the time that I clicked Setup Your Personal Firewall to clicking Ok after selecting "Everything (no firewall)":

[Code]
Gtk-Message **: Failed to load module "canberra-gtk-module" at /usr/lib/libDrakX/mygtk2.pm line 20.

Note: This output shows SysV services only and does not include native
      systemd services. SysV configuration data might be overridden by native
      systemd configuration.

Clearing Shorewall....
Processing /etc/shorewall/stop ...
iptables v1.4.17: Couldn't load target `Ifw':No such file or directory

Try `iptables -h' or 'iptables --help' for more information.
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
ipset v6.16.1: The set with the given name does not exist
ipset v6.16.1: The set with the given name does not exist
Processing /etc/shorewall/tcclear ...
Running /sbin/iptables-restore...
Processing /etc/shorewall/stopped ...
Processing /etc/shorewall/clear ...
done.

[/Code]

The same behaviour if I access the firewall through "Configure System Security, Permissions and Audit".



Mageia 3 Cauldron. I thought it was beta 3 but I downloaded it before the 10th when the email was sent though which confused me.

x86_64 version of Mageia.

How reproducible:


Steps to Reproduce:
1. Open Mageia Control Centre
2. Security
3. Setup your personal firewall
4. Select "Everything (no firewall)"
5. Press OK
6. Go back into Setup your personal firewall and firewall is back to the original setting.


Reproducible: 

Steps to Reproduce:
David Walser 2013-03-11 12:08:43 CET

CC: (none) => thierry.vignaud
Component: Security => RPM Packages
Assignee: bugsquad => thierry.vignaud
QA Contact: security => (none)

David Walser 2013-03-11 12:09:08 CET

CC: (none) => mageia

Comment 1 claire robinson 2013-03-11 14:54:45 CET
Valid 3beta3

CC: (none) => ennael1
Whiteboard: (none) => 3beta3

Comment 2 Manuel Hiebel 2013-03-11 18:11:58 CET
file /usr/lib/libDrakX/network/shorewall.pm line 112
modify my %conf = (disabled => services::is_service_running(shorewall),
to     my %conf = (disabled => !services::is_service_running(shorewall),

can you confirm ?

I don't understand why it's broken as it was working before iirc, but in my vm it seems to work again with that.
(it can take 1min until the service is activate)


for:
iptables v1.4.17: Couldn't load target `Ifw':No such file or directory

Try `iptables -h' or 'iptables --help' for more information.
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
ipset v6.16.1: The set with the given name does not exist
ipset v6.16.1: The set with the given name does not exist
Processing /etc/shorewall/tcclear ...
Running /sbin/iptables-restore...
Processing /etc/shorewall/stopped ...
Processing /etc/shorewall/clear ... 

I have the same in mga2

Source RPM: (none) => drakx-net

Comment 3 Lionel van den Berg 2013-03-12 10:49:27 CET
>modify my %conf = (disabled => services::is_service_running(shorewall),
>to     my %conf = (disabled => !services::is_service_running(shorewall),

I did the change and now it disables correctly. When I first disabled and pressed OK it stopped on a grey screen, I pressed the cross to make it exit properly. When I returned it was disabled as requested.

For the second part above was there anything I had to do?
Comment 4 Manuel Hiebel 2013-03-12 12:26:41 CET
>When I first disabled and pressed OK it stopped on a grey screen, I pressed the cross to make it exit properly.

Yep it seems to take 1min to make the change, I don't know why.


>For the second part above was there anything I had to do?
nop

Thierry, Olivier, opinion above the wrong service status check ?
Comment 5 Manuel Hiebel 2013-03-12 12:38:40 CET
s/above/about
Thierry Vignaud 2013-03-12 19:08:36 CET

CC: (none) => mageia

Comment 6 Lionel van den Berg 2013-03-12 23:25:33 CET
I thought I might add that I installed from the "Network installer + nonfree firmware CD"

Not sure if this makes any difference?
Comment 7 Manuel Hiebel 2013-03-13 23:12:08 CET
Not sure if this makes any difference?
it should not

even playing with systemctl start/status shorewall.service give strange results
William Kenney 2013-03-15 02:30:05 CET

CC: (none) => wilcal.int

Comment 8 Dag Nygren 2013-03-16 11:01:25 CET
I see the same behaviour together with the bug I reported on WLAN connections with too long names.
If I remove them in "manage connections" AND from /etc/shorewall/interfaces everything works for me.

CC: (none) => dag

Comment 9 Dag Nygren 2013-03-16 11:05:21 CET
The bug I was referring to is:
https://bugs.mageia.org/show_bug.cgi?id=8960
Comment 10 Manuel Hiebel 2013-03-19 00:03:23 CET
*** Bug 9346 has been marked as a duplicate of this bug. ***

CC: (none) => periliocastrol

Comment 11 Manuel Hiebel 2013-03-24 16:14:59 CET
blino changed something that should fix it (same line as me)

http://svnweb.mageia.org/soft/drakx-net/trunk/lib/network/shorewall.pm?r1=7657&r2=7656&pathrev=7657
Comment 12 Manuel Hiebel 2013-03-27 12:17:13 CET
was pushed

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Comment 13 Lionel van den Berg 2013-03-27 13:18:33 CET
Great.

Will I see this flow through as an update or does it get added to next release (hypothetical assuming I hadn't fixed it manually).
Comment 14 Stephan Aspridis 2013-05-19 22:26:19 CEST
The bug still exists in Mageia 3 Release LiveDVD-KDE 64 Bit.

shorewall.pm is set to:

my %conf = (disabled => !services::starts_on_boot("shorewall"),

but the firewall is still not changeable.

I tried to change the line to:

my %conf = (disabled => !services::is_service_running(shorewall),

but this has no effect either.

CC: (none) => theodis171

Comment 15 Thierry Vignaud 2013-05-21 12:38:51 CEST
*** Bug 10195 has been marked as a duplicate of this bug. ***

CC: (none) => fab.lin

Comment 16 William Kenney 2013-05-21 14:06:12 CEST
I confirm that I ran right into this on my first install
with m3 boot.iso. It was not there in my last tests of
the release candidates. I thought I was going crazy.
Something has changed. Apache, ProFTP install but do
not work. What Happened?

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

William Kenney 2013-05-21 15:47:35 CEST

Version: Cauldron => 3

William Kenney 2013-05-21 15:47:52 CEST

Hardware: x86_64 => All

Comment 17 William Kenney 2013-05-21 17:47:36 CEST
I ran through my testing again this morning
and again confirm this bug. I qualify my
testing in that it is on a 32-bit platform.
Apache and ProFTP work fine with localhost
and the IP assigned to the platform. Other
M2 systems on the LAN cannot get to the
Apache & ProFTP apps. They appear to be
Firewalled out.
Comment 18 Petr Vesely 2013-05-22 07:19:14 CEST
Confirming this bug. On x64 Mageia 3 system it's impossible make samba works through firewall. It seem like firewall is OFF but nothing pass through it.

CC: (none) => pasaman

Comment 19 Franck Doucet 2013-05-22 19:42:56 CEST
  (In reply to Petr Vesely from comment #18)
> Confirming this bug. On x64 Mageia 3 system it's impossible make samba works
> through firewall. It seem like firewall is OFF but nothing pass through it.

  I make Samba work with Mageia3 x64 by de MCC> system > 
 - shorewall  [on boot] [no]
 - shorewall6 [on boot] [yes]
 - reboot
And  choose [no firewall] . I dont realy like this, but I acces to Samba shares...

CC: (none) => franckdoucet

Comment 20 William Kenney 2013-05-22 20:06:30 CEST
I have a Dell 64-bit laptop on which is M3. I have not updated it in about a
week and it runs Apache/ProFTP just fine even out to the interent.

MCC -> System -> services -> there is only shorewall and it is not turned on at
boot and is "stopped"

I have a 32-bit M3 test system that I network installed ( boot.iso ) on
Monday, 20 May and that exhibits this problem. MCC -> System -> services has two
shorewall's, shorewall and shorewall6. I have set this for shorewall to not
start at boot and shorewall6 to start at boot. I rebooted the system, found both
shorewall and shorewall6 stopped and everything works fine. Shorewall6 is
stopped even though it is set in MCC -> System -> services to start at boot.

I am not going to update the Laptop until this bug is cleared so that I can
gather info if needed.
Comment 21 William Kenney 2013-05-22 21:48:05 CEST
MCC -> System -> service

I just did a new network install ( boot.iso ) and both shorewall
and shorewall6 are checked to start at boot. Unchecking them,
and a reboot, for me solves the problem. M2 does not start
shorewall started as default, M3 used to be that way, and
now both are checked to start at boot as default. I think
that's wrong.

My firewall is a Netgear Router.
Barry Jackson 2013-05-23 19:58:00 CEST

CC: (none) => zen25000
Severity: major => critical

Comment 22 Bill Wilkinson 2013-05-24 15:31:52 CEST
This appears to be a problem throughout.  In attempting to set up a print server on mga3-32, I attempted to allow CUPS connections (check the CUPS server box in the personal firewall settings in MCC). State is not saved on exit as expected.

CC: (none) => wrw105

Comment 23 William Kenney 2013-05-24 15:54:04 CEST
If you follow the steps outlined in:

https://bugs.mageia.org/show_bug.cgi?id=9723

Comment 14 you will be able to run a CUPS server.
I have two M3 installs running CUPS servers that
now work just fine. Also those M3 boxes are
successfully running Apache and ProFTP servers.
Comment 24 Bill Wilkinson 2013-05-24 20:42:38 CEST
Thanks, Wil!  Maybe that could be useful for the M3 errata?  I just removed shorewall-ip6 and reinstalled.  No need to delete anything from /etc.
Comment 25 William Kenney 2013-05-24 21:12:08 CEST
It is in the Errata:

Para. 4.4.4

https://wiki.mageia.org/en/Mageia_3_Errata#drakfirewall_doesn.27t_generate_shorewall6_config
Johnny A. Solbu 2013-05-25 05:12:29 CEST

CC: (none) => cooker

Comment 26 Dylan Myers 2013-05-25 20:15:10 CEST
(In reply to Bill Wilkinson from comment #24)
> Thanks, Wil!  Maybe that could be useful for the M3 errata?  I just removed
> shorewall-ip6 and reinstalled.  No need to delete anything from /etc.

(In reply to William Kenney from comment #25)
> It is in the Errata:
> 
> Para. 4.4.4
> 
> https://wiki.mageia.org/en/Mageia_3_Errata#drakfirewall_doesn.
> 27t_generate_shorewall6_config

Unfortunately in order to make firewall changes using MCC, you have to do this EVERY single time. This needs to get fixed quickly because a firewall is critical. Especially for those of us using our laptops in a professional capacity.

Also, @those who said "my router is my firewall", as a professional in the field I can safely say that is an idiotic statement. Security is best done in layers. In your network if someone cracks the router's firewall (takes a good hacker < 5 minutes to crack home grade router firewalls on averag) then your entire network is wide open. If he cracks the router firewall and you have a firewall properly configured on each computer, as I do, then he'll have to continue to work at it to get anywhere. Never trust in a router firewall alone.

CC: (none) => ralgith

Comment 27 Martin Turner 2013-05-27 06:09:25 CEST
I confirm that this is happening to me as well. PogoLinux AMD 4400 X86_64. 

This is a critical bug for me in that I use my Mageia system to test my products with Windows and Mac OS and as of this bug, I cannot connect via SMB to eiteer of my systems.

Please provide a solid workaround or perm fix ASAP.

CC: (none) => mdturnerinoz

Comment 28 Dylan Myers 2013-05-27 06:10:48 CEST
(In reply to Martin Turner from comment #27)
> I confirm that this is happening to me as well. PogoLinux AMD 4400 X86_64. 
> 
> This is a critical bug for me in that I use my Mageia system to test my
> products with Windows and Mac OS and as of this bug, I cannot connect via
> SMB to eiteer of my systems.
> 
> Please provide a solid workaround or perm fix ASAP.

The only solid work-around is to to uninstall shorewall-ip6 before every firewall edit session.
Comment 29 Martin Turner 2013-05-27 08:36:07 CEST
(In reply to Dylan Myers from comment #28)
> (In reply to Martin Turner from comment #27)
> > I confirm that this is happening to me as well. PogoLinux AMD 4400 X86_64. 
> > 
> > This is a critical bug for me in that I use my Mageia system to test my
> > products with Windows and Mac OS and as of this bug, I cannot connect via
> > SMB to eiteer of my systems.
> > 
> > Please provide a solid workaround or perm fix ASAP.
> 
> The only solid work-around is to to uninstall shorewall-ip6 before every
> firewall edit session.

Thanks, that worked just fine. I can now connect via SMB to my other systems. Since I am behind qutie a solid router firewall, I don't need the Shorewall firewall at all.Oh, and when someone gets around to (hopefully) changing pre-release test suites in this area, I urge then to add a test to ensure that "no firewall" works when set during install. It worked just fine in Mage1 and Mageia2 but was broken here as I was appalled to see all firewall entries set off (meaning a Mageia firewall in place) when I had set it off during the final setps of installing Mageia 3. Mageia has been doing well at distrowatch and in industry rags like Linux format; main path issues like this that should NOT have occurred (ie broken) require better pre-release testing if Mageia is to maintain its distro lead (ir that is any goal of sorts (which I'd hope it is)).
Morgan Leijström 2013-05-27 10:55:57 CEST

CC: (none) => fri

Comment 30 Manuel Hiebel 2013-05-28 14:35:50 CEST
*** Bug 10308 has been marked as a duplicate of this bug. ***

CC: (none) => andre.luiz.d.queiroz

Helge Hielscher 2013-05-30 22:49:06 CEST

CC: (none) => hhielscher

Juan Luis Baptiste 2013-06-04 20:11:11 CEST

CC: (none) => juan.baptiste

Comment 31 Alejandro Vargas 2013-06-05 13:10:12 CEST
I can confirm the bug in a new clean installation of Mageia 3 64 bits.

CC: (none) => alejandro.anv

Comment 32 Giuseppe Stoduto 2013-06-05 14:40:17 CEST
> The only solid work-around is to to uninstall shorewall-ip6 before every
> firewall edit session.

works well

the file  /etc/shorewall/rules.drakx   is changed but shorewall not re-read the changes

# service shorewall reload
Redirecting to /bin/systemctl reload shorewall.service
Failed to issue method call: Job type reload is not applicable for unit shorewall.service.


another error


# service shorewall restart
Redirecting to /bin/systemctl restart shorewall.service
Job for shorewall.service failed. See 'systemctl status shorewall.service' and 'journalctl -n' for details.


# systemctl status shorewall.service
shorewall.service - Shorewall IPv4 firewall
	  Loaded: loaded (/usr/lib/systemd/system/shorewall.service; enabled)
	  Active: failed (Result: exit-code) since Wed, 2013-06-05 14:34:50 CEST; 1min 35s ago
	 Process: 18214 ExecStart=/usr/sbin/shorewall $OPTIONS start (code=exited, status=143)
	  CGroup: name=systemd:/system/shorewall.service

Jun 05 14:34:50 giuseppe.home shorewall[18214]: iptables: No chain/target/match by that name.
Jun 05 14:34:50 giuseppe.home shorewall[18214]: ipset v6.16.1: The set with the given name does not exist
Jun 05 14:34:50 giuseppe.home shorewall[18214]: ipset v6.16.1: The set with the given name does not exist
Jun 05 14:34:50 giuseppe.home shorewall[18214]: Processing /etc/shorewall/tcclear ...
Jun 05 14:34:50 giuseppe.home shorewall[18214]: Running /sbin/iptables-restore...
Jun 05 14:34:50 giuseppe.home shorewall[18214]: Processing /etc/shorewall/stopped ...
Jun 05 14:34:50 giuseppe.home shorewall[18214]: /usr/share/shorewall/lib.common: line 112: 18489 Terminato               $SHOREWA...ions $@
Jun 05 14:34:50 giuseppe.home systemd[1]: shorewall.service: main process exited, code=exited, status=143/n/a
Jun 05 14:34:50 giuseppe.home systemd[1]: Failed to start Shorewall IPv4 firewall.
Jun 05 14:34:50 giuseppe.home systemd[1]: Unit shorewall.service entered failed state


and finally

# iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            

Chain FORWARD (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination    


iptables does not change, it remains always knows itself. (google traslate hehehe)

CC: (none) => gstoduto

Marcello Anni 2013-06-08 17:24:23 CEST

CC: (none) => marcello.anni

Comment 33 Paul Dessart 2013-06-10 17:14:43 CEST
Have the same issue on Mageia 3 X86_64 Publice release : 3.8.13-desktop-1.mga3 #1 SMP Tue May 14 19:05:25 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

had to disable shorewall from service and prevent boot run then restart the machine to get the firewall disabled.

CC: (none) => paul_dessart

Comment 34 José Jorge 2013-06-10 21:21:52 CEST
Buf confirmed again, this a huge one!

CC: (none) => lists.jjorge

Comment 35 Giuseppe Stoduto 2013-06-10 23:19:51 CEST
I understand how to do cause the bug

if in

/etc/shorewall/interfaces

they are names differ from eth0 the shorewall not start.

for example

# cat interfaces 

#
# Shorewall version 4 - Interfaces File
#
# For information about entries in this file, type "man shorewall-interfaces"
#
# The manpage is also online at
# http://www.shorewall.net/manpages/shorewall-interfaces.html
#
###############################################################################
###############################################################################

net	eth0	detect
net	eth1	detect





shorewall start 


if instead





# cat interfaces 

#
# Shorewall version 4 - Interfaces File
#
# For information about entries in this file, type "man shorewall-interfaces"
#
# The manpage is also online at
# http://www.shorewall.net/manpages/shorewall-interfaces.html
#
###############################################################################
###############################################################################
net	wlan0	detect
net	eth0	detect
net	Airstation_automatica	detect




shorewall not start.


this is my configuration.
Richard Patrick 2013-06-11 13:43:30 CEST

CC: (none) => rjpatrick19

Comment 36 Manuel Hiebel 2013-06-15 20:38:45 CEST
please test new version of drakxtools from core/updates_testing
Comment 37 Giuseppe Stoduto 2013-06-16 00:54:28 CEST
not much has changed

The only solid work-around is to to uninstall shorewall-ip6 before every firewall edit session.

but


# cat interfaces 

#
# Shorewall version 4 - Interfaces File
#
# For information about entries in this file, type "man shorewall-interfaces"
#
# The manpage is also online at
# http://www.shorewall.net/manpages/shorewall-interfaces.html
#
###############################################################################
###############################################################################
net	wlan0	detect
net	eth0	detect
#net	Airstation_automatica	detect   ### comment this line ####

shorewall start


#net	Airstation_automatica	detect   ### comment this line ####

this line is also important for drakguard because it is changed and therefore shorewall not start
Comment 38 Giuseppe Stoduto 2013-06-19 21:50:22 CEST
with today's update 19/06/2013 the problem to uninstall shorewall-ip6 not reappeared

but there is another bug https://bugs.mageia.org/show_bug.cgi?id=10513


Finally, to make it all work I disabled network-manager



Thank you. begins to be fun mageia
Comment 39 Thierry Vignaud 2013-12-27 16:02:09 CET
Closing then

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.