Feature Request : White-list only internet access for new DHCP clients


If you're like me, you have several hostiles devices that will automaticall self-destruct if ever allowed to use their call-home backdoor on the unfiltered internet.

What we need to not accidentally destroy these devices is White List Only internet access for unknown device.

Or "DHCP client whitelist", not sure exactly what to call this, it has other uses.

So first how to do this.

Easy mode is, somehow set default Gateway for dnsmasq either to a unused address on your network, or maybe if that's possible, give no gateway address ?

First warning here, Android devices will bounce off a wifi that doesn't give them a valid gateway address and we might also need "fakeinternet" as part of this package.

Ok, now, a new unknown device connects to the network, it gets a dynamic address and a wrong or blank gateway. We're half-way there already !

Next, each new dhcp client needs to be added to the whitelist file /etc/config/dhcp

First thing, we need a tag that contains the good gateway address

config tag 'good_gateway'
        list dhcp_option '3,'
        list dhcp_option '6,'

This will set both the gateway, helpfully named dhcp_option '3 and the DNS named dhcp_option '6

Last step, adding dhcp clients to the whitelist

config host
        option name 'mycomputersname'
        option dns '1'
        option mac 'AB:CD:00:12:34:5F'
        option ip ''
        option tag 'good_gateway'

I'm not sure if option dns '1' needs to be defined

I don't know if you have to decide on an ip address for every single device with option ip '' preferably this line can be left off and every client just gets an address from the pool

I don't know if you can specify more than one tag per client, that would be great

And now, the Feature Request part of this message

It should be possible in LuCI to do this without modifying config files

So here is what needs to change to perform the minimum requirements

First, there needs to be a way to set the DHCP server's default gateway IP

I had a look in the current interface and I cannot see how to specify a blank or invalid or unused IP address as the gateway address

I had a look at the config files, but still can't tell where the dhcp server is being told what gateway to use

It is probably using the br-lan interface called WAN's IP address
But I don't want to set that address to a blank, invalid or unused address !

So I have to find how to set the dhcp server's default gateway address to an arbitrary value

Ah, it might be addign
option '3,'

to the config dnsmasq section of /etc/config/dhcp

--------FEATURE REQUEST HERE !--------
So, ok ! Please add the ability to specify Option 3
To https://router.lan/cgi-bin/luci/admin/network/dhcp the "General Settings" page
(also option 6 DNS please)
(Also, if if you're feeling fancy, check if the option is hardcoded in the config file, if it isn't then write "automatic" in the text box, maybe with the current value "automatic("
--------FEATURE REQUEST HERE !--------

Next, we need to define tags and assign them to static leases

First we need a way to list and assign, at least one, tag to a static lease

This is on the Static Lease page

(how do I make a link to the static lease page ?! It always links to https://router.lan/cgi-bin/luci/admin/network/dhcp#)

This is on the Static Lease page

As you can see, no way to set a tag

So, what we need here is

A combobox where you can see all the defined tags, and choose, at least, one

Then add, at least one, tag name to the "config host" section of the config file for that host
The text is literally
option tag 'good_gateway'

--------FEATURE REQUEST HERE !--------
Add ability to select one (or more) tag on the "DHCP and DNS/Static leases/my host/Edit" page
--------FEATURE REQUEST HERE !--------

Also, how do I NOT set an hardcoded IP address here ?
Can I just leave IPv4 address blank here ?
I'm going to need to make so many host definition, I don't want to give them all an hand picked fixed address ! It should be obvious how to create a "dynamic static lease", yes, you read that right.

Ok next we need to create Tags with our settings

Tags are really simple it's just this text

config tag 'deadend_gateway'
        list dhcp_option '3,'
        list dhcp_option '6,'
config tag 'good_gateway'
        list dhcp_option '3,'
        list dhcp_option '4,'
        list dhcp_option '6,'

Oh BTW, option 4 is the NTP server

config tag 'Android_fakeinternet_gateway'
        list dhcp_option '3,'
        list dhcp_option '6,'

In this case is a DNS server which runs anti-google DNS filtering
and is a gateway with google/android style fakeinternet

config tag 'Android_filtered_gateway'
        list dhcp_option '3,'
        list dhcp_option '6,'

And this is good internet, but all the google websites are DNS filtered AND IP Banned from that gateway

--------FEATURE REQUEST HERE !--------
Ability to see, list, create and modify DHCP option tags
In https://router.lan/cgi-bin/luci/admin/network/dhcp# probably a newtab, similar to "IP Sets" but call it "DHCP Tags", create custom tags and add them to the file /etc/config/dhcp
--------FEATURE REQUEST HERE !--------

While this is not exactly the answer you are looking for: Why don't you just create Firewall rules instead?

You could block all traffic by default and only allow Internet access based on the MAC address.
And/or separate your network into VLANs, where the "trusted" VLAN has Internet access enabled by default and the "untrusted" network requires explicit access permissions.

1 Like


That seems more difficult

Now all the packets would need to be inspected by a firewall, adding a per packet amount of cputime spent on firewalling. I don't think my archer c7 will still work at 300mbps if I enable the firewall.

Also I haven't figured out how to make firewall rules that follow dynamic IP around. I don't wish to spend time assigning and maintaining lists of static IP addresses.

Doing it in the dhcp server seems like the clean way.
I don't expect hostile devices to find their own way to the gateway and disregard dhcp settings, yet.

Even if a firewall was involved, then I would still want the "dynamic static leases" in the dhcp server and they would have to drive the firewall addresses.

So, dhcp internet whitelisting has to work first.

Yes. I assumed that you were talking about your main router that already has a firewall enabled. Your C7 needs to process every single packet anyway for NAT to work properly, the additional overhead consist of a simple address check.

You don't need to. Use the MAC address instead, the DHCP server manages its clients also based on the MAC address.

You can still use static DHCP leases, no problem here.


Firewall would work, I didn't know the firewall could even track by mac address, I imagine that's one thing that came after iptables

From what I understand, it looks something like this

uci add firewall rule # =cfg1c92bd
uci set firewall.@rule[-1].name='block specific host'
uci set firewall.@rule[-1].src='wan'uci add_list firewall.@rule[-1].src_mac='3C:A8:2A:B0:16:25'
uci set firewall.@rule[-1].target='REJECT'

But also, that is a lot more complicated compared with just adding a tag to a dhcp lease.

I would much rather apply firewall rules to all hosts with a tag.

I also do not want to manage parrallel lists of hosts in dhcp leases and then also in firewall.

That really should be just one list for anything but the most exotic setups, and dhcp config is the best place for that list in the absence of a kind of "host list manager page"

To further illustrate the difficulty in using the firewall.
I've been messing around trying to block that host from accessing the internet.
There's several ways to configure the firewall, but there's just so many parameters, it's really hard to get it to do what you want it to do without extensive test hardware and environment

Just trying the couple few permutations I've got all these

uci add firewall rule # =cfg1c92bd
uci set firewall.@rule[-1].name='block specific host'
uci set firewall.@rule[-1].src='wan'
uci add_list firewall.@rule[-1].src_mac='3C:A8:2A:B0:16:25'
uci set firewall.@rule[-1].target='REJECT'
uci add firewall rule # =cfg1d92bd
uci set firewall.@rule[-1].name='block specific host'
uci set firewall.@rule[-1].src='lan'
uci add_list firewall.@rule[-1].src_mac='3C:A8:2A:B0:16:25'
uci set firewall.@rule[-1].target='REJECT'
uci add firewall rule # =cfg1e92bd
uci set firewall.@rule[-1].name='block a specific host'
uci set firewall.@rule[-1].src='*'uci add_list firewall.@rule[-1].src_mac='3C:A8:2A:B0:16:25'
uci set firewall.@rule[-1].target='REJECT'
uci add firewall rule # =cfg1f92bd
uci add firewall rule # =cfg2092bd
uci add_list firewall.@rule[-1].src_mac='3C:A8:2A:B0:16:25'
uci set firewall.@rule[-1].dest='*'
uci set firewall.@rule[-1].target='REJECT'
uci add firewall rule # =cfg2192bd
uci set firewall.@rule[-1].src='*'
uci add_list firewall.@rule[-1].src_mac='3C:A8:2A:B0:16:25'
uci set firewall.@rule[-1].dest='lan'
uci set firewall.@rule[-1].target='REJECT'
uci add firewall rule # =cfg2292bd
uci add_list firewall.@rule[-1].src_mac='3C:A8:2A:B0:16:25'
uci set firewall.@rule[-1].dest='wan'
uci set firewall.@rule[-1].target='REJECT'

Yes I could spend a few weekends mastering this section of openwrt

But setting a tag in the dhcp config, that's hands down the easier way to go and I really think it would make openwrt easier to use the advanced features by common users if it had that feature.

No, the source zone needs to be LAN - check this wiki article (omit the instructions on the time).

You are welcome to contribute this feature. I was just pointing out one way of achieving this without any further development.


I'm really not seeing how your proposed process is an easier way to go then either creating a specific VLAN to connect these 'hostile' devices to and then block internet access by default to that VLAN.

Or creating appropriate firewall rules which are pretty simple:

config rule
        option dest 'wan'
        option src '*'
        option proto 'all'
        option target 'DROP'
        option name 'Device_WAN_Block'
        option src_mac 'aa:bb:cc:dd:ee:ff'

They can also easily be set up in Luci with the current options.


I understand the infrastructure way of doing this might be firewalls and VLANs.

But I find it has been too cumbersome to use at all.

This feature request is a note to myself and fix it my way when I have accumulated enough of these to make it worth my time to learn Lua and fix all the other improvements I wish LuCI had.

I admit I chose maybe a too exotic scenario with my hostile devices (even though all homes nowadays are filled with these self-destructing devices, your TV for instance, autodownloads irreversible firmwares changes without permission)

Another use for this which is more mainstream is to assign VPN and TOR exit nodes by specifying gateways per host / per tag.

Also, access to tags would allow specifying per host/per tag DNS servers, so you can switch between varied levels of DNS filtering in a fine grained manner.


thanks for clearing up that firewall syntax

as for using VLANs, I have multiple dumb switches in my network so I don't think VLANs would work and I also don't have the infrastructure to test if it would work or not.

There's 7 switches and 3 AP in my network and I don't want to have to keep track of where each device is or where it is connected.

Also I'm not sure it's even possible to set a VLAN ID to an android phone plugged in via wifi but also sometimes over wired ethernet with a usb to ethernet adapter ? It would probably end up connected to the wrong VLAN at some point, get unbridled internet access and then promptly brick itself.

If your plan is, at some point, to take the time to sufficiently learn lua so you can make changes to LuCI would it not also be beneficial to also take the time to learn other, arguably more 'proper', methods to do the things you want to do?

Using DHCP to assign different gateways is all well and good when you do have genuinely different default gateways to send traffic to, but creating methods to use DHCP to send traffic to 'fake' default gateways seems less useful. Especially when what you are essentially wanting to do is really a firewall/routing issue. Same thing with VPN/TOR, the default gateway for local hosts is the router. It's then for the router to decide how to route that traffic correctly.

No, dumb switches and VLANs can have wildly inconsistent results.

You wouldn't set the VLAN ID on the device itself. Many end devices don't have that functionality, or don't make it easily accessible. You would tag the wifi or the ethernet port being used.

1 Like


I'm trying to reduce friction necessary to use the advanced features of the underlying software.

Using the firewall to do anything is high friction.
I highly suspect if I start going that route, it's going to kill the performance and become a unmanageable spaghetti of endless rule exception.

What I want is to specify a gateway to a device or group of devices.

I can already do that by editing /etc/dhcp/config in a shell using nano

This feature request is about that, is also still too high friction for most users.

It shouldn't involve the terminal, installing extra applications, learning commands and text editors.

It should be a little dropdown in the dhcp leases tab, and you tell this or that device that it's getting "full internet""no internet""android fakeinternet""whitelist internet""VPN in UK internet""TOR" and so on.

There should only be one place where the user needs to maintain a list of know and unknown devices and for now it should be this page. If there's firewall rules involved, they should refer to this list, the dhcp leases to know what rules should apply. And groups of firewall rules should be applied to hosts and groups of hosts on this page

I'd have to disagree that creating and using a kludge is an approach that reduces 'friction'. The default gateway is (or should be) the destination that connected devices send any packets they don't know how to directly deliver. That is generally the next upstream router. It's for the router to then determine where those packets get sent based on it's routing table and/or firewall rules.

Sending fake gateways to devices to block internet is not a better solution. Trying to use DHCP to direct traffic to VPN/TOR (or anywhere else) will only work if those devices can directly send traffic to that address already, so unless it's a device on the same subnet it's not going to work. You'd need the router as the default gateway and you're back to routing rules.

I also don't think your workaround is any less complicated than using the firewall/routing. It may seem like that to you currently if you have more experience/knowledge around using DHCP, but to someone coming in with no knowledge it's going to be equally as baffling.

Maybe there's an argument that there needs to be improvements to LuCI for using firewall/routing rules, but that's where it should be focused. Not on creating a workaround using DHCP tags.

1 Like

If I had even one hostile device knowingly on my network I would be stupid.

Let them self destruct then chuck them in the bin....

A DHCP based solution should be possible using wildcard MAC, but it goes against best practice and leads to other issues as noted by @krazeh, so you better forget about it.
You don't need multiple firewall rules since multiple MACs can be listed in a single rule.
Depending on what you want to achieve by default, create a prohibitive rule for MACs to block, or remove the LAN to WAN forwarding and create a permissive rule for MACs to allow.


You've made 2-3 other threads regarding this in the Feature Request section.

How does this differ from the other threads, except the slightly different wording?

They really seem like duplicates. From all of them, I've interpreted you want some web GUI view of editing DHCP Options and such "tagging" attached to certain devices.