Set overriding dhcp tag for default subnet

Help Community Help
1

I have put the following into ‘misc.dnsmasq_lines’:

# Main (VLAN1)
dhcp-range=set:vlanmain,192.168.1.150,192.168.1.253,255.255.255.0,24h
dhcp-option=tag:vlanmain,option:router,192.168.1.1
dhcp-option=tag:vlanmain,option:dns-server,192.168.1.20,192.168.1.21

# IoT (VLAN3)
dhcp-range=set:vlaniot,192.168.3.150,192.168.3.253,255.255.255.0,24h
dhcp-option=tag:vlaniot,option:router,192.168.3.1
dhcp-option=tag:vlaniot,option:dns-server,192.168.3.20,192.168.3.21

‘vlanmain‘ range and router settings are the same as what is on the DHCP settings page.

VLAN3 devices do get the ‘vlaniot‘ tag.

Expected Behaviour:

I would expect VLAN1 devices to get the ‘vlanmain‘ tag.

Actual Behaviour:

VLAN1 devices only get ‘eth0‘ tag, and for static dhcp lease devices an additional ‘known‘ tag.

I tried to delete dhcp leases file and to reboot pi-hole, but same result.

2

How is Pi-hole/embedded dnsmasq to distinct between the two VLANs with only those two new tag names (vlanmain & vlaniot)?

In below Pi-hole v5 example with a Pi-hole host thats got multiple interfaces, the tag is set to the physical interface name (eth1) to distinct between the two:

You cant have multiple DHCP ranges if the Pi-hole host only has one interface bc of the broadcast nature of DHCP.
DNS and HTTP etc are all unicast.

3

Your dhpc-ranges don't match any interfaces, so I'm not sure how you'd intend to relate those tags to your VLAN interfaces.

Typically, you'd match DHCP options depending on interfaces (where such an interface may belong to a VLAN), e.g. if your host would carry two virtual interfaces eth0.10 and eth0.20:

dhcp-range=eth0.10,192.168.10.20,192.168.10.200
dhcp-option=eth0.10,option:router,192.168.10.1

dhcp-range=eth0.20,192.168.10.20,192.168.20.200
dhcp-option=eth0.20,option:router,192.168.20.1
4

Oh above is not entirely true.
You can do some trickery if make the Pi-hole host VLAN aware which it istn OOTB with most distros.
But that means complicating your setup substantially with virtual VLAN aware interfaces bc embedded dnsmasq does nothing with VLAN tags (not the same as a dnsmasq tag).

5

I believe above can only work if you make the interfaces VLAN aware?
I dont see how dnsmasq can distinct between the two with the initial DHCPDISCOVER broadcast from a client?
Wont both virtual interfaces, with eth0 being the parent interface, receive the initial DHCPDISCOVER broadcast?
Eg from no IP to 255.255.255.255.

6

First, thank you all for your responses.

Some details:

That being said, in the end using interface names instead of tags do work, and I’m totally fine using that way, so thank you!

Still, for my knowledge, could someone give me an explanation on why tags worked in the case of the above referenced threads ?

7

The follow up on your third link sums it up nicely:

  • The tags has nothing to do with VLAN tagging, they are internal to
    Dnsmasq.

To answer your questions:

  • Yes you are correct
  • Given the sample above I would say no.

As said before:

The other links I'm not so sure if it works as intended.

8

I understand all that. So let’s forget VLAN tags for a moment and keep the focus on dnsmasq tags.

Why do the people in the linked threads (maybe just the first two if the third is not a good example) seemed to have been able to manage multiple subnet ip ranges and options (associated to vlans) with the help of dnsmasq tags?

9

Ahum:

EDIT: Besides interface tagging with dnsmasq, tagging is also often used to supply a particular HW vendor/device, based on MAC, with tailored DHCP options like for example for IGMP snooping for streaming services etc.

10

From what I read in the above pihole forum threads, it really seems like it was working, as their issues were not at all because of the tagging errors but rather file naming/loading related.

11

So you tried using vlan tags for dnsmasq and failed.
While the one using the interface name as a tag was successful.
How much prove do you want?

Ask the others to run below to prove it works as intended:

12

No, as long as the router is configured correctly.
VLANs are managed (and terminated) by a router, i.e. it is the router that would decide which target NICs it would send a broadcast to (and it would commonly strip the VLAN tag from packets before doing so).

pihole-FTL/dnsmasq will then automatically tag a DHCP packet with the name of the NIC that it arrived on, and only one of the interface names will match the range.
(And deHakkelaar is correct to point out that dnsmasq's DHCP option tags are not the same as VLAN tags.)

Adding explicit OS level VLAN support on the host that runs pihole-FTL/dnsmasq may also be a choice, but not a likely one, as that would only be required if the router would treat the port Pi-hole is connected to as a trunk (i.e. a connection to another router), so it would not strip VLAN tags from packets before forwarding them, leaving it to the next router to manage (in that case, the machine hosting Pi-hole).

I haven't read them, but I'd guess that either the host's interfaces would be configured accordingly (i.e. the host has one interface in each VLAN subnet) or a DHCP relay would convey subnet information for relayed broadcasts.

13

As mentioned earlier, that’s indeed the setup I have. So why was it not working?

14

I don't see any interface configuration details in your initial post, but assuming those would be configured appropriately, it would depend on how your router's VLANs are configured.
How does your router forward traffic to your Pi-hole VM?
Is your router aware of both VM interfaces, targeting VLAN traffic to the correct interface, or does it only know about the interface of the machine hosting your VM?
If the latter, you may have to add your VLAN interfaces to your host OS and attach both of them to your Pi-hole VM.

15

I think we might have a misunderstanding about how those two virtual interfaces from your example below are created/setup:

If I create two virtual ones:

$ sudo ip link add link eth0 name eth0.10 type macvlan
$

$ sudo ip link add link eth0 name eth0.20 type macvlan
$

$ sudo ip address add 192.168.10.2/24 dev eth0.10
$

$ sudo ip address add 192.168.20.4/24 dev eth0.20
$

$ sudo ip link set eth0.10 up
$

$ sudo ip link set eth0.20 up
$

$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eth0             UP             b8:27:eb:XX:XX:XX <BROADCAST,MULTICAST,UP,LOWER_UP>
eth0.10@eth0     UP             2a:7b:a8:ce:06:85 <BROADCAST,MULTICAST,UP,LOWER_UP>
eth0.20@eth0     UP             36:e1:f1:ba:36:6a <BROADCAST,MULTICAST,UP,LOWER_UP>

$ ip -br -4 address show scope global
eth0             UP             10.0.0.2/24
eth0.10@eth0     UP             192.168.10.2/24
eth0.20@eth0     UP             192.168.20.4/24

And run a dhcp-discover from another host:

$ sudo tcpdump -ti any udp port 67
[..]
eth0  B   IP 10.0.0.145.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:16:3e:XX:XX:XX (oui Unknown), length 548
eth0.10 B   IP 10.0.0.145.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:16:3e:XX:XX:XX (oui Unknown), length 548
eth0.20 B   IP 10.0.0.145.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:16:3e:XX:XX:XX (oui Unknown), length 548
eth0  Out IP 10.0.0.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 318

How is dnsmasq able to distinct if the DHCPDISCOVER is received on all interfaces (physical and virtual)?
EDIT: Without applying VLAN tagging and trunks on the host.

16

It doesn't matter how interfaces are created.
It's about the router supporting VLANs being able to identify those interfaces (regardless whether they are virtual or physical) and assign them to a specific VLAN - as long as the router is configured correctly, broadcasts emitting from one VLAN will only be received within that same VLAN.

If your router doesn't support VLANs, neither interface creation nor dnsmasq configuration will allow you to create them.

Well, if you don't have VLANs, clients would receive DHCPOFFERs from all configured dhcp-ranges, and it would then depend on the client's OS preferences which DHCPOFFER it would accept.

17

I've never heard of a switch engine that can "identify interfaces" on a receiving host.

I think you're missing the point which has nothing to do with VLAN tagging.
The switch would aggregate all DHCPDISCOVER packets received from the different VLAN's and dump them all on the single switch port that the Pi-hole host is connected to/tagged for.
Thats via a single receiving physical interface on the Pi-hole host and after the switch removed the VLAN tag(s).
So if the exactly same packet with source IP 0.0.0.0 is received on all three interfaces from above example, how would dnsmasq know what scope to apply?

Do you have it setup like your example or can you point me to a link where this works?
I dont want to mess too much with my DHCP server setup to try things out :wink:

EDIT: Ps, did you notice the DHCPOFFER is a broadcast and not unicast with my above tcpdump.
Not sure how you would translate that back to the VLAN's :wink:

18

Simpler switches may well only support static port based VLANs, where the switch's physical NIC (aka port) would determine which VLAN a device that connects through that port would belong to.

It's quite possible to dynamically assign traffic to VLANS based on different criteria (e.g. authenticated or MAC-based RADIUS profiles), and that would require some sort of VMPS running on your routing equipment, which may allow several ways of dynamically separating traffic into VLANs, including MAC-based assignments to VLANs.

19

Sounds complicated and maybe something not found on consumer switches/routers or not?

Maybe a DHCP relay can solve above not spilling to all VLAN's???
You dont want a malicious host in an untrusted VLAN to sniff all those broadcast packets that contain details like hostnames etc.

20

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