You may want to set the inform URL also via the controller correctly (controller Hostname / override inform host).
Check that a) the Hostname is correct as you described and b) the override is turned on.
In this case the controller does the 2nd set-inform for you.
But all devices must be able to use that name - should be true when controller is in cloud.
I'm not sure what's the problem here. I'm an absolute newbie on unifi and by far not a networking expert. When I got my 2nd wan, I enabled it and used failover immediately, cool. Then switched to load balance, had some issues, found it perfectly resolved in 5.6.3 controller (that's the beta piece) and am a very happy camper.
With really good and easy to handle instructions from this forum I added some extras like access to the WAN networks, disabled some NAT to get away from dual nat, added additional load balance features and routes.
In this forum there's so many helpful resources and people - customers as well as staff - and responsive. But just complaining does not help - it brings down the priority for everyone - not sure why I am responding at all.
I think the easiest is to plug it into a POE Switch :)
I believe that all should be possible via CLI, but you need to get into the Edgerouter Forums / Knowledgebase to figure it out. As said, here in this forum there are things like multiple IP's on WAN side, as well as routing (not bridging) to internal networks.
I do not see the value of a bridging configuration - if you want a separate IP on WAN - get that done, and route it to the cloud key and you are done.
For theroretical things, sure there should be some way to set up a bridge config. No idea how to…
At first, if you have a single controller "at home" it can manage the remote components.
There's only a "light" connection where the remote components report their existence/status back to the controller (you port-forward port 8080 to controller at home, use DynDNS for your internet IP if not fixed and define an inform-url for your remote devices.
Via this connection (inform) there's not much data transfer happening, and in case its not stable, you may see a component "heartbeat missed" or "disconnected" - thats not an indication of a local problem, its just a missing report.
Also, with this you do not need an internet-capable IP in the middle-east.
For sure, this allows you to do a VPN, but the VPN may also be not too stable (based on your expectations).
If you have two controllers, i would think that you do a VPN connection via a VPN client on one end and a VPN server on the other end - as there is no common configuration shared over the two.
Why not start with this approach and deploy a 2nd controller "if needed"?
Just a heads up on this.
As may be said above, there's load-balance and fail-over in the USG using the UI. Config options are limited to LB vs Failover, and with LB the percentage.
There are some betas out that have issues with enabling LB via GUI, but the latest (Controller and USG versions) have that fixed. Also, the "Sticky" thing was introduced out of the box now, ensuring that a single session stays on one WAN interface (as some servers misbehave if they see different IP's as source).
So that should be the base.
There's another Ubiquiti product, Edgerouter, that has the same OS and featureset (in CLI), but a completely different GUI. Let's call it the NERD version of Unifi. There's a lot of great info in that products forums and support pages. As you have special wishes for load balancing, you want to look at this:
This explains pretty good the typical things you need in a real-world deployment for load balancing, and it also describes how you can modify the routing based on your own needs, incuding failover options in case that WAN interface is no longer avail.
I have configured my wishes on my system based on that info, and merged that config changes into my setup via the supported processes of Unifi / Controller (config.json.properties file).
Ok, hearing this. So this has nothing to do with bridging.
Lets be more specific: On the outside, an USG has one (standard) or more (optional, manual config) IPs.
On a single IP you can offer a variety of services, and they will not conflict if set up properly.
On the inside, the USG spans its own network(s) - and you can have so many IPs as you want.
So you can plug the Cloud Key into the VOIP (2nd LAN) port of an USG3. Or in any switch port.
Or, you can run the cloud key ON the NAS if you like - its just what's called the controller software. It depends on what NAS you have, and its manual "do it your self" setup and support.
Or, you can run the controller on AWS or another cloud service, managing APs and other gear in any network.
Or, you can buy a controller instance from Unifi for a monthly fee (they call this Unifi Elite).
The easiest is: Plug it into the switch next to the USG and the NAS. Configure first your local UBNT devices (USG, Switch, APs). If that is working, then do a single port-forward (you can define the port you want) in USG to the cloud key Port 8080 so that you can adopt offsite devices.
Ok. # 1 is straightforward - that's what it has been designed for. Thats really easy and a first step.
2: I think this is all possible but requires deeper knowledge. Just as far as i know:
Yes you can have a 2nd IP. Yes you can use 2 lan ports and separate traffic. Bridging is… hm... i would say a term that people don't like on a secure gateway :) - you are discussing this only for cloud key.
As i explained before, if you just want multiple locations and a cloud key - then thats straightforward but does not require your # 2 at all. So what's the real goal of that part?