Bug 11168 - Creation of firewall rule with NAT enabled and destiation "networks|all" fails
Summary: Creation of firewall rule with NAT enabled and destiation "networks|all" fails
Status: CLOSED FIXED
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: all All
: Will affect an average number of users Minor Usability
Assignee: Stefan Schantl
QA Contact: Michael Tremer
URL:
Keywords:
Depends on:
Blocks: FWBUGS
  Show dependency treegraph
 
Reported: 2016-08-24 14:01 UTC by Timmothy Wilson
Modified: 2023-04-24 03:22 UTC (History)
4 users (show)

See Also:
stefan.schantl: needinfo+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Timmothy Wilson 2016-08-24 14:01:09 UTC
As described in the forum (http://forum.ipfire.org/viewtopic.php?f=27&t=17058), it is not possible to set up a firewall rule for enforcing clients to use IPFires DNS proxy.

The changes described at the IPFire planet (http://planet.ipfire.org/post/use-ipfire-to-protect-you-from-dnschanger) thereof cannot be applied through the WebIF.

Please see the forum branch above for more details.

Best regards,
Timmothy Wilson
Comment 1 Peter Müller 2017-10-23 23:04:01 UTC
This issue can be reproduced with Core Update 114.
Comment 2 Alexander Marx 2018-08-23 08:16:38 UTC
Thats a difficult one.
Please correct me if i am wrong (and i am usually ;-) ) 
As IPFire has the ability to set an own DNS Server, there is a standard rule which allows traffic to port 53 per default.
Any rule regarding port 53 would never be checked as the included rule matches.

So i think it is not possible to set a redirect for port 53 in the usual firewall rules.

To get the correct behaviour i think it is needed to set a rule in any PREROUTING chain. These chains are used BEFORE the firewall chains are checked.
There is actually no way to set these chains via webinterface.

To test it, someone could test a manual iptables rule in the  script
/etc/sysconfig/firewall.local

something like
iptables -t nat -A CUSTOMPREROUTING -p udp --dport 53 -j DNAT --to <dns-server-to-use>:53
Comment 3 Michael Tremer 2018-08-23 15:23:48 UTC
And why isn't this possible in the GUI?
Comment 4 Alexander Marx 2018-08-23 15:34:00 UTC
What is your idea to implement this?
Comment 5 Michael Tremer 2018-08-23 15:36:30 UTC
MODIFIED means that a patch has been submitted. When the source has been *modified*: https://wiki.ipfire.org/devel/bugzilla/workflow

I don't understand why the GUI isn't currently able to create this rule. What is blocking this?
Comment 6 Matthias Fischer 2018-12-03 19:58:30 UTC
Hi,

as far as I understand the WiKi, the problem is a GUI/DNAT problem. See the note for solution 1 in https://wiki.ipfire.org/configuration/firewall/dns

Right now I'm testing the following rules in '/etc/sysconfig/firewall.local':

...
iptables -t nat -A CUSTOMPREROUTING -i green0 -p udp --dport 53 -j DNAT --to 192.168.100.254:53
iptables -t nat -A CUSTOMPREROUTING -i green0 -p tcp --dport 53 -j DNAT --to 192.168.100.254:53
iptables -t nat -A CUSTOMPREROUTING -i blue0 -p udp --dport 53 -j DNAT --to 192.168.101.254:53
iptables -t nat -A CUSTOMPREROUTING -i blue0 -p tcp --dport 53 -j DNAT --to 192.168.101.254:53
...

See same question in https://forum.ipfire.org/viewtopic.php?t=17058&f=27#p120855

These rules seem to work but I'm not REALLY sure and would like to get some feedback. Is this OK?

Best,
Matthias
Comment 7 Peter Müller 2018-12-04 16:47:39 UTC
Yes, the firewall GUI is the problem here.
Comment 8 Alexander Marx 2021-03-09 10:19:38 UTC
This one is still not answered.
Michael, please give a feedback.

There are defaultrules in ipfire, which are always there and used BEFORE the firewallGUI rules are taken (FORWARD,INOUT and OUTPUT)

The rule for using the internal DNS is fixed into IPFire isn't it?
Comment 9 Stefan Schantl 2021-07-06 19:36:56 UTC
For this the easiest solution would be a REDIRECT rule.

I've posted a fix to get redirect rules to work in a proper way to the mailing list.

https://patchwork.ipfire.org/project/ipfire/patch/20210630184031.7726-1-stefan.schantl@ipfire.org/

Currently the feature still needs some attention, I'll keep this ticked up to date.
Comment 10 Stefan Schantl 2023-02-12 11:55:02 UTC
The redirect feature has been release some time ago and works fine here.

Is this bug still valid or can it be closed safely?

Thanks in advance,

-Stefan