I hope you all appreciate how much I worked on the above two tests! Just to make sure everyone was paying attention! Yes, it really was a test. I swear!
4 Likes
Thank you Jon! It is a great job.
Regards, Pierre
2 Likes
Hi - back from vacation. (*sigh*)
@Jon: Well done! Great job. 
I’ll have to test this…
After you have discussed and worked this out so extensively, I’m almost a little bit insecure about my settings. But nevertheless - here we go.
@Jon, @troll-op:
This is my current firewall.local since the cited Comment #6. Simple. No magic. I did some modifications since then. It still seems to work, though (hints and corrections are welcome 
):
#!/bin/sh
# Used for private firewall rules
# Read variables
eval $(/usr/local/bin/readhash /var/ipfire/ethernet/settings)
# See how we were called.
case "$1" in
start)
## add your 'start' rules here
# Prevent DNS hijacking - BEGIN
iptables -t nat -A CUSTOMPREROUTING -i green0 -p tcp --dport 53 -j DNAT --to ${GREEN_ADDRESS}:53
iptables -t nat -A CUSTOMPREROUTING -i green0 -p udp --dport 53 -j DNAT --to ${GREEN_ADDRESS}:53
iptables -t nat -A CUSTOMPREROUTING -i blue0 -p tcp --dport 53 -j DNAT --to ${BLUE_ADDRESS}:53
iptables -t nat -A CUSTOMPREROUTING -i blue0 -p udp --dport 53 -j DNAT --to ${BLUE_ADDRESS}:53
# Prevent DNS hijacking - END
# NTP Redirect - BEGIN
iptables -t nat -A CUSTOMPREROUTING ! -o orange0 -p udp --destination-port 123 -j REDIRECT --to-ports 123
# NTP Redirect - END
;;
stop)
## add your 'stop' rules here
# Delete: NTP Redirect - BEGIN
iptables -t nat -D CUSTOMPREROUTING ! -o orange0 -p udp --destination-port 123 -j REDIRECT --to-ports 123
# Delete: NTP Redirect - END
# Delete: Prevent DNS hijacking - BEGIN
iptables -t nat -D CUSTOMPREROUTING -i green0 -p tcp --dport 53 -j DNAT --to ${GREEN_ADDRESS}:53
iptables -t nat -D CUSTOMPREROUTING -i green0 -p udp --dport 53 -j DNAT --to ${GREEN_ADDRESS}:53
iptables -t nat -D CUSTOMPREROUTING -i blue0 -p tcp --dport 53 -j DNAT --to ${BLUE_ADDRESS}:53
iptables -t nat -D CUSTOMPREROUTING -i blue0 -p udp --dport 53 -j DNAT --to ${BLUE_ADDRESS}:53
# Delete: Prevent DNS hijacking - END
;;
reload)
$0 stop
$0 start
## add your 'reload' rules here
;;
*)
echo "Usage: $0 {start|stop|reload}"
;;
esac
Furthermore, I added some REJECT rules via GUI, allowing DNS access only to IPFire, not external:
NAT table:
DNS GUI showed no problems:
For testing, I set DNS server to 1.2.3.4 on one of my PCs and did some nslookups.
The connection table looked as expected and the PC was working without any seen problems:
Results for some nslookups:
That’s all - I did no more. I can put any DNS or NTP-IP on my machines: all DNS queries are sent through IPFire. The main thing was that these rules seemed to work properly. I can’t remember why I choosed DNAT rules, probably it was the first thought I had. And the advantages or disadvantages of my and your version are unfortunately not quite clear to me either.
Therefore - as always! - hints and suggestions are welcome. 
Best,
Matthias
1 Like
Sorry about the vacation ending! There will always be another!
I am way more insecure about my settings then your settings!
I can’t comment on the REDIRECT vs DNAT since I barely understand the REDIRECT.
One of my goals was to try and keep the rule in one place (all in the firewall.local or all in the WebGUI). I was worried if it was split it would be more confusing to enable or disable in two places.
I think it was decided that -o did not work with PREROUTING / CUSTOMPREROUTING.
Here are the references:
EDIT: For your Incoming Firewall Access rules. For the GREEN sources, can you do a screenshot of the whole rule? I think I have the first rule wrong… And maybe the second…
EDIT2:
Here is my guess of your two GREEN source rules pulled out of the iptables. I did not add anything for port 853 (and did not add anything for blue).
# GREEN => 53 (did not add 853)
-A INPUTFW -s 192.168.60.0/24 -d 192.168.60.1/32 -i green0 -p tcp -m tcp --dport 53 -m limit --limit 10/sec --limit-burst 20 -j LOG --log-prefix "INPUTFW "
-A INPUTFW -s 192.168.60.0/24 -d 192.168.60.1/32 -i green0 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUTFW -s 192.168.60.0/24 -d 192.168.60.1/32 -i green0 -p udp -m udp --dport 53 -m limit --limit 10/sec --limit-burst 20 -j LOG --log-prefix "INPUTFW "
-A INPUTFW -s 192.168.60.0/24 -d 192.168.60.1/32 -i green0 -p udp -m udp --dport 53 -j ACCEPT
# GREEN !=> 53 (did not add 853)
-A INPUTFW -s 192.168.60.0/24 -d 24.x.x.x/32 -i green0 -p tcp -m tcp --dport 53 -m limit --limit 10/sec --limit-burst 20 -j LOG --log-prefix "INPUTFW "
-A INPUTFW -s 192.168.60.0/24 -d 24.x.x.x/32 -i green0 -p tcp -m tcp --dport 53 -j DROP
-A INPUTFW -s 192.168.60.0/24 -d 24.x.x.x/32 -i green0 -p udp -m udp --dport 53 -m limit --limit 10/sec --limit-burst 20 -j LOG --log-prefix "INPUTFW "
-A INPUTFW -s 192.168.60.0/24 -d 24.x.x.x/32 -i green0 -p udp -m udp --dport 53 -j DROP
Hi,
Really!? Ok. We’ll see. I’m not so sure about DNAT v.s REDIRECT too. We still can test and compare…
Yep. +1
I also wanted to make sure that no external DNS could be used. So I added the GUI rules.
And yes - while reading this thread I became aware of the -o-Problem in my NTP rules. Just changed them - thanks for reminding me. 
FYI, the GUI rules look like this (please note - I changed the respective colors of DROP and ACCEPT!):
DNS service group:
53, 853 UDP/TCP accepted on BLUE:
53, 853 UDP/TCP accepted on GREEN:
53, 853 UDP/TCP rejected on BLUE:
53, 853 UDP/TCP rejected on GREEN:
IPTables - INPUTFW:
I hope there are no serious errors in this.
Best,
Matthias
EDIT 1: Just thought it over - I think the NTP rule for BLUE isn’t necessary!?
EDIT 2: Correction - The NTP rule IS necassary, I just tested it:
I hope that all of your postings here will finally result in one or two wiki pages?
Right now I’m lost in your conversation, although some of your suggestions are set up already in my IPFire configuration for a long time, but now started to doubt that all runs well here on my side. OTH, I do not have any DSN issues here at the moment…
4 Likes
Same here, I’m following along and appreciate the effort put in by everyone else, but hope that in the end there will be a “final” version added to the Wiki.
1 Like
Hi,
M2c: that’s the goal.
EDIT: Considerations:
By the way, I’m not sure anyway, if these adjustments can be used for ALL thinkable/possible configurations. And if they can/should stay in firewall.local. We’ll see.
But at first we should find something suitable that works. I hope, we’re close to this. In the end, I’d like to keep it as simple as possible.
As always, we (would) need (more) testers and feedback…
Best,
Matthias
1 Like
I’m going to stick to just GREEN for now just to keep things simpler for me!
Thank you for the firewall details pics, that helps me big time! So for the 53, 853 UDP/TCP accepted on GREEN: and 53, 853 UDP/TCP rejected on GREEN: Do you see packets/bytes in the IPTables - INPUTFW??
It is all zeros in the pic above but I thought maybe something was reset/rebooted…
My main question is: why is the rejected / allow rules in the GUI needed if the DNAT (redirect) is in the firewall.local? Belt and suspenders?
I’ve done a little reading on DNAT and REDIRECT. To me REDIRECT looks like a shorten (local only?) version on DNAT.
So to me (and I am probably wrong!) these are the same:
... -j DNAT --to ${GREEN_ADDRESS}:53
-equals-
... -j REDIRECT --to-ports 53
And these are the same:
--destination-port 53 -j REDIRECT --to-ports 53
-and-
--destination-port 53 -j REDIRECT
Disclaimer: I am just learning iptables. Don’t hurt me!
1 Like
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.
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
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.
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
3 Likes
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)
But don’t forget blue network and maybe NTP protocol, too.
2 Likes
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.
- 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.
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:
- 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
3 Likes