Bug 24738

Summary:	Shorewall and Iptables killing each other
Product:	Mageia	Reporter:	HomeBoy TAZ <nicolas.bachelet1>
Component:	RPM Packages	Assignee:	Mageia Bug Squad <bugsquad>
Status:	RESOLVED INVALID	QA Contact:
Severity:	major
Priority:	Normal	CC:	basesystem, kernel, lists.jjorge, marja11
Version:	6
Target Milestone:	---
Hardware:	All
OS:	Linux
Whiteboard:
Source RPM:		CVE:
Status comment:

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