Recently I thought about setting my router so that the guest network (different subnet, isolated from the "main" one) would use the same pi-hole as a DNS server (and only DNS, router is the only DHCP server here)
I've followed some generic manuals how to create an additional interface. Here's what I've added:
The thing is, the interface does exist, looks like it's running but when I try to ping gateway or some other device on that network tries to ping pi, it's not working.
arp ran on router shows the pi IP on the 2nd network but either as:
? (192.168.12.7) at on ath1.1
or
? (192.168.12.7) at 00:12:34:56:78:90 [ether] on br0
the difference being that if there's no eth0:1 defined in the /etc/dhcpcd.conf, I get the former.
ath1.1 is the virtual interface with separate SSID used as the guest network
Since any device that's on the 2nd network can ping the gateway and not the pi, I suspect it's not a router configuration issue (it's running dd-wrt if anyone's wondering), rather something missing on the pi. The thing is, I'm out of ideas here. Setting and forcing the ip route manually solves nothing. What am I missing?
You should have the route in any case, are you sure you set up the route correctly? All you're describing very much sounds like a route issue. The device just doesn't know how to ping because it doesn't know where.
Thinking again about it, this is interesting:
Even if there is no route for this network on the Pi, shouldn't it at the very least be reachable from the outside? Maybe not, because it cannot reply. I'm just thinking while I'm writing. Still, I will keep my thinking here, maybe it is useful to spark an idea
What is the output of
ip a
Maybe it is. How have you configured your router to "isolate" the network? Is this just because they receive different IP ranges? So if I come to your house, you give me guest access and I change my subnet to /16, I can still access all devices in your local network (which I shouldn't see), right? I just want to get an idea what you want to do exactly.
You are trying to configure two gateways on the same machine where Linux will allow exactly one default gateway in a routing table, and there is commonly only one routing table.
Depending on your system, you'd have to cater for multiple default gateways yourself. This would involve creating additional routing tables as required as well as adding respective routing rules to it.
You could also define multiple gateways using metrics, but that would likely not produce what you want, as traffic still would get routed through a single gateway only (i.e. the best metric available one).
It may be easier to stick with just one interface (or at least use the same gateway) on your Pi-hole and configure proper routing in your router instead.
In either case, as this is a networking rather than a Pi-hole issue, you may improve your chances for hints applicable to your specific setup by consulting your router's manual and/or other networking focussed sites.
There was one, but it didn't show eth0:1 explicitly, so I thought that maybe the traffic to the 2nd subnet wanted to go through the eth0. I've removed it, added it manualy but it looks like "ip route" either doesn't show virtual interfaces, just the physical one or traffic cannot be forced to go through the virtual interface.
Yeah, sure. The weird thing is, it appears with its ip, but cannot be reached. I'm not that much into networking so be able to determine what's exactly wrong here. I suspect what I wrote above, but I'm not sure, it's just an idea. The fact that some tools don't seem to work with virtual interfaces (ping, traceroute) doesn't make it any easier for me.
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: usb0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether 02:6b:10:1e:71:da brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether [here's the mac] brd ff:ff:ff:ff:ff:ff
inet 192.168.12.7/24 brd 192.168.12.255 scope global eth0:1
valid_lft forever preferred_lft forever
inet 192.168.1.7/24 brd 192.168.1.255 scope global noprefixroute eth0
valid_lft forever preferred_lft forever
inet6 fe80::2e0:4cff:fe36:94f/64 scope link
valid_lft forever preferred_lft forever
I've set an additional virtual interface with its own, separate dhcp range. Initially I had AP isolation enabled, but I've disabled it for debugging purposes. However, that didn't change anything. With or without it, a client connected to the 2nd network could at least ping the gateway. Pi doesn't seem to be able to do that (right now).
As for changing the mask from 24 to 16 - it wouldn't. There's a separate setting for that, called Net Isolation. With that enabled, any client from the 2nd subnet cannot talk to devices in the 1st one and vice versa. That's the sole reason why I'm trying to set up that thing. No point in setting "guest" network if the only difference is the SSID, right?
I know that this isn't bunny hill for Linux users, but what's the difference between having 2 physical interfaces and defining IP, mask and gateway for them and having 1 physical and 1 virtual one and setting those in the same fashion? Why wouldn't (shouldn't) that work? It's not Windows, which gets dizzy if you use more than one network interface and don't define routing manually... I've used Linux machines that had 8 interfaces (8 physical ones, I admit), every single one on different net, vlan and it all worked flawlessly. I bumped into a problem like that for the first time ever.
On that I can agree, I've already posted a question somewhere else. If I could easily set up that, I'd post a feature request to add multiple interfaces so pihole could be used in an environment where one has set up multiple subnets and doesn't want to set up few raspberries to basically do the same thing.
The first actually connects the two interfaces to the two network segments.
The second depends if your router has routes defined for the two IP's on the same physical interface (likely not) and if traffic isnt blocked by other means between the two network segment.
Easiest would be to configure the router WAN/Internet DNS settings to point to Pi-hole only (no other DNS servers).
That way, the clients in both networks will get the router IP for DNS via the router DHCP, and the router forwards DNS queries to Pi-hole.
But that would result in not seeing individual stats for the clients on the web GUI as all the DNS queries seems to originate from the router (from Pi-hole's point of view).
Another more difficult aproach would be to connect the Pi-hole host to both networks, if have two physical network interfaces.
Disable the router DHCP and enable the one on Pi-hole.
And manually configure the pihole-FTL daemon (with dnsmasq embedded) to hand out two different DHCP ranges for the two isolated networks.
But that means you have to go through dnsmasq DHCP options and manually setup your own config file in the /etc/dnsmasq.d/ folder:
So it looks like the additional subnet is completely separate from the "cabled" network. 192.168.12.x subnet doesn't forward any traffic to the primary bridge (and that's actually ok, those 2 shouldn't be connected) but the consequence of that is, that anything on that network will try to search for raspberry on the wlan, omitting lan ports. I'd have to either punch a hole so clients on the 2nd subnet would be allowed to talk with a certain lan port to which pi is connected and that should do the trick.
In the end, it looks I might have set up the 2nd interface on the raspberry correctly, it's the router's "fault" - or rather its tightened security, which is responsible for the lack of communication.
The routes on the raspberry were created the moment I added 2nd network interface and probably were set up right (I'll verify that at some point), so it looks like changing/adding anything by hand won't be needed.
As for the pointing - that's what I had in mind from the beginning (before I thought about setting a guest network), but I went down the road where the router handles DHCP and I set up conditional forwarding - that way I can see individual clients. It just works.
Ahh, my bad. In any case, I'll probably end up doing something that I've described above, I'll test the config and report back, in case someone else has a similar question and will seek for an answer
