I'm running pihole version v5.1.1 on Raspbian stretch on a Raspberry Pi 3 Model B.
I'm trying to serve both wired and wireless networks. The wired interface eth0 is on 192.168.1.20 and the wireless interface is on 192.168.1.19.
Here's the tricky bit: my local network is managed by a TP-Link Archer C7 router (V2). The wired network is trusted, but the wlan0 interface is connected to the "guest" network. The problem I'm trying to solve is to serve DNS primarily on the guest network while maintaining access to the device from the wired network.
What I think should be happening: the Pi should respond to ping on the wired network at 192.168.1.20 and on the guest wireless network at 192.168.1.19.
Actual Behaviour:
When both interfaces are connected, the Pi responds only on the wired network. And it responds on the wired network to both IP addresses. From the wireless guest network, 192.168.1.19 does not respond to ping.
When the wired interface is disconnected, the Pi responds to ping on the wireless guest network, but not on the wired network. And only on address 192.168.1.19.
The problem I'm ultimately trying to solve is to serve DNS on the wired network. I tried a clever workaround---tell the router to use the Pi as its WAN DNS server. Unfortunately the Archer C7 has a conniption fit---it does not like the idea of a machine on the local subnet acting as the ultimate DNS server.
I have seen a few suggestions that it's bad to have both eth0 and wlan0 be on the same subnet. I don't have a strong opinion either way, but it may be worth pointing out that I have no issues using the Pi itself (when the eth0 is connected). It seems to make outgoing connections just fine. It's the response to ping that concerns me. And I don't know whether responding to 192.168.1.19 to the wired network (and not the wireless one) is the fault of the Pi or if for some reason I should blame the router.
Routers commonly implement guest networks defining a specific subnet, isolating it from the rest of your standard network.
That subnet is distinctively different from the router's standard network, e.g. your router may manage 192.168.1.0/24 as standard and 192.168.2.0/24 as guest network.
In your case, it would seem that both IPs for your Pi-hole machine lie within your standard network subnet only.
For the network interface that handles connections to the wifi guest network, pick an IP address that matches the guest network's subnet.
Unfortunately, my router puts everything on the same subnet. Inspecting the "DHCP guest list" page on the router confirms that all devices, wired and wireless, are assigned IP addresses on 192.168.1.0.
The router's guest-network settings are quite limited. Aside from SSID and password, I can limit access in a couple of ways (not useful on my network) and I can allow devices on the guest network to access the LAN (which is what I'm trying to avoid by having a guest network in the first place).
It may be worth noting that I am not allowing the Pi to pick its own IP addresses---it is a DHCP client, and the router is picking addresses for it. I have both MAC addresses hard-wired to IP addresses I've chosen, so that the Pi's DNS service can be found at a predictable IP address, but the hard-wiring is done in the router, not by the Pi.
Any idea why the Pi might agree to serve wireless packets when eth0 is disconnected but not when it's connected? There's no change to the Pi software; I just unplug the cable.
That's a strange concept for guest networks. I wonder how they isolate guest devices from the rest of the nework then.
I usually see routers using VLANs to achieve this, defining a virtual wifi port or interface and maybe dedicating a certain LAN port for guests as well. Normally, they'd attach a dedicated DHCP range to those ports.
I'm speculating: If your TP-Link would do it similarly, just skipping the dedicated IP range part, it could be that packets still carry VLAN tags when arriving at your Pi-hole machine (though I'd expect a router to strip them before forwarding). In that case, it may help to make your Pi-hole machine VLAN aware:
sudo apt-get install vlan
sudo modprobe 8021q
But that's just a wild guess, really.
Surely, routing could well be somehow involved in this, but it could be your router as well as your Pi-hole machine.
Note that if you've two interfaces attached to the same network, essentially using the same gateway, it's their respective metrics that will decide which interface will be used. Normally, that shouldn't be much of an issue, but as interfaces constitute some sort of different network qualities (standard vs. guest) in your case, it'd seem that could be causing your troubles.
I am by no means familiar with your TP-Link device, so consider the above as the speculations I tried to mark it as.
I did some followup and some experiments. It appears to be a limitation of Linux that if two network interfaces are active and are serving the same IP subnet, the hardware uses one of those interfaces exclusively. I confirmed this behavior by connecting a Linux laptop to the same network in the same way and running Wireshark. Although both interfaces (eth0 and wlan0) work independently, when both are active Wireshark sees packets only on the interface with higher routing priority. My guess is that as long as the router insists on putting the main network and the guest network on the same subnet, the problem cannot be solved.
Yes, that is normal routing behaviour.
I doubt that your RPi's routing contributes to your problem, though.
IP routing is indifferent to the medium ist transported over. You don't need wifi to be active on a server to serve wifi clients.
I'd focus on the router to try tackling this issue: It's your router that controls traffic flow between ist defined networks.
I hence still suspect it's the way your router handles its VLAN guest network that's causing you troubles. The fact that you try to connect your RPi 3B to it via wifi would be just a coincidence then.
The pi is connected to the "guest network" SSID, which is the only way to get the router to send packets to it from other devices on the guest network. I had hoped I could get the pi to listen to the guest network on wlan0 and the regular network on eth0. Alas, it will not.
It's not a limitation of linux, it's how TCP/IP networking works. If you have one device with two interfaces on the same exact network segment/collision domain then you have to have a preferred route, you can't send TCP packets as a "best attempt" like UDP.
Sending isn't my issue. Receiving is my issue. I'm told (on the Linux boards) that the unwillingness to receive on both interfaces is a fundamental limitation of the Linux TCP/IP stack.
I'm going to try the bridge interface recommended by @deHakkelaar
pi@ph5:~ $ man dhcpcd.conf
[..]
denyinterfaces pattern
When discovering interfaces, the interface name must not
match pattern which is a space or comma separated list of
patterns passed to fnmatch(3).
[..]
Just have to make sure the network mangler dhcpcd5 doesnt assign IP's to the two interfaces.
At time of writing that howto, I wasnt that familiar with dhcpcd5.
