Re: IPFire 2.27 - Core Update 160 released

Re: IPFire 2.27 - Core Update 160 released

[Bernhard Bitsch]

[-- Attachment #1: Type: text/plain, Size: 670 bytes --]

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>.
> 

Re: IPFire 2.27 - Core Update 160 released

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 912 bytes --]

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(a)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>.

Re: IPFire 2.27 - Core Update 160 released

[Bernhard Bitsch]

[-- Attachment #1: Type: text/plain, Size: 1306 bytes --]

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(a)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>.
> 

Re: IPFire 2.27 - Core Update 160 released

[Daniel Weismüller]

[-- Attachment #1: Type: text/plain, Size: 2236 bytes --]

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(a)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(a)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>.

Re: IPFire 2.27 - Core Update 160 released

[Bernhard Bitsch]

[-- Attachment #1: Type: text/plain, Size: 2771 bytes --]

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
> 
> 5. Oktober 2021 22:10, "Bernhard Bitsch" <bbitsch(a)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(a)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>.

Re: IPFire 2.27 - Core Update 160 released

[Daniel Weismüller]

[-- Attachment #1: Type: text/plain, Size: 3388 bytes --]

6. Oktober 2021 14:12, "Bernhard Bitsch" <bbitsch(a)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(a)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(a)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>.

Re: IPFire 2.27 - Core Update 160 released

[Bernhard Bitsch]

[-- Attachment #1: Type: text/plain, Size: 3952 bytes --]

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:
> 6. Oktober 2021 14:12, "Bernhard Bitsch" <bbitsch(a)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(a)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(a)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>.

Re: IPFire 2.27 - Core Update 160 released

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 3232 bytes --]

Hello,

> On 6 Oct 2021, at 13:12, Bernhard Bitsch <bbitsch(a)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(a)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(a)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>.

Re: IPFire 2.27 - Core Update 160 released

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 6221 bytes --]



> On 6 Oct 2021, at 20:40, Jon Murphy <jcmurphy26(a)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(a)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:
>>> 6. Oktober 2021 14:12, "Bernhard Bitsch" <bbitsch(a)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(a)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(a)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>.
>