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.
I bumped into this as well - it certainly is a major problem.
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?
(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.
Committed a patch for this one. https://patchwork.ipfire.org/patch/3982/
> 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.
This patch unfortunately does not work correctly: https://lists.ipfire.org/pipermail/development/2021-March/009650.html
Ups. try this one instead: https://patchwork.ipfire.org/patch/3999/
Users seem to bump into this, too: https://community.ipfire.org/t/incoming-firewall-access-when-using-standard-networks/5701
Fix has been sent to the development mailing list: https://patchwork.ipfire.org/project/ipfire/patch/20210716163558.3779-1-stefan.schantl@ipfire.org/
Resetting this back to ASSIGNED since the patch has not been merged yet.
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=a9611629cc90f716fbf4fc7050a95f0b7b285df3
Shipped here: https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=d10a558196dc6a8c3559659686f74d1722c8741b
https://blog.ipfire.org/post/ipfire-2-27-core-update-160-released