Forcing all DNS traffic from the LAN to the firewall

bbitsch · 5 November 2020 10:52

I think you are right.

The ALLOW rules ( in my firewall.local., also ) are for short cut of “well-behaved” DNS requests. There is no REDIRECT/DNAT needed, because they have the right destination already.

mfischer · 5 November 2020 17:43

Hi,

I added BLUE because some of my kids use smartphones from China (sigh) that don’t allow you to configure explicit time servers, for example, or that run applications that refuse to use my DNS servers specified via DHCP. Took me a while to find out what was going on (“DAD!? Its not working! Internet is empty!”).

Running for a while, it looks like this:

INPUTFW (GUI rules):

No REJECTS, only ACCEPTS, as it should be.

And yes - as you wrote - its Belts and suspenders. I would agree to that. If my - manual written - rules in firewall.local are OK, then these are obsolete.

CUSTOMPREROUTING (firewall.local):

Only udp traffic - as it should be. Looks OK for me.

I searched too, and would agree with you. In THIS case, it makes no difference if we use REDIRECT or DNAT rules in firewall.local [Someone please correct me if I’m wrong!]. Its only local.
I’ve found a lot of explanations, one - regarding squid - here. IMHO short and understandable.
E.g., because I used DNAT, I had to add eval $(/usr/local/bin/readhash /var/ipfire/ethernet/settings), so I could use the ${GREEN/BLUE_ADDRESS}-variables (see above #74).

If you use REDIRECT, then these variables are not needed. It is like a special DNAT rule where the new destination address is mandatorily the IP address of the receiving interface.

My conclusion (for now):
Both DNAT and REDIRECT can be used in THIS case, the GUI rules are obsolete and nobody will hurt you. For now.

What puzzles me:
As MT wrote in another topic: YES, I ...simply want a checkbox that prevents clients from using different DNS servers. Is this possible under ALL(!) circumstances and how could this be done/coded?

Best,
Matthias

bbitsch · 5 November 2020 20:22

If we are right with our investigations, this checkbox just produces “our” rules.

I use the REDIRECT rules, too. Investigation with wireshark on my client showed, that the DNS responses are originated from the external DNS server. That means REDIRECT behaves like a DNAT. As far as I understand it.

mfischer · 6 November 2020 17:31

Hi,

I coded a bit:

I know, we’re not that far - but I thought “What the heck…how could this be done!?”

Opinions?

Best,
Matthias

jon · 6 November 2020 17:58

I like it!

Maybe:

Force local DNS server on GREEN (or blue)
Force local IPFire DNS server on GREEN (or blue)
Force all DNS traffic to local IPFire DNS server on GREEN (or blue)

(I am partial to the last one!)

EDIT: added blue and a line of NTP…

Force all NTP traffic to local IPFire NTP server on GREEN (or blue)

hellfire · 6 November 2020 19:33

But don’t forget blue network and maybe NTP protocol, too.

mfischer · 7 November 2020 10:18

Hi,

Done.

CGI is looking good. IMHO. I choosed ‘optionsfw.cgi’ - sounded obvious to me:

[My testmachine has no blue interface so there is no masquerading for BLUE. DNS and NTP check boxes for BLUE are only visible because I cheated a bit.]

The next thing would be to add the appropriate rules in /etc/init.d/firewall, …for changes to take effect.

And at this point I’m not quite sure where to put these rules. At which position exactly? Hints wanted!

And: I’d REALLY like to get some more feedback:

Do we want this?

Is it “feasible” - or necessary?

Is it - see my question in an earlier posting - usable under ALL circumstances?

Perhaps I’m overcautious, but these rules could have “side-effects”…

Best,
Matthias

jon · 8 November 2020 01:00

Looking very nice!

How about here:

to add this:

Firewall options for GREEN interface
Force DNS to use local DNS servers on GREEN
Force NTP to use local NTP servers on GREEN

Firewall options for BLUE interface
Drop all packets not addressed to proxy
Drop all Microsoft ports 135,137,138,139,445,1025

Force DNS to use local DNS servers on BLUE
Force NTP to use local NTP servers on BLUE

Everyone else: please feel free to add your thoughts!

EDIT: I forgot to answer the questions!

Do we want this?
YES!

Is it “feasible” - or necessary?
YES - to me it is necessary.

I have one device that uses 4 different DNS one after the last.
I have one other device that uses a NTP server in Brazil (I am in the US).

Usable under ALL circumstances?
Don’t know. This one I cannot answer. Since it can be enabled/disabled means no will get stuck if it doesn’t work for them.

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)