You need to read my comment again. The clients are behind either a bridged AP or a switch, i.e. all on the same subnet, all getting their DHCP addresses from the UDM-Pro, all in the UDM-Pro's ARP table. There is NO double NAT happening here.

Furthermore I didn't say they were invincible. I just said they were invisible to the UDM-Pro's UI. Unless you have a blanket ban on outgoing LAN traffic, which would be absurd, there's no way to block access for a particular client or a particular destination address for that client.

In the case I gave, a Chinese robot vacuum with no on-device interface, please tell me how to find the IP of this robot, then block outgoing traffic from it, without SSH'ing into the UDM and running scripts. That's right, you can't, because the UDM-Pro doesn't support it.

I never said you were using double nat, but noted it as an example in which you may have these issues.

> Unless you have a blanket ban on outgoing LAN traffic, which would be absurd, there's no way to block access for a particular client or a particular destination address for that client.

To the contrary; this is exactly what you should be doing. Isolated subnet for these untrusted devices. Block by default. (Whitelist only)

I used the word invisible to describe it missing in the ui. I used the word invincible to describe your lack of “management” (ie; blocking) of the device.

What I am trying to suggest, however, is that the UDM is likely not the root cause of these issues. I certainly don’t mean to suggest they are the best. The lack of compatibility of features between their product lines is a nightmare.

It's not just compatibility features. They are missing features that low end consumer grade hardware have, and I'll say what I was implying: It's because it's a vendor lock-in strategy, and they want you to replace ALL your equipment with theirs. Explain to me why I shouldn't be able to manage a list of DHCP clients in a piece of "enterprise grade" hardware.