@Alexander Marx alexander.marx@ipfire.org A small error has slipped into the diagram.
@ALL
There is a network before, see the attached diagram. Pfsense does not do NAT. [image: image.png]
@Peter Müller :
The anomaly is created: https://bugzilla.ipfire.org/show_bug.cgi?id=11977#c0
With kind regards.
Jbsky
Le mer. 23 janv. 2019 à 16:05, Alexander Marx alexander.marx@ipfire.org a écrit :
Hi together, as far as i can see in your pictures, your GREEN network is 192.168.60.xx You are defining a hostgroup as SOURCE, which has devices from the network 192.168.10.xx. These are not GREEN and so the firewall assumes it is an INPUT rule.
Correct me if i am wrong.
Alex
Am 22.01.19 um 23:51 schrieb Julien Blais:
Hello,
In this new year, apart from wishing you all the best, I would also like to share with you the anomalies I was able to raise in Ipfire on the generation of firewall rules using the HMI.
I noticed 3 major problems in the management of firewall rules.
In the page https://ipfire:444/cgi-bin/firewall.cgi, it is worth noting 3 tables, namely Firewall Rules, Incoming Firewall Access and Outgoing Firewall Access.
The first two deduplication concerns the rules established in the 1st table, Firewall Rules.
1e problem :
By defining a FORWARD rule whose destination is the standard network red0 (everything but green0/orange0/blue0/etc...), a rule is created in FORWARDFW.
[image: image.png]
However, I noticed that also that these same rules were reported in INPUTFW [image: image.png]
INPUTFW rules with the -o red0 flag, it feels weird, doesn't it?
2nd problem :
It is much more delicate because it concerns DNAT.
For the creation of such a rule, here is the example below.
[image: image.png]
Including the 4 redirection rules :
[image: image.png]
As we can see, they are correctly created in NAT_DESTINATION :
[image: image.png]
However, it is not expected to be duplicated in OUTGOINGFW as well. [image: image.png]
In fact, the creation of these rules is useless, even dangerous. Hopefully things are going well at home and the potential threat remains my person (LOL).
The last case is a little more twisted, it concerns the SNAT, of which here is the example below. [image: image.png]
As I was refused a nice creation :
[image: image.png]
I modified directly in the /var/ipfire/firewall/input file.
Here is the result:
[image: image.png]
Using such a rule allows me to follow the path represented by the diagram below and solve the problem of double NAT: [image: image.png]
The rules are correctly created in table NAT_SOURCE.
[image: image.png]
However, there is also a rule creation in the INPUTFW table, which I think is unnecessary. [image: image.png]
Awaiting your thoughts, I hope I have provided all the information you need to understand the 3 cases above.
With kind regards.
Jbsky