Bug 24738 - Shorewall and Iptables killing each other
Summary: Shorewall and Iptables killing each other
Status: RESOLVED INVALID
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 6
Hardware: All Linux
Priority: Normal major
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-04-29 23:27 CEST by HomeBoy TAZ
Modified: 2019-05-01 15:44 CEST (History)
4 users (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments

Description HomeBoy TAZ 2019-04-29 23:27:59 CEST
Description of problem:

iptables starting normally, but if shorewall running, shorewall ends (inactive dead).
shorewall starting normally, but if iptables running, iptables ends (inactive dead).
In other words, cannot have both services running at the same time.

Version-Release number of selected component (if applicable):

iptables-1.6.1-2.mga6
shorewall-5.0.15.6-1.mga6

How reproducible:

I have a VM which was running mga6 and I upgraded to beta2 (then installed all updates until 04/29). I experience the same behaviour so this is why I have in mind that it is a bug rather than a configuration issue.

The VM has:
- iptables-1.8.2-5.mga7
- shorewall-5.2.3-1

Cannot tell since when I have the issue.
If iptables is down, I cannot remote access my machine. If shorewall is down, hum, it has not to be down, right?

Steps to Reproduce:
1. service iptables restart then service iptables status and service shorewall status
2. service shorewall restart then service shorewall status and service iptables status

I would be please to add more information, but so far, I do not know what/where/how to find some.
David Walser 2019-04-30 01:54:02 CEST

Component: Security => RPM Packages
QA Contact: security => (none)

Comment 1 HomeBoy TAZ 2019-04-30 18:47:41 CEST
Hi,

A little update:
- created a new VM and launched the installation from the 7.Beta3 ISO
- I choosed my French language and keyboard, created a user, other options were default ones (I have a doubt if Plasma was default or if I selected it)
- updates were installed during the installation
- after first login, service shorewall status was OK, service iptables status was KO
- I installed all remaining updates, reboot (because of kernel update)
- same result for both services

I will keep my 7.Beta3 VM and I will try a fresh 6.0 and keep this ticket updated
Comment 2 Marja Van Waes 2019-05-01 09:36:38 CEST
I'm not sure it should be possible to run both, as you can read here http://www.shorewall.net/Introduction.html shorewall uses several other tools and iptables is among those.

Anyway, CC'ing some more knowledgeable people than me.

CC: (none) => basesystem, kernel, marja11

Comment 3 José Jorge 2019-05-01 12:40:02 CEST
(In reply to Marja Van Waes from comment #2)
> I'm not sure it should be possible to run both, as you can read here
> http://www.shorewall.net/Introduction.html shorewall uses several other
> tools and iptables is among those.
> 
You are right Marja : shorewall is a configurator for iptables. It is not a service, in the sense there is not a daemon always running.

The real question is : does the firewall open/close the ports you asked for?

The end user should only use the MCC to configure firewall, all other uses require manual tweaking.

Status: NEW => UNCONFIRMED
Ever confirmed: 1 => 0
CC: (none) => lists.jjorge

Comment 4 Jani Välimaa 2019-05-01 15:29:41 CEST
The reason why things happens like described in comment 0 is because shorewall.service has 'Conflicts=iptables.service'.

IIUC both shorewall.service and iptables.service just loads firewall rules so it makes sense to conflict with each other to not override rules set by other one.
Comment 5 HomeBoy TAZ 2019-05-01 15:39:47 CEST
OK, so my guess was wrong, it is not a bug but a feature.

So, as I want shorewall, only this service should be running.
If I want a fail2ban additional service, I should configure it to use shorewall for banning rules (instead of iptables) so in that case, only fail2ban and shorewall should be running?

The thing that confused me is that shorewall is declared as an iptable frontend so what I understood is that iptables should be running and shorewall was just a more human readable rules...

If I understood it well now, you should mark this as "resolved" (as it appears that there is no "not a bug" [or I do not have access to it] choice ; on my side, I have to figure out what went wrong on my configuration because my services became unavailable for some days...

Thanks for the time you taken on this.
Comment 6 José Jorge 2019-05-01 15:44:41 CEST
Doing so.

Status: UNCONFIRMED => RESOLVED
Resolution: (none) => INVALID


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