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
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
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âŚ
But donât forget blue network and maybe NTP protocol, too.
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
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 GREENFirewall options for BLUE interface
Drop all packets not addressed to proxy
Drop all Microsoft ports 135,137,138,139,445,1025Force 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.
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.
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 ???
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.
Hi,
ACK!
After some tuning, Iâve got the CGI the way that I wanted:
Without BLUE:
With BLUE:
Up to this point these were only preliminary works, further discussions should take place in the mailing list.
Best,
Matthias
What?!? Didnât I already answer this question? just kidding!
How about here?:
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)
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 ).
Excellent! Thank you!
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!
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.
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.
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:
192.168.60.147
192.168.60.1
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
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
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
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
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)
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
Not allowed to use 8.8.8.8 not in my Domain Name Systen.
Is this working?
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?
What do you add, when the dns server is not ipfire itself, but another server in the green zone?