Discovered folowing:
I set the port of my laptop to the same VLAN as where the pihole resides.
And gues I can access the pihole admin and also ssh is working.
From the native vlan and all other it's not possible,
BTW VLAN to VLAN traffic is not blocked on the firewall.
Cold reboot everything.
Somthing might be glitching while making so many changes.
Ow ps that all looks good:
pi@ph5:~ $ curl -Iv http://10.0.0.4/admin/
* Expire in 0 ms for 6 (transfer 0x563880)
* Trying 10.0.0.4...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x563880)
* Connected to 10.0.0.4 (10.0.0.4) port 80 (#0)
> HEAD /admin/ HTTP/1.1
> Host: 10.0.0.4
> User-Agent: curl/7.64.0
> Accept: */*
>
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
[..]
pi@ph5:~ $ sudo tail -f /var/log/lighttpd/access.log
1601925440|10.0.0.4|HEAD /admin/ HTTP/1.1|200|0
Firewall rules:
VLAN profile set for the Pi-hole (before it was just attached to Server VLAN):
If for example trusted to servers was blocked I woudln't be able to reach the other pihole or my nas.
So inter VLAN routings seems to be working just not when alias Ip's are added to it... weird...
Outa ideas.
I dont have vlan capability or similar HW to help you further ... sorry for that.
EDIT: only one more, check if newer firmware for your HW is available.
Sometimes they have added features or bug fixes.
No problem you have been more then helpfull, at least I can narrow it down some more.
Or maybe someone else nows what could be the problem?
You seem to have done this also, would you have an idea?
Not web related but noticed you have the unbound daemon listening on the same 127.0.0.1:5353 socket as the avahi-daemon who is listening on all 0.0.0.0:5353.
I had DNS time-out problems with above and had to disable the avahi-daemon:
sudo systemctl disable avahi-daemon
sudo systemctl stop avahi-daemon
Google/DuckDuckGo what it does.
EDIT: had daemons wrong way around 
Yea, I understand the difference but don't mind you clarifying for other viewers. My setup is small, with only 4 VLANs (and only two isolated that needed the rules), so the resources are barely touched. However, I can see how it would get much more complicated while a configuration scales out, and doing it the VLAN way would be a better option.
Hi,
Getting crazy tried the whole day...
So for testing purposes I've setup a RaspiPi without Pi-Hole on it, just latest Raspi OS.
After adding VLANS issue remains the same:
Hope someone can help me out...
A crude one until you find a proper fix, hash out below bit in dhcpcd.conf:
interface eth0
static ip_address=..../24
static routers=.....
static domain_name_servers=....
and add below:
denyinterfaces eth0
That way no IP gets assigned to the eth0 interface.
And add an extra aliased IP as replacement in /etc/network/interfaces.d/vlans and dhcpcd.conf for the 10.10.50.41 IP eg:
auto eth0.50
iface eth0.50 inet manual
and:
interface eth0.50
static ip_address=10.10.50.41/24
static routers=10.10.50.1
static domain_name_servers=10.10.50.1
EDIT: maybe you need below two in /etc/network/interfaces.d/vlans to make sure the eth0 interface comes up (I believe dhcpcd does that normally):
auto eth0
iface eth0 inet manual
You did not exactly specify your VLAN configuration to start with.
Your 05.-custom.conf may be motivated by your VLANs, but it is not defining them. It just redirects DNS queries for local domains and reverse lookups for local IPs to specific DNS servers, allowing you to see hostnames for IP addresses that Pi-hole itself possibly wouldn't know any hostnames for.
VLANs are segregating a physical network into separate logical layer 2 networks. Any inter-VLAN traffic has to be dealt with on layer 3, i.e. it has to be routed from one VLAN to another.
If you'd solely been using a VLAN-aware layer 2 switch, that switch by itself wouldn't be able to route traffic between your VLANs.
In that case, defining virtual interfaces on your Pi-hole and tagging them when appropriate may have allowed VLAN traffic to flow to the correct devices connected to your switch. You may've had to configure the L2 switch's port that your Pi-hole is plugged into accordingly.
Sending inter-VLAN traffic to a routing device would be another solution, and maybe the more common approach.
In larger networks, attaching multiple virtual interfaces to a device may spare you one or two hops for same-switch connections if a switch wouldn't be able to handle the routing itself.
If instead of an L2 switch you were using a layer 3 switching device (which could be your router or a dedicated L3 switch), there would be no immediate need to create virtual interfaces on your Pi-hole device: The routing device would take care of routing inter-VLAN traffic.
In your case, my guess would be that your router handled your original VLAN setup. If that has worked to your satisfaction, quite probably there would have been nothing to be gained by reconfiguring Pi-hole with multiple virtual interfaces. It would just complicate your setup.
So, if you were happy with your previous VLAN configuration, I'd recommend to stick with it.
That is true but ... with routing, you would not see individual clients am I correct ?
No, that doesn't change the IP address necessarily, so clients would still show up with their own IP.
Routing just affects the MAC address of Ethernet frames (changing it from origin to gateway). It's NATting that would change the IP address.
Aha oc.
But that leaves only one MAC that will be registered as using Pi-hole
Yes, that's true (and you will find me often mentioning this peculiarity of L3 switching equipment ).
Side note: some Unifi Routers run dnsmasq and can load manual configuration files that offer options that are not available in the GUI. Since pihole is becoming EDNS(0) aware, one can set the add-mac and add-subnet options and pihole will show the real IP and MAC for devices connected in other VLANS (if using the router as DNS server, which in turn uses pihole as upstream). I have this setup at home and it's working very well.
My setup is an Ubiquiti USG router and Ubiquiti POE Switch Gen1 (Gen 2 supports layer 3) who is indeed a "advanced layer 2" switch and to my knowledge inter-VLAN is supported howerver it gets handled through the USG, but for a home network this shouldn't be a problem.
The config I made was like explained on many fora, making the RasPi VLAN aware by installing the VLAN package and activating the 8021q module and then defining my VLANS and all seems to be working fine except for the native vlan of the trunk port of wich my RasPi is connected through.
However above you see the post from @yubiuser wouldn't this be a better aproach? Infact this is the most hassle free install but I didn't want to do it like that in the past because in the Pi-hole log you would only see the IP of the USG instead of it's clients.
Hi,
This seems to be an interesting aproach, would you be willing to explain how to configure this?
My USG runs indeed dnsmasq as DNS server and I know how to add settings not availlable in the GUI (through config.gateway.json). I suppose this wasn't possible in the past since pihole wasn't EDNS(0) aware.
Some info I found:
--add-mac[=base64|text]
Add the MAC address of the requestor to DNS queries which are forwarded upstream. This may be used to DNS filtering by the upstream server. The MAC address can only be added if the requestor is on the same subnet as the dnsmasq server. Note that the mechanism used to achieve this (an EDNS0 option) is not yet standardised, so this should be considered experimental. Also note that exposing MAC addresses in this way may have security and privacy implications. The warning about caching given for --add-subnet applies to --add-mac too. An alternative encoding of the MAC, as base64, is enabled by adding the "base64" parameter and a human-readable encoding of hex-and-colons is enabled by added the "text" parameter.
--add-subnet[[=[<IPv4 address>/]<IPv4 prefix length>][,[<IPv6 address>/]<IPv6 prefix length>]]
Add a subnet address to the DNS queries which are forwarded upstream. If an address is specified in the flag, it will be used, otherwise, the address of the requestor will be used. The amount of the address forwarded depends on the prefix length parameter: 32 (128 for IPv6) forwards the whole address, zero forwards none of it but still marks the request so that no upstream nameserver will add client address information either. The default is zero for both IPv4 and IPv6. Note that upstream nameservers may be configured to return different results based on this information, but the dnsmasq cache does not take account. If a dnsmasq instance is configured such that different results may be encountered, caching should be disabled.
For example, --add-subnet=24,96 will add the /24 and /96 subnets of the requestor for IPv4 and IPv6 requestors, respectively. --add-subnet=1.2.3.4/24 will add 1.2.3.0/24 for IPv4 requestors and ::/0 for IPv6 requestors. --add-subnet=1.2.3.4/24,1.2.3.4/24 will add 1.2.3.0/24 for both IPv4 and IPv6 requestors.
Now the question is, how to implement this so all my VLANS show their correct IP in Pi-Hole.
Thx!
My reply was geared towards answering your initial question:
I was not trying to suggest a certain configuration or to prefer one approach over another then.
But I was indeed wondering why you tinkered with your configuration when you described it as:
Hence my recommendation to keep your config, provided you've been happy with it so far.
I wouldn't rate yubiuser's approach to be better or worse, it would just be another valid option if you had setup your DNS resolution in the same way as yubiuser has.
Since you were already seeing individual clients with your initial configuration, I'd see no immediate reason to alter it.
If you'd prefer to change it nonetheless, I am confident that yubiuser's configuration should work for you as well.
I am also confident @yubiuser is willing to share his knowledge on how he got EDNS(0) running.
One of the reasons I would like to try that aproach is because to me it seems cleaner, the USG router is acting as DNS server and also handles local resolving instead of Pi-Hole (like it was until now, because I had defined the Pi-Hole servers in the DHCP of all the VLANS). So the Pi-hole is used as an upstream DNS filtering device wich in my case resolves then with Unbound. I already tried this in the past and it worked fine but without the EDNS support I always saw the ip of the USG instead of the connected client.
There's only 1 thing I'm not sure off, in my current config I have rules setup in my config.gateway.json to ctach devices that have hardcoded DNS to redirect them to the pihole and also masq the connection.
Code:
"nat": {
"rule": {
"1": {
"description": "Redirect DNS requests",
"destination": {
"port": "53"
},
"inbound-interface": "eth1.10",
"inside-address": {
"address": "10.10.50.40-10.10.50.41",
"port": "53"
},
"source": {
"address": "!10.10.50.40-10.10.50.41"
},
"log": "disable",
"protocol": "tcp_udp",
"type": "destination"
},
"2": {
"description": "Redirect DNS requests",
"destination": {
"port": "53"
},
"inbound-interface": "eth1.20",
"inside-address": {
"address": "10.10.50.40-10.10.50.41",
"port": "53"
},
"source": {
"address": "!10.10.50.40-10.10.50.41"
},
"log": "disable",
"protocol": "tcp_udp",
"type": "destination"
},
"3": {
"description": "Redirect DNS requests",
"destination": {
"port": "53"
},
"inbound-interface": "eth1.30",
"inside-address": {
"address": "10.10.50.40-10.10.50.41",
"port": "53"
},
"source": {
"address": "!10.10.50.40-10.10.50.41"
},
"log": "disable",
"protocol": "tcp_udp",
"type": "destination"
},
"4": {
"description": "Redirect DNS requests",
"destination": {
"port": "53"
},
"inbound-interface": "eth1.50",
"inside-address": {
"address": "10.10.50.40-10.10.50.41",
"port": "53"
},
"source": {
"address": "!10.10.50.40-10.10.50.41"
},
"log": "disable",
"protocol": "tcp_udp",
"type": "destination"
},
"5": {
"description": "Redirect DNS requests",
"destination": {
"port": "53"
},
"inbound-interface": "eth1.90",
"inside-address": {
"address": "10.10.50.40-10.10.50.41",
"port": "53"
},
"source": {
"address": "!10.10.50.40-10.10.50.41"
},
"log": "disable",
"protocol": "tcp_udp",
"type": "destination"
},
"6000": {
"description": "MASQ DNS requests to LAN",
"destination": {
"address": "10.10.50.40-10.10.50.41",
"port": "53"
},
"log": "disable",
"outbound-interface": "eth1",
"protocol": "tcp_udp",
"type": "masquerade"
Do you think this will still work or do I have to edit the "source" for each VLAN now to the DNS gateway echt VLAN?
@yubiuser what's your thought on this?