Forcing all DNS traffic from the LAN to the firewall

mfischer · 8 November 2020 09:24

Hi Jon,

LOL - YMMD! Sorry, this is a bit longer than I wanted.

Explanation => actually, I asked a wrong/misleading question, but got an interesting answer:

Answer:

I totally overlooked the table with the two options for BLUE! Please don’t ask me why!

So I originally added a CGI entry for BLUE which is only shown if BLUE exists. At the top of the page, right under the Masqerading ORANGE/BLUE-selections. These selections are only shown if (&Header::blue/orange_used()) is true in optionsfw.cgi.
Next I thought about adding the apppriate DNS- and NTP-REDIRECT rules to /etc/init.d/firewall. But where? And that was my original question. Where to put these rules in the firewall init script!? And is this script the right place? Is there something better?

For now, if I follow your proposal, the REDIRECT rules for GREEN would still go in /etc/init.d/firewall. Ok. And this question is still active: where is the right place to add the DNS- and NTP-REDIRECT rules for GREEN in /etc/init.d/firewall?

For BLUE it is different:
The REDIRECT rules for BLUE must be added in wirelessctrl.c, because the two rules for DROPPROXY and DROPSAMBA are managed by wirelessctrl.c (line 109ff). The table Firewall options for BLUE interface is shown even if BLUE doesn’t exist. There is no verification here. If BLUE doesn’t exist, this is handled in another way (line 78ff).

In the end, I would perhaps stick to your proposal, but it made me laugh that I overlooked this. We’ll see. Back to keyboard.

Best,
Matthias

EDIT:
Btw, it is very interesting how /var/ipfire/optionsfw/settings is processed:

CONNTRACK_TFTP=on		(init-firewall)
DROPFORWARD=on 			(firewall-policy)
DROPPROXY=off 			(wirelessctrl.c)
CONNTRACK_H323=off		(init-firewall)
DROPNEWNOTSYN=on		(init-firewall)
DROPINPUT=on			(firewall-policy)
SHOWREMARK=on			(firewall.cgi)
FWPOLICY=REJECT			(rules.pl, firewall-policy)
DROPWIRELESSFORWARD=on	(wirelessctrl.c)
SHOWCOLORS=on			(optionsfw.cgi. firewall.cgi)
NTP_FORCE_ON_GREEN=on	???
CONNTRACK_PPTP=off		(firewall.cgi)
DROPOUTGOING=on			(firewall-policy)
SHOWDROPDOWN=on			(firewall.cgi, fwhosts,cgi, optionsfw.cgi)
DROPPORTSCAN=on			(init-firewall, optionsfw.cgi)
CONNTRACK_IRC=off		(init-firewall)
DROPWIRELESSINPUT=on	(wirelessctrl.c)
MASQUERADE_GREEN=on		(init-firewall)
FWPOLICY2=REJECT		(rules.pl, firewall-policy)
SHOWTABLES=on			(optionsfw.cgi. firewall.cgi)
CONNTRACK_SIP=off		(init-firewall)
DROPSAMBA=off			(wirelessctrl.c)
FWPOLICY1=REJECT		(rules.pl, firewall-policy)
CONNTRACK_FTP=on		(init-firewall)
DNS_FORCE_ON_GREEN=on	???

bbitsch · 8 November 2020 19:20

I think thesw settings should be handled in the same place as DROPNEWNOTSYN, DROPOUTGOING, CONNTRACK_xxx, … Means init-firewall or rules.pl.
But I didn’t dig deep enough into the firewall rules processing, yet.

We should discuss this in the devel mailing list, IMHO.

mfischer · 8 November 2020 19:34

Hi,

ACK!

After some tuning, I’ve got the CGI the way that I wanted:

Two “Firewall option”-sections for GREEN and BLUE.
Entries for BLUE are only shown if BLUE exists.

Without BLUE:

With BLUE:

Up to this point these were only preliminary works, further discussions should take place in the mailing list.

Best,
Matthias

jon · 9 November 2020 04:20

What?!? Didn’t I already answer this question? just kidding!

How about here?:

github.com

ipfire/ipfire-2.x/blob/master/config/firewall/rules.pl#L133


      
          
          my $POLICY_INPUT_ALLOWED   = 0;
          my $POLICY_FORWARD_ALLOWED = ($fwdfwsettings{"POLICY"} eq "MODE2");
          my $POLICY_OUTPUT_ALLOWED  = ($fwdfwsettings{"POLICY1"} eq "MODE2");
          
          my $POLICY_INPUT_ACTION    = $fwoptions{"FWPOLICY2"};
          my $POLICY_FORWARD_ACTION  = $fwoptions{"FWPOLICY"};
          my $POLICY_OUTPUT_ACTION   = $fwoptions{"FWPOLICY1"};
          
          #workaround to suppress a warning when a variable is used only once
          my @dummy = ( $Location::Functions::ipset_db_directory );
          undef (@dummy);
          
          # MAIN
          &main();
          
          sub main {
          	# Get currently used ipset sets.
          	@ipset_used_sets = &ipset_get_sets();
          
          	# Flush all chains.

Side thoughts

Concerning Usable under ALL circumstances (above): This may cause problems with pi-hole. I know pi-hole isn’t recommended but it is used by IPFire members.

Scenario: pi-hole would take the DNS request and try and answer via its external DNS server (if config’d that way). The above DNS redirect rule would grab it and redirect it to the local DNS. May cause an issue?

Concerning BLUE must be added in wirelessctrl.c (above): I have my BLUE configured with an external WiFi Access Point and not an internal wireless (WiFi) board. Does BLUE still use wirelessctrl.c for external wifi access points? If not, then this DNS redirect for BLUE may need to go elsewhere also. (hope that made sense)

bbitsch · 9 November 2020 10:29

Concerning BLUE: BLUE is just one interface out of {GREEN, BLUE, RED, ORANGE} ( the standard interfaces of an IPFire system. The rules for this interfaces are mainly set in rules.pl. The forcing of DNS and NTP requests to the internal servers should be done there also for all possible ifs ( GREEN, BLUE ).

mfischer · 9 November 2020 17:51

Hi,

Done. Sent to developer list.

Best,
Matthias

jon · 9 November 2020 18:07

Excellent! Thank you!

jon · 14 November 2020 17:34

I’ve been running what I posted and corrected above in post #65 and all has been working very well for me. I’ve been testing with 10 different DNS servers (including the DNS for ipfire) and monitoring with conntrack. Everything looks like it is being redirected as hoped. NTP redirects are working though I am still trying to figure a better way to test.

Is anyone else testing the DNS/NTP redirects? If so, please add your testing results and your two cents worth to this thread! Your input is needed!

jon · 15 November 2020 22:21

for the record. Here is the command I use to monitor DNS connections on my IPFire box:

conntrack -E -e NEW,UPDATE | grep -e "=53 " -e "=853 "

A big thank you to Andreas @troll-op for telling me about this command! It was a new one for me.

hvacguy · 15 November 2020 23:27

On the redirect client I see their request going to the red ip.
On the none redirect client request going back to client.
If that makes sence.

jon · 16 November 2020 04:09

I am assuming your IPFire box is 192.168.1.1.
And your computer 192.168.1.20

If so, then it looks A-OK to me! You may want to try some other external DNS servers.

But I don’t understand the lines after that from 192.168.1.235

Here is my view:

my laptop is 192.168.60.147
my IPFire box is 192.168.60.1

Test 1 - DNS redirect STARTED using Quad9 DNS

This is with the DNS redirect within firewall.local is started AND trying to use Quad9 as a DNS server:

    [NEW] udp      17 30 src=192.168.60.147 dst=9.9.9.9 sport=60879 dport=53 [UNREPLIED] src=192.168.60.1 dst=192.168.60.147 sport=53 dport=60879
 [UPDATE] udp      17 30 src=192.168.60.147 dst=9.9.9.9 sport=60879 dport=53 src=192.168.60.1 dst=192.168.60.147 sport=53 dport=60879

DNS is redirected from 9.9.9.9 to 192.168.60.1

Test 2 - DNS redirect STARTED using IPFire DNS

This is with the DNS redirect within firewall.local is started AND using the IPFire box as the DNS server:

    [NEW] udp      17 30 src=192.168.60.147 dst=192.168.60.1 sport=52665 dport=53 [UNREPLIED] src=192.168.60.1 dst=192.168.60.147 sport=53 dport=52665
 [UPDATE] udp      17 30 src=192.168.60.147 dst=192.168.60.1 sport=52665 dport=53 src=192.168.60.1 dst=192.168.60.147 sport=53 dport=52665

DNS is 192.168.60.1

Test 3 - DNS redirect STARTED using junk DNS

This is with the DNS redirect within firewall.local is started AND using 1.2.3.4 (junk) DNS server:

    [NEW] udp      17 30 src=192.168.60.147 dst=1.2.3.4 sport=55092 dport=53 [UNREPLIED] src=192.168.60.1 dst=192.168.60.147 sport=53 dport=55092
 [UPDATE] udp      17 30 src=192.168.60.147 dst=1.2.3.4 sport=55092 dport=53 src=192.168.60.1 dst=192.168.60.147 sport=53 dport=55092

DNS is redirected from 1.2.3.4 to 192.168.60.1

Test 4 - DNS redirect STOPPED using Quad9

This is with the DNS redirect within firewall.local is stopped AND using the Quad9 as a DNS server:

    [NEW] udp      17 30 src=192.168.60.147 dst=9.9.9.9 sport=61158 dport=53 [UNREPLIED] src=9.9.9.9 dst=24.xxx.xxx.xxx sport=53 dport=61158
 [UPDATE] udp      17 30 src=192.168.60.147 dst=9.9.9.9 sport=61158 dport=53 src=9.9.9.9 dst=24.xxx.xxx.xxx sport=53 dport=61158

DNS is 9.9.9.9

hvacguy · 16 November 2020 11:13

But I don’t understand the lines after that from 192.168.1.235
That computer is using 8.8.8.8
192.168.3.156 is wan (red)

neutron_head · 17 November 2020 04:08

I have been testing Jon @jon setup from post #65. Looks like it works, both the NTP and DNS preroutes. Thanks for the command in post 96 via Andreas @troll-op. Allowed me to also probe NTP rules. Device 192.168.10.5 is configured to get NTP from firewall 192.168.10.1, but device 192.168.10.151 (which i thought I had manually configured to use the firewall for NTP) is redirected to firewall, at least according to this output:

    [NEW] udp      17 30 src=192.168.10.5 dst=192.168.10.1 sport=123 dport=123 [UNREPLIED] src=192.168.10.1 dst=192.168.10.5 sport=123 dport=123
 [UPDATE] udp      17 30 src=192.168.10.5 dst=192.168.10.1 sport=123 dport=123 src=192.168.10.1 dst=192.168.10.5 sport=123 dport=123
    [NEW] udp      17 30 src=192.168.10.151 dst=137.190.2.4 sport=34816 dport=123 [UNREPLIED] src=192.168.10.1 dst=192.168.10.151 sport=123 dport=34816
 [UPDATE] udp      17 30 src=192.168.10.151 dst=137.190.2.4 sport=34816 dport=123 src=192.168.10.1 dst=192.168.10.151 sport=123 dport=34816

So far looking good

P

hvacguy · 18 November 2020 00:05

Not allowed to use 8.8.8.8 not in my Domain Name Systen.
Is this working?

Do I need firewall rule too?
Looks like it’s not loading or not started.
Used nano easier than Vi.

Make the firewall.local executable:

chmod +x /etc/sysconfig/firewall.local

If running the first time enter:

/etc/sysconfig/firewall.local start

Perhaps upnpd is to blame.? will test latter.
Edited miniupnpd,conf to ports above 1024 and port 88
Do I need to change the default fire wall policy to block first?

trixwood · 15 April 2021 14:34

What do you add, when the dns server is not ipfire itself, but another server in the green zone?

cbrown · 15 April 2021 16:26

You can specify DNS servers, NTP Servers and WINS Servers for your Green zone (and/or Blue zone) nodes via the Network → DHCP configuration web page in the WUI

trixwood · 16 April 2021 11:33

Let me refine, NTP, DHCP, DNS are all separate servers located in the green zone. Not running on the ipfire box itself. DHCP because it easier to configure and maintained with the custom forefront/scripts already created. NTP because it a Stratum-1 server. With fail-over servers, etc… Servers which are working, upgraded and maintained for at least a decade. That I can’t migrate to the ipfire box without breaking things and undercut functionality. NTP for example is stratum 1, etc…

So how do I redirect all the traffic for DNS and NTP request instead as explained above to those servers instead of the ipfire box itself.

bbitsch · 16 April 2021 12:33

That case is a bit more complicated.
IPFire structure uses the DHCP config to do ‘automatic’ tasks.
This config knows about NTP and DNS ( with wpad also about the proxy ). So these informations can be used by the firewall scripts.
If DNS and NTP servers are not in IPFire itself, you must use DNAT. REDIRECT routes to IPFire.
For a quick info see Iptables REDIRECT vs. DNAT vs. TPROXY – What I've learned during GSoC – Here I describe what I've learned during contributing to the netfilter project during my GSoC participation in 2018 hoping that it will help others looking for hard-to find information. ( almost cited by @mfischer above).

jon · 30 May 2022 03:45

Fixed!

https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=21b37391f9769718df7bd726453140f4ec8ff1c0