168
Votes

Feature Request - Guest Network separate DHCP/DNS settings

 
168
Votes

Feature Request - Guest Network separate DHCP/DNS settings

237 Reply
Re:Feature Request - Guest Network separate DHCP/DNS settings
2025-05-04 20:17:16

  @mojothemonkey 

 

You can't guarantee that the client will use DNS 2 on the traditional network.
For me, this is a bad idea because the goal of Pi Hole is to handle 100% of traffic through it.

+1 for adding this feature.

With a Pi Hole as a DNS server, the guest network doesn't function like the LAN is isolated.

#217
Options
RE:Feature Request - Guest Network separate DHCP/DNS settings
2025-05-18 20:44:24
I need this feature ASAP please
#218
Options
Re:Feature Request - Guest Network separate DHCP/DNS settings
2025-05-24 06:46:42

same issue with me, running AdGuard Home on my raspberry pi and not being abble to utilize the guest network properly

#219
Options
Re:Feature Request - Guest Network separate DHCP/DNS settings
2025-05-24 14:02:33

Hey @TP-Link

we are several people that have the same problem i all kind of devices... I have 2 X50 that im thinking about selling because of this problem!!!

#220
Options
Re:Feature Request - Guest Network separate DHCP/DNS settings
2025-06-03 23:30:44
I know it's been years and several hundred requests for this feature already, but I want to re-iterate how important this feature is and once again request that it be added. Please allow for different DNS configuration for the main, guest and IoT networks.
#221
Options
Re:Feature Request - Guest Network separate DHCP/DNS settings
2025-06-09 13:54:10

Please just add an exception to local network isolation, so that clients on the guest network can connect to the manual DNS IP address that I set (e.g., 192.168.1.2). This is probably the simplest way to allow a local DNS server such as PiHole to serve all clients on the network (both main and guest).

 

#222
Options
Re:Feature Request - Guest Network separate DHCP/DNS settings
2025-06-23 09:20:37 - last edited 2025-06-23 10:03:46

OK folks, I've got a solution for this, to allow guest clients to reach dns server on main network.
For those that are not afraid of some networking voodoo.
(TL;DR - apply the persistant config further down).

 

So we know that the guest network is on another vlan (591).
Well, the wired connections are actually trunk ports, including guest vlan traffic.
(You can view this traffic with: `sudo tcpdump -ne|grep 'vlan 591'`).

 

First, set your dhcp primary dns to your server on the main network (and no secondary dns).
Then, assuming your wired connection is on eth0 of your dns server, we can add a sub-interface on the vlan with:

 

sudo ip link add link eth0 name eth0.591 type vlan id 591
sudo ip link set dev eth0.591 up
sudo ip addr add 10.10.10.10/32 dev eth0.591  #arbitrary ip. an ip is needed for arp responses.

 

This is enough to process the vlan tagged packets, and deliver them to the kernel.
If you search on your dns server for a guest client ip, you should now see requests reaching the server.

 

For the responses, we'll need some routing to send them back over the guest vlan.
But of course, the guest and main networks are on the same subnet. So destination based routing is no use.
The only thing we have to go on, is that guest requests are coming in from the vlan interface eth0.591.
To solve this, we can use iptables to mark dns connections from this interface:

 

# Mark incoming DNS requests that arrive on eth0.591 (VLAN 591)
sudo iptables -t mangle -A PREROUTING -i eth0.591 -p udp --dport 53 -j MARK --set-mark 591
sudo iptables -t mangle -A PREROUTING -i eth0.591 -p tcp --dport 53 -j MARK --set-mark 591

# Save the mark to the connection tracking table (CONNMARK)
sudo iptables -t mangle -A PREROUTING -i eth0.591 -p udp --dport 53 -j CONNMARK --save-mark
sudo iptables -t mangle -A PREROUTING -i eth0.591 -p tcp --dport 53 -j CONNMARK --save-mark

# Restore the mark on *outgoing* response packets
sudo iptables -t mangle -A OUTPUT -p udp --sport 53 -j CONNMARK --restore-mark
sudo iptables -t mangle -A OUTPUT -p tcp --sport 53 -j CONNMARK --restore-mark

 

Then route the responses using the mark (and a new table):

 

sudo ip rule add fwmark 0x24f lookup 591 priority 100
sudo ip route add 192.168.68.0/22 dev eth0.591 table 591  #substitute your LAN subnet here

Bosh!

 


Persisting the config..

 

You will need:
* netplan, using networkd renderer.
* networkd-dispatcher service running.

 

Append vlan config to /etc/netplan/01-netcfg.yaml:

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: yes

  vlans:
    eth0.591:
      id: 591
      link: eth0
      addresses:
      - 10.10.10.10/32
      routes:
      - to: 192.168.68.0/22   #substitute your LAN subnet
        table: 591
        scope: link
      routing-policy:
      - from: 0.0.0.0/0
        mark: 591
        table: 591
        priority: 100

 

 

Create /etc/networkd-dispatcher/routable.d/90-vlan591:

#!/bin/bash
[[ "$IFACE" == "eth0.591" ]] || exit 0
iptables -t mangle -A PREROUTING -i eth0.591 -p udp --dport 53 -j MARK --set-mark 591
iptables -t mangle -A PREROUTING -i eth0.591 -p tcp --dport 53 -j MARK --set-mark 591
iptables -t mangle -A PREROUTING -i eth0.591 -p udp --dport 53 -j CONNMARK --save-mark
iptables -t mangle -A PREROUTING -i eth0.591 -p tcp --dport 53 -j CONNMARK --save-mark
iptables -t mangle -A OUTPUT -p udp --sport 53 -j CONNMARK --restore-mark
iptables -t mangle -A OUTPUT -p tcp --sport 53 -j CONNMARK --restore-mark

and make executable:

sudo chmod +x /etc/networkd-dispatcher/routable.d/90-vlan591

apply:

sudo netplan apply
#223
Options
RE:Feature Request - Guest Network separate DHCP/DNS settings
2025-06-26 02:31:16
Local guess network doesn't work
#224
Options
RE:Feature Request - Guest Network separate DHCP/DNS settings
2025-06-28 13:06:00
Thisnfeature would be useful. Seperate IoT network setting too
#225
Options
RE:Feature Request - Guest Network separate DHCP/DNS settings
2025-06-30 19:45:34
pleas add separate DHCP-DNS to Guest Network
#226
Options