You’d think it would be simple: adopt the device locally, configure it (which works just fine), then move it to a remote site with its own public WAN connection and continue managing it. But nope — the moment you connect that second gateway to its own WAN, the ER7212PC’s built-in controller tries to re-adopt it. And of course, that fails — thanks to the “safety feature” mentioned earlier. And yes, this still fails even if you setup the correct NAT rules for 29810-29816 (TCP/UDP) and set the INFORM URL on the remote device to the public IP/FQDN of the controller, as well as the setting the required management settings on the controller side. Just, does, not, work.

Why does it need to re-adopt something it already adopted, just because it's on a different subnet? Yikes.

This seems like one of two things:

1. A bug in the ER7212PC’s built-in controller that prevents it from ever managing a second gateway remotely (despite claiming to support up to two),

OR

2. An intentional feature limitation. But what’s the point of “supporting two gateways” if they both have to be local? That makes absolutely no sense in 99% of real-world scenarios — nobody is buying this kind of gear to run multiple gateways on the same LAN segment.

Here’s another oddity: if you want to use the Auto option to set up a site-to-site VPN between two gateways, you must have both gateways managed by the same controller. The Auto setup requires you to choose the "Remote Site" — which must already be defined and managed by the controller.

So… who exactly is setting up site-to-site VPNs between two gateways sitting on the same network? Again, yikes.

Next step: I’ll try setting up the VPN manually between the ER7212PC and the ER7206. Then I’ll see if I can adopt the ER7206 through the tunnel. My guess? It'll work. But again — what’s the point? If the tunnel goes down but the remote WAN is still active, you lose management access to the remote gateway. Why? Because you’re only allowed to manage it through the tunnel in that scenario. DERP.

 

Another update:

Successfully set up a Site-to-Site VPN tunnel between the ER7212PC and an ER7206 — no issues. Everything worked great.

I then set the inform URL on the ER7206 to the internal IP of the ER7212PC. It showed up as “Pending” — great!

I adopted it to my second site — worked perfectly. Again, great!
 

Then it hit "CONFIGURING" — and the entire ER7206 reset to factory defaults. The VPN tunnel? Gone. All configuration? Gone. The remote subnet? Back to 192.168.0.0/24. It's no longer manageable.
 

Why is a full factory reset part of the adoption process? Seriously — what logic is this? Why would resetting a functioning, configured gateway be a required step? That’s not just bad design — that’s reckless.
 

The end result: You cannot adopt a remote gateway to the ER7212PC’s built-in controller. It simply doesn’t work. There’s no workaround. It’s not supported, despite what the specs or UI might lead you to believe.
 

Which raises the obvious question:
Why does it claim to support multiple sites and up to two managed gateways — if both gateways have to exist on the same local network? What is the use case here? One gateway in the basement and one in the kitchen?
 

Meanwhile, the OC200 has no problem adopting a remote ER7206 — I tested it. The same goes for the software controller running on a VM. It just works.

Conclusion: The ER7212PC’s built-in controller is fundamentally flawed when it comes to multi-site gateway management. It’s either a severe oversight or an intentional limitation — either way, it makes the multi-gateway feature completely useless in real-world scenarios.

Dumpster fire.