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
Hello Julien,
thank you for the detailled bug description.
Could you please file this as a new bug at https://bugzilla.ipfire.org/ ? Bugzilla is used as a bug tracker. Let me know if there is any trouble. :-)
Thanks, and best regards, Peter Müller
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.
1^e 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.png
However, I noticed that also that these same rules were reported in INPUTFW
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.png
Including the 4 redirection rules :
image.png
As we can see, they are correctly created in NAT_DESTINATION :
image.png
However, it is not expected to be duplicated in OUTGOINGFW as well.
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.png
As I was refused a nice creation :
image.png
I modified directly in the /var/ipfire/firewall/input file.
Here is the result:
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.png
The rules are correctly created in table NAT_SOURCE.
image.png
However, there is also a rule creation in the INPUTFW table, which I think is unnecessary.
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
@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
The image is not gone.[image: image.png]
Le mer. 23 janv. 2019 à 22:20, Julien Blais blais.julien.30@gmail.com a écrit :
@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
-
Alexander Marx -
Julien Blais -
Peter Müller