How to configure traffic redirect with Box 12 KPN to Raspberry Pi?

Hi ​@Imhoteep , you don’t need to redirect the traffic to your pi. It’s the DNS settings that you need to change. By default, they are set to the experiabox’s IP (192.168.2.254)> Instead, set it to the Pi’s IP-address. After that, your client machines must refresh the network connection, so they get the new IP address from the DHCP-server.

Hi ​@XS4-Arjan , thanks for the reply, but unfortinately this is not 100% valid since google-chrome still forces it’s own DNS servers, the same for any other client that decides to change the DNS server in their own settings. This is why I wanted to make sure to force the traffic for port 53 to my pi server. 

I already added the DNS settings and I can reproduce the above with ease in any of my clients. 

Hi ​@Imhoteep , I’m not sure if the experiabox lets you do that. I don’t have one myself...

Thanks for your reply! It’s a shame since the router is really good, WiFi is excellent, don’t want to trade for another one 

Hey ​@Imhoteep. Welcome to the KPN Community! 

Good that you’ve come here to try and get answers to your questions. XS4-Arjan has already tried to point you in the right direction, but that wasn’t quite what you were looking for. I have to admit that I don’t know too much about this myself and don’t personally work with custom DNS or a Pi-hole server. But I can try to tag ​@TDN  or ​@bnh to see if they might know how you can approach this.

Dit kan niet met de KPN Box. Ik denk dat dit met geen enkele provider router kan. Je hebt hier echt een meer uitgebreidere router voor nodig.

Ik zelf gebruik een Opnsense router. Verkeer richting poort 53 redirect ik naar AdGuard. Verkeer naar 853 ook. Dat is DNS over TLS. DNS over HTTPS kan je niet redirecten. Want dat is poort 443. Dezelfde poort als ander internet verkeer. Ik blokkeer wel bekende DNS over HTTPS servers.

​@Imhoteep No, you cannot do this with the ISP router. With your own router, it is possible. By example with OpenWRT

iptables -t nat -I PREROUTING -i eth1 -p tcp --dport 53 -j DNAT --to <PI_IPv4>
iptables -t nat -I PREROUTING -i eth1 -p udp --dport 53 -j DNAT --to <PI_IPv4>
ip6tables -t nat -A PREROUTING -i eth1 -p udp --dport 53 -j DNAT --to-destination <PI_IPv6>
ip6tables -t nat -A PREROUTING -i eth1 -p tcp --dport 53 -j DNAT --to-destination <PI_IPv6>

iptables -t nat -I PREROUTING -i eth1 -p tcp --dport 53 -j DNAT --to <PI_IPv4>
iptables -t nat -I PREROUTING -i eth1 -p udp --dport 53 -j DNAT --to <PI_IPv4>
ip6tables -t nat -A PREROUTING -i eth1 -p udp --dport 53 -j DNAT --to-destination <PI_IPv6>
ip6tables -t nat -A PREROUTING -i eth1 -p tcp --dport 53 -j DNAT --to-destination <PI_IPv6>

En kan de Raspberry Pi dan wel verbinding maken naar buiten op poort 53?

Ja, als hij niet op LAN port 1 aangesloten is, anders moet je een uitzondering instellen. Dit is algemeen mogelijk voor op linux gebouwd router. Specifiek voor OpenWRT is makkelijker

https://openwrt.org/docs/guide-user/firewall/fw3_configurations/intercept_dns

Thank you everyone for all your awesome answers and links!!!

it’s really helpful! 

The only thing you can do is configure under internetverbinding/dns the local ip address of the PI device.

So now all dhcp served devices on the local network ask their DNS requests on the PI except for the OS or devices that bypass this with requests directly to internet DNS of google , etc.

I assume when these are blocked outgoing then they will fallback to the system DNS received via DHCP which ends up in the PI hole.

So then the next step would be to block port 53 specifically towards these internet DNS you want to avoid. For this you need the firewall level ‘’custom” and then choose forward all and make a specific block rule for port 53 with destination ip the DNS server on internet you want to block.

This would not work with an ISP router. The firewall blocks DNS traffic from Pi too.

I don,t see why not. In the custom firewall rules it is possible to set source destination and protocol type and port number. I would then make a source specific rule that filters out all dns 53 to internet except for the ip address of the pi. This way none of the devices can ask dns on the internet except the pi. Thus forcing everything through the pi device.

Because KPN firewall refuses to work as described.

Of course the condition to start with should be a working firewall.

Its not very clear in the screenshot, but why it is expected the client devices to have a dns request with source port 53? I would expect only the destination of the dns request is containing port 53. If the client on 192.168.2.0/24 now tries a dns request it will be from a dynamic port number. Implying thus there would currently be no match in the firewall.

Another thing to take into account the way this firewall function seems to operate is that essentially it is only a single table filled with block or forward rules together. But the first primary button “forward or block all” is more less dictating what is happening further down the table with rules. 

So if the button “forward all” is selected then a basic rule forward all is put on top of the table (invisible in table but created by the button). This is at the same time rendering all the (specific) forward rules that are still visible in this table useless. Because they are all superseeded by this forward all.

In other words it is now in a mode where only the specific (active) block rules make sense.

Selecting the other button “block all” reverses the whole process in still the same single firewall table filled with block and forward rules.

However now in this case there is a generic block all and only the specific forward rules now create the firewall function together.

So coming back to the original story. Thus when a “forward all” is started  and then a block on the whole 192.168.2.0/24 segment (including the PI) is performed then the PI indeeds also would not work (assuming the firewall works correctly). Then the other approach would be to choose the block all button.

And then sort the table based on action and find the existing rule for 53. This rule is then edited and now only the source ip address of the PI is being put in there. 

Theoretically(given the firewall functions) now only the PI is permitted to go out on 53 and the rest of the devices with other 192.168.2.x addresses should now be blocked via the generic block all button function.

The 53 PI forward would then look like :

And the devices need to be informed via dhcp or static all dns request are to be done locally on the PI address.

​@BruisTablet As you can see, I intentionally disabled the rule for PI to block all DNS traffic. However, I can still perform a DNS query via 1.1.1.1 without any problems.

And what button is used block or forward all in the beginning?

Quick function test for the dns part I have done over here is the following:

Select firewall level custom:

Select block all

And set on ip4 and ipv6 rules a disable on the existing 53 dns rule.

It instantly kills my all my outgoing 53DNS requests.

Het is heel belangrijk dat de regels in de goede volgorde staan. Zidat ze ook in die volgorde uitgevoerd worden. Bij de KPN Box kan je volgens mij de volgorde van de regels niet aanpassen. En dat geeft te denken. In de tabel wirden de regels waarschijnlijk in alfabetische volgorde weergegeven. Of op poortnummer. Maar worden ze zo ook uitgevoerd?