Just a question. How is the activation of redirection implemented?
Am 05.10.2021 um 12:45 schrieb IPFire Project:
IPFire Logo
there is a new post from Michael Tremer on the IPFire Blog:
*IPFire 2.27 - Core Update 160 released*
This is the release announcement for IPFire 2.27 - Core Update 160. It comes with a large number of bug fixes and package updates and prepare for removing Python 2 which has reached its end of life.Click Here To Read More https://blog.ipfire.org/post/ipfire-2-27-core-update-160-released
The IPFire Project Don't like these emails? Unsubscribe https://people.ipfire.org/unsubscribe.
Stefan and Michael created this:
https://wiki.ipfire.org/configuration/firewall/rules/redirect-services https://wiki.ipfire.org/configuration/firewall/rules/redirect-services
Does that help?
Jon
On Oct 5, 2021, at 8:55 AM, Bernhard Bitsch bbitsch@ipfire.org wrote:
Just a question. How is the activation of redirection implemented?
Am 05.10.2021 um 12:45 schrieb IPFire Project:
IPFire Logo there is a new post from Michael Tremer on the IPFire Blog: *IPFire 2.27 - Core Update 160 released* This is the release announcement for IPFire 2.27 - Core Update 160. It comes with a large number of bug fixes and package updates and prepare for removing Python 2 which has reached its end of life. Click Here To Read More https://blog.ipfire.org/post/ipfire-2-27-core-update-160-released The IPFire Project Don't like these emails? Unsubscribe https://people.ipfire.org/unsubscribe.
Hello,
Simply using -j REDIRECT.
This was always part of the firewall engine, but the UI was broken and did not allow to create these rules.
-Michael
On 5 Oct 2021, at 14:55, Bernhard Bitsch bbitsch@ipfire.org wrote:
Just a question. How is the activation of redirection implemented?
Am 05.10.2021 um 12:45 schrieb IPFire Project:
IPFire Logo there is a new post from Michael Tremer on the IPFire Blog: *IPFire 2.27 - Core Update 160 released* This is the release announcement for IPFire 2.27 - Core Update 160. It comes with a large number of bug fixes and package updates and prepare for removing Python 2 which has reached its end of life. Click Here To Read More https://blog.ipfire.org/post/ipfire-2-27-core-update-160-released The IPFire Project Don't like these emails? Unsubscribe https://people.ipfire.org/unsubscribe.
Hi all,
Thanks. So it was only a misunderstanding. I thought, there would be options to redirect DNS requests and NTP requests. But this 'any port solution' is much mightier. I'll try to convert my actual firewall.local solution to the main stream and report about the results.
Regards, Bernhard
Am 05.10.2021 um 18:28 schrieb Michael Tremer:
Hello,
Simply using -j REDIRECT.
This was always part of the firewall engine, but the UI was broken and did not allow to create these rules.
-Michael
On 5 Oct 2021, at 14:55, Bernhard Bitsch bbitsch@ipfire.org wrote:
Just a question. How is the activation of redirection implemented?
Am 05.10.2021 um 12:45 schrieb IPFire Project:
IPFire Logo there is a new post from Michael Tremer on the IPFire Blog: *IPFire 2.27 - Core Update 160 released* This is the release announcement for IPFire 2.27 - Core Update 160. It comes with a large number of bug fixes and package updates and prepare for removing Python 2 which has reached its end of life. Click Here To Read More https://blog.ipfire.org/post/ipfire-2-27-core-update-160-released The IPFire Project Don't like these emails? Unsubscribe https://people.ipfire.org/unsubscribe.
Hello I have also had a look at this. There are now two Wiki pages on this topic. - A general one (https://wiki.ipfire.org/configuration/firewall/rules/redirect-services). - A very specific one for DNS redirect (https://wiki.ipfire.org/configuration/firewall/dns).
Since core160 the general method works. This is equivalent to the method 1 described on the specific page.
Following the general instructions, I have created a few firewall rules to redirect DNS, DoT and NTP. This works very well now.
In general, I think that general instructions are always better than specific step-by-step instructions.
In my eyes, the described method 2, which had to be taken as a temporary solution, is therefore obsolete. In addition, pure blocking can lead to some devices no longer working.
Do you see it the same way?
- Daniel
5. Oktober 2021 22:10, "Bernhard Bitsch" bbitsch@ipfire.org schrieb:
Hi all,
Thanks. So it was only a misunderstanding. I thought, there would be options to redirect DNS requests and NTP requests. But this 'any port solution' is much mightier. I'll try to convert my actual firewall.local solution to the main stream and report about the results.
Regards, Bernhard
Am 05.10.2021 um 18:28 schrieb Michael Tremer:
Hello, Simply using -j REDIRECT. This was always part of the firewall engine, but the UI was broken and did not allow to create these rules. -Michael On 5 Oct 2021, at 14:55, Bernhard Bitsch bbitsch@ipfire.org wrote:
Just a question. How is the activation of redirection implemented?
Am 05.10.2021 um 12:45 schrieb IPFire Project:
IPFire Logo there is a new post from Michael Tremer on the IPFire Blog: *IPFire 2.27 - Core Update 160 released* This is the release announcement for IPFire 2.27 - Core Update 160. It comes with a large number of bug fixes and package updates and prepare for removing Python 2 which has reached its end of life. Click Here To Read More https://blog.ipfire.org/post/ipfire-2-27-core-update-160-released The IPFire Project Don't like these emails? Unsubscribe https://people.ipfire.org/unsubscribe.
Hello,
Am 06.10.2021 um 12:04 schrieb Daniel Weismüller:
Hello I have also had a look at this. There are now two Wiki pages on this topic.
- A general one (https://wiki.ipfire.org/configuration/firewall/rules/redirect-services).
- A very specific one for DNS redirect (https://wiki.ipfire.org/configuration/firewall/dns).
This is true, but the first page can't be found by a normal research in the wiki.
Since core160 the general method works. This is equivalent to the method 1 described on the specific page.
Following the general instructions, I have created a few firewall rules to redirect DNS, DoT and NTP. This works very well now.
In general, I think that general instructions are always better than specific step-by-step instructions.
Agreed.
In my eyes, the described method 2, which had to be taken as a temporary solution, is therefore obsolete. In addition, pure blocking can lead to some devices no longer working.
Having implemented the second method until now, I can see a difference. Label 'DNAT' in the logging isn't nice. 'REDIRECT' would be more helpful. If I define a rule for NTP, I get two log entries ( one with 'DNAT', one with 'INPUTFW' ). A similiar rule for DNS produces one log message only. - Bernhard
Do you see it the same way?
Daniel
- Oktober 2021 22:10, "Bernhard Bitsch" bbitsch@ipfire.org schrieb:
Hi all,
Thanks. So it was only a misunderstanding. I thought, there would be options to redirect DNS requests and NTP requests. But this 'any port solution' is much mightier. I'll try to convert my actual firewall.local solution to the main stream and report about the results.
Regards, Bernhard
Am 05.10.2021 um 18:28 schrieb Michael Tremer:
Hello, Simply using -j REDIRECT. This was always part of the firewall engine, but the UI was broken and did not allow to create these rules. -Michael On 5 Oct 2021, at 14:55, Bernhard Bitsch bbitsch@ipfire.org wrote:
Just a question. How is the activation of redirection implemented?
Am 05.10.2021 um 12:45 schrieb IPFire Project:
IPFire Logo there is a new post from Michael Tremer on the IPFire Blog: *IPFire 2.27 - Core Update 160 released* This is the release announcement for IPFire 2.27 - Core Update 160. It comes with a large number of bug fixes and package updates and prepare for removing Python 2 which has reached its end of life. Click Here To Read More https://blog.ipfire.org/post/ipfire-2-27-core-update-160-released The IPFire Project Don't like these emails? Unsubscribe https://people.ipfire.org/unsubscribe.
6. Oktober 2021 14:12, "Bernhard Bitsch" bbitsch@ipfire.org schrieb:
Hello,
Am 06.10.2021 um 12:04 schrieb Daniel Weismüller:
Hello I have also had a look at this. There are now two Wiki pages on this topic.
- A general one (https://wiki.ipfire.org/configuration/firewall/rules/redirect-services).
- A very specific one for DNS redirect (https://wiki.ipfire.org/configuration/firewall/dns).
This is true, but the first page can't be found by a normal research in the wiki. Since core160 the general method works. This is equivalent to the method 1 described on the specific page. Following the general instructions, I have created a few firewall rules to redirect DNS, DoT and NTP. This works very well now. In general, I think that general instructions are always better than specific step-by-step instructions. Agreed. In my eyes, the described method 2, which had to be taken as a temporary solution, is therefore obsolete. In addition, pure blocking can lead to some devices no longer working. Having implemented the second method until now, I can see a difference.
Label 'DNAT' in the logging isn't nice. 'REDIRECT' would be more helpful. If I define a rule for NTP, I get two log entries ( one with 'DNAT', one with 'INPUTFW' ). A similiar rule for DNS produces one log message only.
Bernhard
I have checked my logs and cannot confirm this.
15:16:30 INPUTFW blue0 UDP 192.168.56.127 192.168.56.1 57803 53(DOMAIN) b8:85:84:a6:a0:f7 15:16:30 DNAT blue0 UDP 192.168.56.127 192.168.56.1 57803 53(DOMAIN) b8:85:84:a6:a0:f7 15:16:30 INPUTFW green0 UDP 192.168.55.30 192.168.55.1 123(NTP) 123(NTP) 00:1a:e8:ad:07:52 15:16:30 DNAT green0 UDP 192.168.55.30 192.168.55.1 123(NTP) 123(NTP) 00:1a:e8:ad:07:52
As you can see, two entries are always generated for me.
- Daniel
Do you see it the same way?
Daniel 5. Oktober 2021 22:10, "Bernhard Bitsch" bbitsch@ipfire.org schrieb: Hi all,
Thanks. So it was only a misunderstanding. I thought, there would be options to redirect DNS requests and NTP requests. But this 'any port solution' is much mightier. I'll try to convert my actual firewall.local solution to the main stream and report about the results.
Regards, Bernhard
Am 05.10.2021 um 18:28 schrieb Michael Tremer:
Hello, Simply using -j REDIRECT. This was always part of the firewall engine, but the UI was broken and did not allow to create these rules. -Michael On 5 Oct 2021, at 14:55, Bernhard Bitsch bbitsch@ipfire.org wrote: Just a question. How is the activation of redirection implemented?
Am 05.10.2021 um 12:45 schrieb IPFire Project:
IPFire Logo there is a new post from Michael Tremer on the IPFire Blog: *IPFire 2.27 - Core Update 160 released* This is the release announcement for IPFire 2.27 - Core Update 160. It comes with a large number of bug fixes and package updates and prepare for removing Python 2 which has reached its end of life. Click Here To Read More https://blog.ipfire.org/post/ipfire-2-27-core-update-160-released The IPFire Project Don't like these emails? Unsubscribe https://people.ipfire.org/unsubscribe.
Hi Daniel,
I tried to eliminate this double messages. First I found the standard rules in 'Incoming Firewall Access' for DNS enabled. Interpreting these as the 'RETURN' rules discussed in the development process, I defined similiar rules for NTP. The 'INPUTFW' messages are gone. They show up again, when I enable logging for these rules. Maybe this helps a bit to clarify the issue.
Bernhard
Am 06.10.2021 um 15:22 schrieb Daniel Weismüller:
- Oktober 2021 14:12, "Bernhard Bitsch" bbitsch@ipfire.org schrieb:
Hello,
Am 06.10.2021 um 12:04 schrieb Daniel Weismüller:
Hello I have also had a look at this. There are now two Wiki pages on this topic.
- A general one (https://wiki.ipfire.org/configuration/firewall/rules/redirect-services).
- A very specific one for DNS redirect (https://wiki.ipfire.org/configuration/firewall/dns).
This is true, but the first page can't be found by a normal research in the wiki. Since core160 the general method works. This is equivalent to the method 1 described on the specific page. Following the general instructions, I have created a few firewall rules to redirect DNS, DoT and NTP. This works very well now. In general, I think that general instructions are always better than specific step-by-step instructions. Agreed. In my eyes, the described method 2, which had to be taken as a temporary solution, is therefore obsolete. In addition, pure blocking can lead to some devices no longer working. Having implemented the second method until now, I can see a difference.
Label 'DNAT' in the logging isn't nice. 'REDIRECT' would be more helpful. If I define a rule for NTP, I get two log entries ( one with 'DNAT', one with 'INPUTFW' ). A similiar rule for DNS produces one log message only.
Bernhard
I have checked my logs and cannot confirm this.
15:16:30 INPUTFW blue0 UDP 192.168.56.127 192.168.56.1 57803 53(DOMAIN) b8:85:84:a6:a0:f7 15:16:30 DNAT blue0 UDP 192.168.56.127 192.168.56.1 57803 53(DOMAIN) b8:85:84:a6:a0:f7 15:16:30 INPUTFW green0 UDP 192.168.55.30 192.168.55.1 123(NTP) 123(NTP) 00:1a:e8:ad:07:52 15:16:30 DNAT green0 UDP 192.168.55.30 192.168.55.1 123(NTP) 123(NTP) 00:1a:e8:ad:07:52
As you can see, two entries are always generated for me.
Daniel
Do you see it the same way?
Daniel 5. Oktober 2021 22:10, "Bernhard Bitsch" bbitsch@ipfire.org schrieb: Hi all,
Thanks. So it was only a misunderstanding. I thought, there would be options to redirect DNS requests and NTP requests. But this 'any port solution' is much mightier. I'll try to convert my actual firewall.local solution to the main stream and report about the results.
Regards, Bernhard
Am 05.10.2021 um 18:28 schrieb Michael Tremer:
Hello, Simply using -j REDIRECT. This was always part of the firewall engine, but the UI was broken and did not allow to create these rules. -Michael On 5 Oct 2021, at 14:55, Bernhard Bitsch bbitsch@ipfire.org wrote: Just a question. How is the activation of redirection implemented?
Am 05.10.2021 um 12:45 schrieb IPFire Project:
IPFire Logo there is a new post from Michael Tremer on the IPFire Blog: *IPFire 2.27 - Core Update 160 released* This is the release announcement for IPFire 2.27 - Core Update 160. It comes with a large number of bug fixes and package updates and prepare for removing Python 2 which has reached its end of life. Click Here To Read More https://blog.ipfire.org/post/ipfire-2-27-core-update-160-released The IPFire Project Don't like these emails? Unsubscribe https://people.ipfire.org/unsubscribe.
Hello *,
Just to add more info. I was trying to eliminate the Log info for the new redirect rule.
With the Rule enabled AND the Log enabled I see this in `/var/log/messages`: Oct 6 13:17:07 ipfireHP kernel: DNAT IN=green0 OUT= MAC=<REDACTED> SRC=192.168.1.100 DST=1.1.1.1 LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=10636 PROTO=UDP SPT=57109 DPT=53 LEN=44 Oct 6 13:17:07 ipfireHP kernel: INPUTFW IN=green0 OUT= MAC=<REDACTED> SRC=192.168.1.100 DST=192.168.1.1 LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=10636 PROTO=UDP SPT=57109 DPT=53 LEN=44 Oct 6 13:17:07 ipfireHP kernel: DNAT IN=green0 OUT= MAC=<REDACTED> SRC=192.168.1.100 DST=1.2.3.4 LEN=65 TOS=0x00 PREC=0x00 TTL=64 ID=6382 PROTO=UDP SPT=55200 DPT=53 LEN=45 Oct 6 13:17:07 ipfireHP kernel: INPUTFW IN=green0 OUT= MAC=<REDACTED> SRC=192.168.1.100 DST=192.168.1.1 LEN=65 TOS=0x00 PREC=0x00 TTL=64 ID=6382 PROTO=UDP SPT=55200 DPT=53 LEN=45
With the Rule enabled AND the Log NOT enabled I see this in `/var/log/messages`: Oct 6 13:50:16 ipfireHP kernel: DNAT IN=green0 OUT= MAC=<REDACTED> SRC=192.168.1.100 DST=192.168.1.1 LEN=69 TOS=0x00 PREC=0x00 TTL=255 ID=60778 PROTO=UDP SPT=59328 DPT=53 LEN=49 Oct 6 13:50:16 ipfireHP kernel: INPUTFW IN=green0 OUT= MAC=<REDACTED> SRC=192.168.1.100 DST=192.168.1.1 LEN=69 TOS=0x00 PREC=0x00 TTL=255 ID=60778 PROTO=UDP SPT=59328 DPT=53 LEN=49 Oct 6 13:50:17 ipfireHP kernel: DNAT IN=green0 OUT= MAC=<REDACTED> SRC=192.168.1.100 DST=192.168.1.1 LEN=62 TOS=0x00 PREC=0x00 TTL=255 ID=15801 PROTO=UDP SPT=57028 DPT=53 LEN=42 Oct 6 13:50:17 ipfireHP kernel: INPUTFW IN=green0 OUT= MAC=<REDACTED> SRC=192.168.1.100 DST=192.168.1.1 LEN=62 TOS=0x00 PREC=0x00 TTL=255 ID=15801 PROTO=UDP SPT=57028 DPT=53 LEN=42
It seems like logging cannot be disabled for this rule.
See: https://bugzilla.ipfire.org/show_bug.cgi?id=12654 https://bugzilla.ipfire.org/show_bug.cgi?id=12654
Jon
On Oct 6, 2021, at 8:49 AM, Bernhard Bitsch <bbitsch@ipfire.org mailto:bbitsch@ipfire.org> wrote:
Hi Daniel,
I tried to eliminate this double messages. First I found the standard rules in 'Incoming Firewall Access' for DNS enabled. Interpreting these as the 'RETURN' rules discussed in the development process, I defined similiar rules for NTP. The 'INPUTFW' messages are gone. They show up again, when I enable logging for these rules. Maybe this helps a bit to clarify the issue.
Bernhard
Am 06.10.2021 um 15:22 schrieb Daniel Weismüller:
- Oktober 2021 14:12, "Bernhard Bitsch" <bbitsch@ipfire.org mailto:bbitsch@ipfire.org> schrieb:
Hello,
Am 06.10.2021 um 12:04 schrieb Daniel Weismüller:
Hello I have also had a look at this. There are now two Wiki pages on this topic.
- A general one (https://wiki.ipfire.org/configuration/firewall/rules/redirect-services https://wiki.ipfire.org/configuration/firewall/rules/redirect-services).
- A very specific one for DNS redirect (https://wiki.ipfire.org/configuration/firewall/dns https://wiki.ipfire.org/configuration/firewall/dns).
This is true, but the first page can't be found by a normal research in the wiki. Since core160 the general method works. This is equivalent to the method 1 described on the specific page. Following the general instructions, I have created a few firewall rules to redirect DNS, DoT and NTP. This works very well now. In general, I think that general instructions are always better than specific step-by-step instructions. Agreed. In my eyes, the described method 2, which had to be taken as a temporary solution, is therefore obsolete. In addition, pure blocking can lead to some devices no longer working. Having implemented the second method until now, I can see a difference.
Label 'DNAT' in the logging isn't nice. 'REDIRECT' would be more helpful. If I define a rule for NTP, I get two log entries ( one with 'DNAT', one with 'INPUTFW' ). A similiar rule for DNS produces one log message only.
Bernhard
I have checked my logs and cannot confirm this. 15:16:30 INPUTFW blue0 UDP 192.168.56.127 192.168.56.1 57803 53(DOMAIN) b8:85:84:a6:a0:f7 15:16:30 DNAT blue0 UDP 192.168.56.127 192.168.56.1 57803 53(DOMAIN) b8:85:84:a6:a0:f7 15:16:30 INPUTFW green0 UDP 192.168.55.30 192.168.55.1 123(NTP) 123(NTP) 00:1a:e8:ad:07:52 15:16:30 DNAT green0 UDP 192.168.55.30 192.168.55.1 123(NTP) 123(NTP) 00:1a:e8:ad:07:52 As you can see, two entries are always generated for me.
Daniel
Do you see it the same way?
Daniel 5. Oktober 2021 22:10, "Bernhard Bitsch" <bbitsch@ipfire.org mailto:bbitsch@ipfire.org> schrieb: Hi all,
Thanks. So it was only a misunderstanding. I thought, there would be options to redirect DNS requests and NTP requests. But this 'any port solution' is much mightier. I'll try to convert my actual firewall.local solution to the main stream and report about the results.
Regards, Bernhard
Am 05.10.2021 um 18:28 schrieb Michael Tremer:
Hello, Simply using -j REDIRECT. This was always part of the firewall engine, but the UI was broken and did not allow to create these rules. -Michael On 5 Oct 2021, at 14:55, Bernhard Bitsch <bbitsch@ipfire.org mailto:bbitsch@ipfire.org> wrote: Just a question. How is the activation of redirection implemented?
Am 05.10.2021 um 12:45 schrieb IPFire Project:
IPFire Logo there is a new post from Michael Tremer on the IPFire Blog: *IPFire 2.27 - Core Update 160 released* This is the release announcement for IPFire 2.27 - Core Update 160. It comes with a large number of bug fixes and package updates and prepare for removing Python 2 which has reached its end of life. Click Here To Read More <https://blog.ipfire.org/post/ipfire-2-27-core-update-160-released https://blog.ipfire.org/post/ipfire-2-27-core-update-160-released> The IPFire Project Don't like these emails? Unsubscribe <https://people.ipfire.org/unsubscribe https://people.ipfire.org/unsubscribe>.
On 6 Oct 2021, at 20:40, Jon Murphy jcmurphy26@gmail.com wrote:
Hello *,
Just to add more info. I was trying to eliminate the Log info for the new redirect rule.
Can anyone confirm this?
With the Rule enabled AND the Log enabled I see this in `/var/log/messages`: Oct 6 13:17:07 ipfireHP kernel: DNAT IN=green0 OUT= MAC=<REDACTED> SRC=192.168.1.100 DST=1.1.1.1 LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=10636 PROTO=UDP SPT=57109 DPT=53 LEN=44 Oct 6 13:17:07 ipfireHP kernel: INPUTFW IN=green0 OUT= MAC=<REDACTED> SRC=192.168.1.100 DST=192.168.1.1 LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=10636 PROTO=UDP SPT=57109 DPT=53 LEN=44 Oct 6 13:17:07 ipfireHP kernel: DNAT IN=green0 OUT= MAC=<REDACTED> SRC=192.168.1.100 DST=1.2.3.4 LEN=65 TOS=0x00 PREC=0x00 TTL=64 ID=6382 PROTO=UDP SPT=55200 DPT=53 LEN=45 Oct 6 13:17:07 ipfireHP kernel: INPUTFW IN=green0 OUT= MAC=<REDACTED> SRC=192.168.1.100 DST=192.168.1.1 LEN=65 TOS=0x00 PREC=0x00 TTL=64 ID=6382 PROTO=UDP SPT=55200 DPT=53 LEN=45
With the Rule enabled AND the Log NOT enabled I see this in `/var/log/messages`: Oct 6 13:50:16 ipfireHP kernel: DNAT IN=green0 OUT= MAC=<REDACTED> SRC=192.168.1.100 DST=192.168.1.1 LEN=69 TOS=0x00 PREC=0x00 TTL=255 ID=60778 PROTO=UDP SPT=59328 DPT=53 LEN=49 Oct 6 13:50:16 ipfireHP kernel: INPUTFW IN=green0 OUT= MAC=<REDACTED> SRC=192.168.1.100 DST=192.168.1.1 LEN=69 TOS=0x00 PREC=0x00 TTL=255 ID=60778 PROTO=UDP SPT=59328 DPT=53 LEN=49 Oct 6 13:50:17 ipfireHP kernel: DNAT IN=green0 OUT= MAC=<REDACTED> SRC=192.168.1.100 DST=192.168.1.1 LEN=62 TOS=0x00 PREC=0x00 TTL=255 ID=15801 PROTO=UDP SPT=57028 DPT=53 LEN=42 Oct 6 13:50:17 ipfireHP kernel: INPUTFW IN=green0 OUT= MAC=<REDACTED> SRC=192.168.1.100 DST=192.168.1.1 LEN=62 TOS=0x00 PREC=0x00 TTL=255 ID=15801 PROTO=UDP SPT=57028 DPT=53 LEN=42
It seems like logging cannot be disabled for this rule.
See: https://bugzilla.ipfire.org/show_bug.cgi?id=12654
Jon
On Oct 6, 2021, at 8:49 AM, Bernhard Bitsch bbitsch@ipfire.org wrote:
Hi Daniel,
I tried to eliminate this double messages. First I found the standard rules in 'Incoming Firewall Access' for DNS enabled. Interpreting these as the 'RETURN' rules discussed in the development process, I defined similiar rules for NTP. The 'INPUTFW' messages are gone. They show up again, when I enable logging for these rules. Maybe this helps a bit to clarify the issue.
Bernhard
Am 06.10.2021 um 15:22 schrieb Daniel Weismüller:
- Oktober 2021 14:12, "Bernhard Bitsch" bbitsch@ipfire.org schrieb:
Hello,
Am 06.10.2021 um 12:04 schrieb Daniel Weismüller:
Hello I have also had a look at this. There are now two Wiki pages on this topic.
- A general one (https://wiki.ipfire.org/configuration/firewall/rules/redirect-services).
- A very specific one for DNS redirect (https://wiki.ipfire.org/configuration/firewall/dns).
This is true, but the first page can't be found by a normal research in the wiki. Since core160 the general method works. This is equivalent to the method 1 described on the specific page. Following the general instructions, I have created a few firewall rules to redirect DNS, DoT and NTP. This works very well now. In general, I think that general instructions are always better than specific step-by-step instructions. Agreed. In my eyes, the described method 2, which had to be taken as a temporary solution, is therefore obsolete. In addition, pure blocking can lead to some devices no longer working. Having implemented the second method until now, I can see a difference.
Label 'DNAT' in the logging isn't nice. 'REDIRECT' would be more helpful. If I define a rule for NTP, I get two log entries ( one with 'DNAT', one with 'INPUTFW' ). A similiar rule for DNS produces one log message only.
Bernhard
I have checked my logs and cannot confirm this. 15:16:30 INPUTFW blue0 UDP 192.168.56.127 192.168.56.1 57803 53(DOMAIN) b8:85:84:a6:a0:f7 15:16:30 DNAT blue0 UDP 192.168.56.127 192.168.56.1 57803 53(DOMAIN) b8:85:84:a6:a0:f7 15:16:30 INPUTFW green0 UDP 192.168.55.30 192.168.55.1 123(NTP) 123(NTP) 00:1a:e8:ad:07:52 15:16:30 DNAT green0 UDP 192.168.55.30 192.168.55.1 123(NTP) 123(NTP) 00:1a:e8:ad:07:52 As you can see, two entries are always generated for me.
Daniel
Do you see it the same way?
Daniel 5. Oktober 2021 22:10, "Bernhard Bitsch" bbitsch@ipfire.org schrieb: Hi all,
Thanks. So it was only a misunderstanding. I thought, there would be options to redirect DNS requests and NTP requests. But this 'any port solution' is much mightier. I'll try to convert my actual firewall.local solution to the main stream and report about the results.
Regards, Bernhard
Am 05.10.2021 um 18:28 schrieb Michael Tremer:
Hello, Simply using -j REDIRECT. This was always part of the firewall engine, but the UI was broken and did not allow to create these rules. -Michael On 5 Oct 2021, at 14:55, Bernhard Bitsch bbitsch@ipfire.org wrote: Just a question. How is the activation of redirection implemented?
Am 05.10.2021 um 12:45 schrieb IPFire Project:
IPFire Logo there is a new post from Michael Tremer on the IPFire Blog: *IPFire 2.27 - Core Update 160 released* This is the release announcement for IPFire 2.27 - Core Update 160. It comes with a large number of bug fixes and package updates and prepare for removing Python 2 which has reached its end of life. Click Here To Read More https://blog.ipfire.org/post/ipfire-2-27-core-update-160-released The IPFire Project Don't like these emails? Unsubscribe https://people.ipfire.org/unsubscribe.
Hello,
On 6 Oct 2021, at 13:12, Bernhard Bitsch bbitsch@ipfire.org wrote:
Hello,
Am 06.10.2021 um 12:04 schrieb Daniel Weismüller:
Hello I have also had a look at this. There are now two Wiki pages on this topic.
- A general one (https://wiki.ipfire.org/configuration/firewall/rules/redirect-services).
- A very specific one for DNS redirect (https://wiki.ipfire.org/configuration/firewall/dns).
This is true, but the first page can't be found by a normal research in the wiki.
Since core160 the general method works. This is equivalent to the method 1 described on the specific page. Following the general instructions, I have created a few firewall rules to redirect DNS, DoT and NTP. This works very well now. In general, I think that general instructions are always better than specific step-by-step instructions.
Agreed.
In my eyes, the described method 2, which had to be taken as a temporary solution, is therefore obsolete. In addition, pure blocking can lead to some devices no longer working.
Having implemented the second method until now, I can see a difference. Label 'DNAT' in the logging isn't nice. 'REDIRECT' would be more helpful.
Technically DNAT is correct. REDIRECT is just a shortcut to change the destination IP address to the local machine and leave the destination port unchanged.
If I define a rule for NTP, I get two log entries ( one with 'DNAT', one with 'INPUTFW' ). A similiar rule for DNS produces one log message only.
Any NAT rule with logging enabled should always produce two log entries. One for the ‘nat’ table and another time when it hits the ’filter’ table.
-Michael
Bernhard
Do you see it the same way?
Daniel 5. Oktober 2021 22:10, "Bernhard Bitsch" bbitsch@ipfire.org schrieb:
Hi all,
Thanks. So it was only a misunderstanding. I thought, there would be options to redirect DNS requests and NTP requests. But this 'any port solution' is much mightier. I'll try to convert my actual firewall.local solution to the main stream and report about the results.
Regards, Bernhard
Am 05.10.2021 um 18:28 schrieb Michael Tremer:
Hello, Simply using -j REDIRECT. This was always part of the firewall engine, but the UI was broken and did not allow to create these rules. -Michael On 5 Oct 2021, at 14:55, Bernhard Bitsch bbitsch@ipfire.org wrote:
Just a question. How is the activation of redirection implemented?
Am 05.10.2021 um 12:45 schrieb IPFire Project:
IPFire Logo there is a new post from Michael Tremer on the IPFire Blog: *IPFire 2.27 - Core Update 160 released* This is the release announcement for IPFire 2.27 - Core Update 160. It comes with a large number of bug fixes and package updates and prepare for removing Python 2 which has reached its end of life. Click Here To Read More https://blog.ipfire.org/post/ipfire-2-27-core-update-160-released The IPFire Project Don't like these emails? Unsubscribe https://people.ipfire.org/unsubscribe.
-
Bernhard Bitsch -
Daniel Weismüller -
Jon Murphy -
Michael Tremer