Dual subnet network - wired & wireless

Expected Behaviour:

Pi-Hole connected to two subnets AND both use Pi-Hole DNS.

Actual Behaviour:

Hello! I know I've seen this issue and solution posted but I cannot locate. I think I am searching for the wrong words. I thought I had read Pi-Hole could work on two networks after including a second Network. So I added a USB-to-Ethernet adapter and set it up as a static address. But no Pi-Hole DNS on the wireless network.

My Wired network is

My Wireless network is

DHCP is provided by a firewall. DNS from Pi-Hole.

The Pi-Hole is currently connected and working perfectly on the wired network. Pi-Hole is and is using eth0.

I went to the menu Settings > DNS tab > Interface listening behavior and enabled Listen on all interfaces.

I added a USB-to-Ethernet adapter to the Pi-Hole and set it up as a static address. It connect to the wireless network as a wired device at via eth1.

My test machine is a laptop connected to the wireless network and with the DNS set to I can connect to the Pi-Hole web interface via the Wireless network. No issues there.

But nothing good happens. And I cannot find the post I thought I saw and I was not able to find what I needed in the docs.

Info: Pi-hole v5.3.1 / Web Interface v5.5 / FTL v5.8

So I am guessing I am missing a a few more steps... Is the above possible? Or should I build up a second Pi-Hole for the wireless?

Pi-hole can only listen on interfaces that have content. If you have two VLANs, port 53 traffic has to be able to transit between them. That's an issue in your firewall, I would suspect.

What is the resolver config on your wireless clients? Are they taking the DNS config from the DHCP server? If those clients support it, nslookup/dig/drill are your friends here.

If the resolver is not hard configed in the wireless clients, What is the DNS server configured on the DHCP scope?

Can those wireless clients ping

Is the pihole listening on port 53 on

Mine looks like this ...

netadmin@namepi:~ $  sudo netstat -ltunp | grep ":53 "
tcp        0      0*               LISTEN      9387/nsd            
tcp        0      0*               LISTEN      28874/unbound       
tcp        0      0  *               LISTEN      16927/pihole-FTL    
tcp        0      0*               LISTEN      16927/pihole-FTL    
tcp        0      0 *               LISTEN      16955/systemd-resol 
udp        0      0*                           9387/nsd            
udp        0      0*                           28874/unbound       
udp        0      0  *                           16927/pihole-FTL    
udp        0      0*                           16927/pihole-FTL    
udp        0      0 *                           16955/systemd-resol 
netadmin@namepi:~ $ cd /etc/dnsmasq.d/

My setup has an additional config file under /etc/dnsmask

netadmin@namepi:/etc/dnsmasq.d $ cat 10-mypiholesetup.conf 

Where that listen-address is a comma separated list of addresses to listen on.

Hope some of this helps.


Hello jfb and Harry! Thank your for your responses!

One big question from me: What is the purpose of enabling Listen on all interfaces? Is this it to do what what I am trying? Or am I forcing a square peg into a round hole?

I'm not sure what this means. There is network traffic on this network. And I can ping the eth1 interface via

My setup is not a VLAN. Two network ports from the firewall. Both on separate subnets.

No. Right now I am only testing with my laptop and the DNS is set to No other DNS servers. The DNS setting is manually configured. So not taken from the DHCP server at this time.

Yes. And I can access the Pi-Hole webgui at

I am guessing this is the problem. Or part of the problem.

  • FYI - I only use Pi-Hole for DNS and not for DHCP.
pi@pihole:~ $ sudo netstat -ltunp | grep ":53 "
tcp        0      0    *               LISTEN      607/pihole-FTL      
tcp6       0      0 :::53                   :::*                    LISTEN      607/pihole-FTL      
udp        0      0    *                           607/pihole-FTL      
udp6       0      0 :::53                   :::*                                607/pihole-FTL      
pi@pihole:~ $ 

I've not used this before. What does this do?

FYI - this is what I see in the /etc/dnsmasq.d directory. I did see the note not to change the 01-pihole.conf file.

pi@pihole:~ $ ls -al /etc/dnsmasq.d
total 12
drwxr-xr-x  2 root root 4096 May  7 22:35 .
drwxr-xr-x 87 root root 4096 Apr 16 13:15 ..
-rw-r--r--  1 root root 1485 May  7 22:35 01-pihole.conf
pi@pihole:~ $ 

Pi-hole is effectively a customised dnsmasq installation, or at least pihole-FTL the DNS part of pihole is.

The default pi-hole config is set in 01-pihole.conf. You do not want to mess with that file as pi-hole updates will overwrite it. The settings in that file can be modified via the GUI.

That file probably contains the line:

I believe that means listen on all interfaces except nonexisting ones.

From the dnsmasq manual:

    -i, --interface=<interface name>
              Listen only on the specified interface(s). Dnsmasq automatically adds the loopback (local) interface to the list of interfaces  to  use  when
              the  --interface  option  is used. If no --interface or --listen-address options are given dnsmasq listens on all available interfaces except
              any given in --except-interface options. On Linux, when --bind-interfaces or --bind-dynamic are in effect,  IP  alias  interface  labels  (eg
              "eth1:0")  are checked, rather than interface names. In the degenerate case when an interface has one address, this amounts to the same thing
              but when an interface has multiple addresses it allows control over which of those addresses are accepted.  The same effect is achievable  in
              default  mode  by using --listen-address.  A simple wildcard, consisting of a trailing '*', can be used in --interface and --except-interface

If you add a lexically "later" file in that directory, that is processed after the standard pi-hole set up and you can put additional config for your pihole there and pihole update will leave it alone. All the dnsmasq config directives are valid for pi-hole. man dnsmasq for the full gory detail

 -a, --listen-address=<ipaddr>
              Listen on the given IP address(es). Both --interface and --listen-address options may be given, in which case the set of both interfaces  and
              addresses  is  used. Note that if no --interface option is given, but --listen-address is, dnsmasq will not automatically listen on the loop‐
              back interface. To achieve this, its IP address,, must be explicitly given as a --listen-address option.

This option is telling dnsmasq to listen on that ip address for DNS requests.
My requirement is slightly different to yours, my pi-hole server is configured with multiple ip addresses running multiple nameservers, and pi-hole should only answer queries to that specific address, and the loopback address.

By default I believe dnsmasq answers queries to all addresses.
The result from your netstat query above seems to support this.
(That's what the first on the lines in your netstat reports indicates I believe, and will respond to queries from anywhere as the second* .in your netstat report suggests.)

You can access the GUI and ping the "wireless side" interface from the wireless network, there does not appear to be anything preventing queries reaching the pihole server. So I'm puzzled...

As a test you could consider setting both --interface and --listen-address explicitly in the extra config file. The explicit listen addresses should than show up in the netstat report, and possibly change the behaviour.

If you install tcpdump or tshark on the pihole server, you can inspect the traffic arriving on that interface


Good news / bad news. Based on your advice I think I got things working. I'll go through things...

Good News

This comment helped me the most! I thought the DNS was dnsmasq. But I couldn't find it running as an active process. I didn't realize it was wrapped in pihole-FTL. Thank you!

I installed tcpdump and that also helped! I ran sudo tcpdump host -i eth1 and saw lots of requests but zero replies.

No. There was no except-interface in the file 01-pihole.conf. This is what I saw:

pi@pihole:~ $ cat /etc/dnsmasq.d/01-pihole.conf

# Pi-hole: A black hole for Internet advertisements
# (c) 2017 Pi-hole, LLC (https://pi-hole.net)
# Network-wide ad blocking via your own hardware.
# Dnsmasq config for Pi-hole's FTLDNS
# This file is copyright under the latest version of the EUPL.
# Please see LICENSE file for your rights under this license.

#                                                                             #
#                      /etc/pihole/setupVars.conf                             #
#                                                                             #
#                    WITHIN /etc/dnsmasq.d/yourname.conf                      #








pi@pihole:~ $ 

I added a new file named /etc/dnsmasq.d/02-my_pihole.conf


I wasn't sure how to reload dnsmasq so I ran sudo service pihole-FTL restart. And "boom" things started to work. Everything seemed to be going through Pi-Hole on both wired & wireless networks. Yay! Success!

Now the bad news

So I wanted to document (yes here!) what you had told me and what I had done. But when I deleted my /etc/dnsmasq.d/02-my_pihole.conf file and restated via sudo service pihole-FTL restart nothing changed. I also tried rebooting my Pi-Hole box. I could NOT get my changes to stop working. This doesn't make sense!

I tried clearing the browser cache - no joy. I cleared the local DNS cache on my Mac via sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder - also no joy.

Is there something within Pi-Hole that needs to be cleared or changed to put things back to the beginning?

No real help from me here. I do not know why your set up did not work originally, so I'm not entirely sure that simply restarting pi-hole would not have resolved the issue. :frowning:

Using the "standard" network set up on the pi is really really irritating at the best of times, the interaction between NetworkManager, avahi-daemon, dhcpcd, wikd and wepa-supplicant generates all kinds of odd behaviour, all of them thinking they know better than me how to configure a network.

I don't use that set up at all, I'm using networking based on systemd-networkd, with the wireless set up disabled. It at least does as its told...


1 Like

One thought at the back of my mind, is that what you have set up is known in IP parlance as a "dual homed host". Linux's default ARP behaviour is "odd". It's of no consequence if you have only one network interface, but can cause issues with more interfaces.

In essence the default Linux behaviour stems from an oddity of Sun networking. The concept is that the MAC address belongs to the system, not the interface. Sun's used to have only one MAC address, so that never gave issues. With more interfaces, and other systems that expect an MAC address to be related to a specific interface that is not true.

By default a Linux system will respond to an ARP request on an interface for any IP that the system owns, with the MAC address that corresponds to the interface with that IP , even if the IP address is bound to another interface on the box.

explanation here, from notes on kernel.org:

arp_filter - BOOLEAN
	1 - Allows you to have multiple network interfaces on the same
	subnet, and have the ARPs for each interface be answered
	based on whether or not the kernel would route a packet from
	the ARP'd IP out that interface (therefore you must use source
	based routing for this to work). In other words it allows control
	of which cards (usually 1) will respond to an arp request.

	0 - (default) The kernel can respond to arp requests with addresses
	from other interfaces. This may seem wrong but it usually makes
	sense, because it increases the chance of successful communication.
	IP addresses are owned by the complete host on Linux, not by
	particular interfaces. Only for more complex setups like load-
	balancing, does this behaviour cause problems.

	arp_filter for the interface will be enabled if at least one of
	conf/{all,interface}/arp_filter is set to TRUE,
	it will be disabled otherwise

arp_announce - INTEGER
	Define different restriction levels for announcing the local
	source IP address from IP packets in ARP requests sent on
	0 - (default) Use any local address, configured on any interface
	1 - Try to avoid local addresses that are not in the target's
	subnet for this interface. This mode is useful when target
	hosts reachable via this interface require the source IP
	address in ARP requests to be part of their logical network
	configured on the receiving interface. When we generate the
	request we will check all our subnets that include the
	target IP and will preserve the source address if it is from
	such subnet. If there is no such subnet we select source
	address according to the rules for level 2.
	2 - Always use the best local address for this target.
	In this mode we ignore the source address in the IP packet
	and try to select local address that we prefer for talks with
	the target host. Such local address is selected by looking
	for primary IP addresses on all our subnets on the outgoing
	interface that include the target IP address. If no suitable
	local address is found we select the first local address
	we have on the outgoing interface or on all other interfaces,
	with the hope we will receive reply for our request and
	even sometimes no matter the source IP address we announce.

	The max value from conf/{all,interface}/arp_announce is used.

	Increasing the restriction level gives more chance for
	receiving answer from the resolved target while decreasing
	the level announces more valid sender's information.

arp_ignore - INTEGER
	Define different modes for sending replies in response to
	received ARP requests that resolve local target IP addresses:
	0 - (default): reply for any local target IP address, configured
	on any interface
	1 - reply only if the target IP address is local address
	configured on the incoming interface
	2 - reply only if the target IP address is local address
	configured on the incoming interface and both with the
	sender's IP address are part from same subnet on this interface
	3 - do not reply for local addresses configured with scope host,
	only resolutions for global and link addresses are replied
	4-7 - reserved
	8 - do not reply for all local addresses

	The max value from conf/{all,interface}/arp_ignore is used
	when ARP request is received on the {interface}

arp_notify - BOOLEAN
	Define mode for notification of address and device changes.
	0 - (default): do nothing
	1 - Generate gratuitous arp requests when device is brought up
	    or hardware address changes.

arp_accept - BOOLEAN
	Define behavior for gratuitous ARP frames who's IP is not
	already present in the ARP table:
	0 - don't create new entries in the ARP table
	1 - create new entries in the ARP table

	Both replies and requests type gratuitous arp will trigger the
	ARP table to be updated, if this setting is on.

	If the ARP table already contains the IP address of the
	gratuitous arp frame, the arp table will be updated regardless
	if this setting is on or off.

Coupled with that Linux these days does not permit asymmetric routing:

Notes on asymmetric routing

Systems with their ARP cache polluted by the "generous" ARP arrangement that Linux uses by default, can find that they are blocked from communicating with a host as their traffic is sent to the "wrong" interface (ie not the one that sent the initial request) and is silently dropped by the target hosts routing filter.

My solution is to put this file in /etc/sysctl.d/sane-arp.conf

netadmin@backdoorpi:/etc/sysctl.d $ cat sane-arp.conf 
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.all.arp_filter = 1
net.ipv4.conf.all.arp_ignore = 1

setting the ARP configuration to something less "generous" , and more in line with the rest of the universes assumption that mac addresses relate to specific interfaces.

I'm by no means sure that this is in any way related to the issue you had, but it is one of the ways that very odd network behaviour can be triggered on dual home hosts.

It's also probably impossible to reproduce, since whatever event triggered the ARP cache pollution, if that was the cause, could be timing related, and or order of connection, or restart of one of the hosts.


1 Like

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.