Bug 12265 - firewall: iptables rules are being created in the wrong chain
Summary: firewall: iptables rules are being created in the wrong chain
Status: ASSIGNED
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: unspecified Unspecified
: Will only affect a few users Major Usability
Assignee: Stefan Schantl
QA Contact: Peter Müller
URL:
Keywords:
Depends on:
Blocks: FWBUGS
  Show dependency treegraph
 
Reported: 2020-01-04 14:02 UTC by Michael Tremer
Modified: 2021-09-04 10:08 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Tremer 2020-01-04 14:02:59 UTC
I am trying to give machines in the ORANGE network access to the web proxy.

When I create a rule with the ORANGE network as source and select the GREEN IP address as destination (TCP port 800 as well), this rule is being created in the forward section and won't work.

If I do the same thing with the ORANGE IP address the same thing happens.

It is interesting that nobody else ran into this before, but it is a major problem.
Comment 1 Peter Müller 2020-01-22 21:15:41 UTC
I bumped into this as well - it certainly is a major problem.
Comment 2 Alexander Marx 2021-03-09 10:10:39 UTC
Hi.

Well, isn't the default behaviour of the firewall to block traffic from orange to green/blue?

What do you expect from this rule?

Why should a orange machine have access to the webproxy? Shouldn't it directly communicate with the Internet? 

So the question is:

Should the Webinterface just give an errormessage when trying to create such a rule or should the firewalldesign be changed, so that orange Ip's can access green?
Comment 3 Michael Tremer 2021-03-18 12:57:03 UTC
(In reply to Alexander Marx from comment #2)
> Well, isn't the default behaviour of the firewall to block traffic from
> orange to green/blue?

Yes it is, but firewall rules can be created to make exceptions to this rule.

> What do you expect from this rule?

I am expecting an iptables rule in INPUTFW if the destination IP address is one of the IP addresses of the firewall itself.

> Why should a orange machine have access to the webproxy? Shouldn't it
> directly communicate with the Internet? 

Take this as an example :) I am using rules like this for various other things.

The problem is the same if I were to create rules with the GREEN or BLUE IP address as destination.

> So the question is:
> 
> Should the Webinterface just give an errormessage when trying to create such
> a rule or should the firewalldesign be changed, so that orange Ip's can
> access green?

No, it should accept the rule (and it is doing it), but it needs to create it in INPUTFW and not FORWARDFW (or probably both).

I believe firewall.pl would behave correctly. The CGI script is just writing the rule to the wrong configuration file.
Comment 4 Alexander Marx 2021-03-25 13:27:00 UTC
Committed a patch for this one.

https://patchwork.ipfire.org/patch/3982/
Comment 5 Peter Müller 2021-03-27 08:32:10 UTC
> Committed a patch for this one.

Thank you very much. :-)

Since that patch did not made it into the Git repository, yet, I'll set this back to ASSIGNED so we won't lose track on it. In addition, I will test your patch and provide feedback soon.
Comment 6 Peter Müller 2021-03-27 20:46:28 UTC
This patch unfortunately does not work correctly:

https://lists.ipfire.org/pipermail/development/2021-March/009650.html
Comment 7 Alexander Marx 2021-03-30 13:09:33 UTC
Ups.

try this one instead:
https://patchwork.ipfire.org/patch/3999/
Comment 8 Peter Müller 2021-06-28 16:11:35 UTC
Users seem to bump into this, too: https://community.ipfire.org/t/incoming-firewall-access-when-using-standard-networks/5701
Comment 9 Stefan Schantl 2021-07-16 17:17:50 UTC
Fix has been sent to the development mailing list:

https://patchwork.ipfire.org/project/ipfire/patch/20210716163558.3779-1-stefan.schantl@ipfire.org/
Comment 10 Peter Müller 2021-09-04 10:08:14 UTC
Resetting this back to ASSIGNED since the patch has not been merged yet.