EDIT

  @btx What kind of additional hardware would be needed?  I have everything set up so it would work if I could get the devices to use a hostname instead of the IP of the controller.  I wonder if we're talking about the same thing, because for what I want it doesn't matter if Omada has a DNS server.

EDIT

ryan5678 wrote

How do I override the hostname that devices use to connect to the Omada controller?  No matter what I do they're trying to connect to the IP address of the controller, so there's no way to manage devices that leave the LAN.

 

There's "Settings - Controller - Access Config - Controller Hostname/IP", but the info says "Enter the hostname or IP address of the controller that will be used for the reset password emails and the RADIUS portal" which makes me think it's not functioning like Unifi's "Controller Hostname/IP" with the option to "Override inform host with controller hostname/IP."

 

If I have a self hosted controller at "omada.example.com", how do I tell APs and switches to use "omada.example.com" to communicate with the controller?

  @ryan5678 

this does not work in the same way as unifi, to tell omda device where controller is you have to use dhcp opion 138 or you have to use omada discovery utility tools.

with discovery utility you can use dns name or ip to adopt devices to controller.(work pretty musch same way as unifi but you have to do it manualey with this tools)

a bit more work but you can also log on each device and tell the device where the controller is with ip or dns name

I hope Omada comes up with a similar solution as unifi for this eventually, it's a useful function that I use a lot.

on Omada is this only for password reset, I dont know how it works

EDIT

  @btx 

this has nothing to do with Omada's DNS server, you can use any DNS server to do this (no-ip for example). the point is that Omada devices should find the controller even if the controller is not on the same network, then you can use an ip or a dns name. I use this myself with the dns name so I don't quite understand the problem.
it is the only way if you have a remote site that will connect to a central controller. if it is dynamic wan ip you have to use dns to find the controller

EDIT

  @btx 

it has nothing to do with local domain, this is an internet domain, in this case to find the controller with the name where it is remote site is somewhere on the internet.

I not use tp-link for customer yet but it is the same on unifi, we hosting a unifi controller for multiple cusomer and use unifi,mycompany,com as inform overwride on controller,

if we ned to move controller to antoher ip we just change host name ip and all the 100 site is moved to new ip, its pretty simple and not very complicated :-)

EDIT

@shberge Thanks.  That got me on the right track and I was able to get it working and tested enough that it's usable.

@btx What I wanted to do doesn't need Omada to deal with any DNS.  Our authoritative DNS is at Cloudflare.  Our controller is behind a firewall that does failover.  If our main ISP fails it automatically switches to our secondary ISP and updates our DNS at Cloudflare, so the public IP of our controller changes if our main ISP fails.

Based on the hint from @shberge I was able to learn / test the following:

• When devices are on the same LAN / subnet as the controller they can be adopted directly, but they seem to end up configured with the private LAN IP of the controller which is not very useful if you're trying to manage anything more than a single site.
• Using the discovery tool to pre-configure devices prior to adoption works.  They seem to end up configured with the desired hostname rather than an IP address.
  • I think putting the controller and the devices getting adopted on the same LAN / (broadcast) subnet is problematic.  The biggest issue I had when doing this is that I couldn't tell if a device had been pre-configured with the discovery tool or if it has simply been discovered via broadcast.  To avoid accidentally letting the controller adopt un-configured devices I've chosen to use the discovery tool on a separate VLAN / subnet to ensure the controller can't discover them before they're configured with the correct hostname.
  • I simulated failover / moving to another site by changing the public IP of my controller.  The devices seem to do a decent job of re-querying DNS and reconnecting when they get disconnected.  At a minimum, I'm certain a reboot is sufficient to get them to reconnect when the controller moves to a new IP and that's as good as UniFi (the last time I tested UniFi it cached the controller IP indefinitely, ignoring TTLs).

I would say the way the controller works right now (v5.4.6) is quite bad in terms of adopting devices.  It's inconsistent and taking the easiest path by using the controller's discovery / adoption does the wrong thing in my opinion.  The whole point of the controller is to have a single pane of glass to manage multiple sites.  Configuring devices with a private IP just doesn't make sense.  At the very least it should have an override for the contoller hostname similar to what UniFi does.

Thanks for the help.