Different DHCP option 3 for android clients

OpenWRT version: OpenWrt 23.05.3 r23809-234f1a2efa (Redmi AX6S)

Network config:

LAN network: 192.168.0.0/24
192.168.0.1 - Virgin Media Hub 5 no public IP DHCP and wifi disabled
192.168.0.2 - OpenWRT running as DHCP, DNS and wifi access point

IOT network: 192.168.2.0/24
192.168.2.1 - OpenWRT

I am trying to configure devices on the LAN network to have a static route to the IOT network, so I set option:
121,192.168.2.0/24,192.168.0.2,0.0.0.0/0,192.168.0.1
and disabled Option 3
This in theory should work fine, but in it turns out Android ignores option 121, so I re-enabled Option 3 and set it to 192.168.0.2 - it's not the end of the world to route via .2 for Android, but then I ran into a further problem. Clients that support option 121 are supposed to ignore option 3, but of course Microsoft can't be bothered, so now I have two default routes on Windows clients and 192.168.0.2 has higher priority, not ideal.

So now I'm in the murky world of setting vendor-specific options in DHCP and could use a little help. What I'd like to do is disable option 3 if the vendor is MSFT, or alternatively override option 3 if the vendor is Android, so based on the docs at https://openwrt.org/docs/guide-user/base-system/dhcp_configuration I added this to /etc/config/dhcp

config vendorclass 'msft'
        option networkid 'msft'
        option vendorclass 'MSFT'
        list dhcp_option 'vendor:MSFT,3'

(I also tried 3,192.168.0.1, and doing thing with vendorclass 'Android')

Unfortunately this doesn't appear to work. It is a 2017 doc, so it's possible the config has changed (or more likely, I did something wrong) but I have not been able to find anything more recent.

Any ideas?

You can set a different option 3 by MAC or IP address but that only works for clients you know, maybe you can work with that?

Does this need anything more complicated than adding the IOT firewall zone to the “Allow forward to destination zones” in the lan firewall zone?

Did you intend to set 0.0.0.0/0 ? As written you are only adding a route for 0.0.0.0/24 which is a CIDR point that won't get hit in practice. It only matches host "0" on any 24-bit lan (ie ..*.0).

I actually set /0 in the config, and mistyped here sorry. I've edited the OP to avoid confusion

1 Like

Unfortunately yes. To allow for things like the Philips Hue app on Android to actually talk to the Hue hub I need to route to the IOT network as well as from

Not easily unfortunately, Android phones default to doing MAC randomisation, and I generally want my guests to have access to Chromecast, Hue etc. I just don't want those devices to have access to my main network (with the exception of Chromecast having access to Plex)

Clients can easily alter their own routing so this is not secure solution.

For a secure solution you need to separate traffic on the firewall e.g. with a guest wifi,
You can make traffic rules to allow only certain traffic to go through by port and IP address e.g. to get to your plex

I'm fine with clients on the main LAN being able to route to the IOT network, since I trust those clients (e.g. my phone, partners' phones, laptop etc.) I don't trust IOT devices and the aim with this config is to block them from accessing the LAN unless I specifically allow it in the firewall, thus limiting the damage they can do if they do get compromised.

I've been considering a guest WLAN for wifi guests I don't trust, but that's a separate issue to worry about at another time. I don't want a general guest wifi because it will end up with double NAT

Does the hue app allow input of an IP for the hub or is it auto detect only? If it accepts an IP, as long as the connection is instigated by the lan device, allowing connection via the firewall will work. I have IOT side mqtt servers working with lan side clients no problem as the connection is initiated by the lan side. No special rules required, and IOT can’t get to lan uninitiated, exactly the same as wan.

Hue app might, but Harmony and Chromecast do not.

However I'm not sure how that would help as I'd still need the LAN client to actively choose to use a different gateway than the default, even if I manually set the IP

Aha, your router is not the gateway, I see. Is there a reason you have left the sh5 as the gateway, rather than put it in bridge mode and use the router as the gateway?

Just an idea to use tags.
https://openwrt.org/docs/guide-user/base-system/dhcp_configuration#client_classifying_and_individual_options
You still need to do the classification though, it's not automatic.

Not necessarily, I think if you can set a static route on the main router you do not have to NAT the traffic of the guest wifi

Two reasons

  1. My internet conection is about 1.1gig, and my OpenWRT'd AX6S maxes out at about 945
  2. Virgin Media support will always blame "Modem Mode" if you use it and will refuse to troubleshoot problems that are obviously at their end until you turn it off. Sometimes they turn it off without telling you, leaving you stuck with double NAT until you realise!

Unfortunately the VM hub doesn't even let you change its IP from 192.168.0.1/24 let alone allow static routes or anything actually useful!.

Tags would be worth doing, but I'd still need to get it to do the detection based on the vendor sent by the DHCP client, so that I can then send the correct options

Im reading about this.

from what i think is that you need to use dhcp option 43 and 60.

43 is i think the vendor class option inside the interface settings i think you can see that as the whitelist, while dhcp option 60 checks for the client, and you should push this to your clients, if 43 is not used it will not work.

^ i realize i made a mistake, this option 43 shows in the advanced tab when the interface has protocol dhcp client, i remember this because for my iptv box i needed a string for it in order to work, so maybe it has to be exposed differently.

Here is where i get this from though it is not OpenWrt but i think this is how it works.

https://www.sonicwall.com/support/knowledge-base/how-to-configure-dhcp-option-43-and-option-60/220617123907357/#:~:text=DHCP%20Option%2060%20is%20used,itself%20to%20the%20DHCP%20server.

So i guess it is, 60,Android 8 as example ?, it could be the " quotes are needed.

So I haven't had much luck with 43, but I have managed to set extra options for MSFT, unfortunately not quite the way I'd like.

If I do vendor:MSFT,3,192.168.0.1 attempting to override the default 192.168.0.2 I think it's sending that in addition to the original Option 3, which causes DHCP to fail

If I do vendor:MSFT,3 it makes no difference, so it's not disabling, just not sending the extra

I can't figure out what I need for vendor:Android to send custom things for that.

Is there any way I can do vendor!=MSFT:3,192.168.0.2 because the most correct way would be to send option 121 with the correct routes and option 3 for the fallback config, and then just remove option 3 specifically to deal with Microsoft's incorrect implementation

Unfortunately im not aware of a ! approach with dhcp options, maybe someone else knows this better.

Though ive found a usefull command with tcpdump to see communication and vendor information if this was not posted yet.

tcpdump -i interface port 67 or 68 -e -p -vv

If you replug a cable or restart the routers wifi to one of these devices i was able to see clients sent dhcp option 60, androids have kinda a random string with its version going on, some other devices only show udhcp-(version), so 60 is not used on the server afaik.

To me i came to the conclusion it makes it difficult to make this manageable aswell if you need to handle different vendors, it can maybe work for some time until their version is upgraded because they put their version in the string, you have no control over these random vendor names.

My best guess is using the mac address OUI fields and do a wildcard, even though mac addresses can be spoofed, + some devices have randomization, some randomizations still respect OUI its worth to check if thats holding true for android. :+1: