Is it possible to offer DHCP only to WiFi clients?


Would it be possible to offer DHCP only to Wifi clients, but not on the wired LAN ports? That is, if someone plugs a cable into the router's LAN port, which is configured with a static address, must also configure a static IP on the device to access the internet through the router.

If they connect via WiFi instead, they receive their IP via DHCP on that same subnet of the LAN interface. What would be the overall steps for that?


You should not need to do anything to make this work. If you set your ethernet interfaces on your LAN connected devices to a static IP address then this will solve the problem. They won't send out DHCP solicit requests and won't get allocated an IP by DHCP.

1 Like

Thanks for your answer!
Yes, that part is as you say, on the wired LAN all devices including the OpenWRT router would have their own static IP. The point is that I need the router to be the DHCP server for those connecting to its WiFi, offering a range of IP addresses that are on the same IP network as the wired LAN. What I don't know how to do is prevent DHCP from advertising on the wired LAN as well.

I don't understand the problem. When any DHCP client device comes up, it explicitly asks for an IP address using a broadcast request. If the wired client devices are set to static IP addresses, it won't solicit for DHCP and there won't be DHCP traffic.

While you can disable DHCP for a given interface, your wired lan and your wifi are bridged, so disabling it on the lan interface will also disable it on the wifi radio interface. You appear to be creating a problem where there is none?

EDIT: only in ipv6 do we get the notion of router advertisements. An ipv4 DHCP server does not advertise. In ipv4, the client will broadcast a DHCPDISCOVER message to find the DHCP server, which will reply with a DHCPOFFER offering up an IP address. The client then replies with a DHCPREQUEST message to accept the offer. The server then sends a DHCPACK to complete the negotiation. So if your client is not sending a DHCPDISCOVER, which it won't in the case of a static ip configuration, you won't get any DHCP traffic between the wired client and the DHCP server

1 Like

separate LAN & WiFi interface (i.e. don't bridge them)?

And then firewall ruls and routing rules to handle the traffic between.

He wants their IPs on the same subnet, so that won't work

That may lead to a solution, I'll make some tests.

The ultimate goal is that if, for instance, someone plugs a device into a UTP network socket on the wall, they don't automatically get an IP address given by the router. If instead, it connects to WiFi, for which a strong password is needed, the router's DHCP service gives the device an address that allows IP connectivity to other devices, wired or wireless on the LAN.

1 Like

So if I understand it correctly, your problem isn't actually "advertisement" per se. It's that you're setting up your clients for DHCP and thus if they're connected to both wifi and LAN, they request and get two IP addresses.

I don't know what version of OpenWRT you're using, so not sure if your firewall is nftables or iptables, but assuming it's iptables, you could try to drop DHCP traffic over your wired interface. So assuming your wired LAN port is eth1, you'd use something like this, which will silently drop all traffic from the DHCP server to the client udp port 68 used by DHCP clients.

iptables -A output_rule -o eth1 -p udp --dport 68 --sport 67 -j DROP

The wired interface is a member of a bridge, so this can only be done using ebtables or an nftables table of bridge family.

The point is to prevent a random someone from plugging a device into a wall socket and automatically get an IP address from the router that allows LAN connectivity. It's more of a "security requirement". We want them to only get an IP address if they connect to WiFi, which is something we can control with a password.

Yeah, correct - the rule has no effect when the interface is a member of a bridge

I'll take a look at that, thanks!

Another potential option would be if you put a managed switch on the LAN side of your OpenWRT. You can then add an ACL to each port on the switch to block inbound traffic destined for UDP port 67.

The OpenWrt version I'm using is 22.03.3. The router is a TP-Link Archer C6U.

Yes, I thought of something like that, but I was hoping I could solve it just by configuring OpenWRT ...

What is the output of brctl show ?

For most managed switch you just need to turn on DHCP snooping.

I know there was a etables-dhcpsnooping in OpenWrt but not in 22.03, so I don't know if we can still do it on new OpenWrt....

This is the output:

bridge name     bridge id               STP enabled     interfaces
br-lan          7fff.ac15a2b96901       no              lan4

Run the following commands (copy/paste the entire block and press Enter).

opkg update; opkg install kmod-nft-bridge; \
nft add table bridge filter; \
nft add chain bridge filter input '{type filter hook input priority -200; }'; \
nft add chain bridge filter output '{type filter hook output priority 100; }'; \
nft add rule bridge filter input iifname { lan1, lan2, lan3, lan4 } udp dport 67 counter drop; \
nft add rule bridge filter output oifname { lan1, lan2, lan3, lan4 } udp sport 67 counter drop

This is for testing purposes only. If you restart the router, the settings will be lost.


Thank you!
After your commands, the router's DHCP no longer responds to requests from clients connected to the wired LAN, which looks great! I'm not physically at the router site right now, so I can't test if DHCP works on WiFi. If I could connect to WiFi with an address given by the router's DHCP, your proposal WOULD BE the solution I'm looking for. I'll confirm it tomorrow ...

This is seen on the wired LAN before your filter commands:

[casanovg@hta-spirit ~]$ sudo nmap --script broadcast-dhcp-discover -e eno5

Starting Nmap 7.93 ( ) at 2023-03-10 00:38 -03
Pre-scan script results:
| broadcast-dhcp-discover:
|   Response 1 of 1:
|     Interface: eno5
|     IP Offered:
|     DHCP Message Type: DHCPOFFER
|     Server Identifier:
|     IP Address Lease Time: 12h00m00s
|     Renewal Time Value: 6h00m00s
|     Rebinding Time Value: 10h30m00s
|     Subnet Mask:
|     Broadcast Address:
|     Router:
|     Domain Name: lan
|_    Domain Name Server:,,
Nmap done: 0 IP addresses (0 hosts up) scanned in 10.24 seconds

After applying the filters...

[casanovg@hta-spirit ~]$ sudo nmap --script broadcast-dhcp-discover -e eno5

Starting Nmap 7.93 ( ) at 2023-03-10 00:41 -03
Nmap done: 0 IP addresses (0 hosts up) scanned in 10.23 seconds
1 Like