@Cepheus0815 

you only need a controller, switcher and access points you can adopt in the vpn tunnel, but i would not recommend it with the router. it is a very complicated procedure and if something happens to the vpn tunnel you have no way to fix it since the remote router will be offline.
you need to port NAT in UDP 29810 and TCP 29811-29816 to the controller, you also need the management ip for device upgrade, TCP port 443 then you can adopt the devices on the remote site via WAN ip on the site where the controller is.

  @MR.S 

while i agree that using the port forwarding at the OC200 host site approach is much easier for adoption of remote sites, i really, REALLY dont like that you have to expose port 443 (or whatever you set the https port on the controller to be) to the internet at large.  Even though this forward on to the controller, its not a sure fire way of negating https attacks and the ports are listed as fully open on external port scans

I choose to adopt through the VPN tunnel, setting each devices controller IP to the controller IP on its host site subnet - as long as the VPN tunnel connects the host and remote site default/core/whatever you want to call it VLAN, it seems to work just fine, even firmware updates.

Once properly configured, if the VPN drops, the WAN has gone down, and then remote management wont work anyway you set it up.

Neither method is the best or most reliable way, and both have their merits and downsides.

  @GRL 

I have tested both and if something happens with the VPN it is impossible to fix it without doing a factory reset of the router and starting over. I agree that it is quite poorly thought out by TP-Link to use the management port for device upgrades, I wonder what they have in mind, not security in any case. But to secure access to controllers you can use 2FA to log in to the controller, then it is quite secure. If there was an easier way to adopt the router via VPN I would have agreed with you :-)

Thanks for the answers! One question, if the VPN tunnel drops for some time, the branch site will work as configured, correct?

  @MR.S 

I actually use both methods

My Host network is at my main place of work.  HIghly secured, deals with GDPR data, children and customer info etc, there is no way in hell im exposing 443 to the internet there, regardless of the security measures in place on the controller, its just too big of an attack vector.  All remote sites have to use the VPN method.  If there is an issue, i just have to accept i have to physically go there to sort it, its not a huge big deal.

At my other place of work, there is essentially nothing of importance on the LAN side of the host network, to the point it doesnt matter much if an attacker does get in, there would be nothing to do.  So for that one, i have my own home ER650 v2 using the port forwarding method of adoption to that site since its easier.

The necessity of opening the https port for remote update is absolutely insane though - they must have their reasons, but it seems very short-sighted that it is the "correct" way

  @Cepheus0815 

yes it will carry on as it was configured regardless.

  @MR.S what do you mean by, something happens to the VPN? Of course there can be an outage, but will it not reconnect, when connectivity is established again?

  @Cepheus0815 

the main risk of the vpn method is if you mess up the VPN settings or even an ACL setting (that controls host network IP access )on the remote site to the point it CANNOT connect to the host site.  At that point, you are stuffed and will have to physically intervene.

If you choose the VPN method, make absolutely certain you are happy wioth the tunnel settings, it gives you everything you need access to, then leave it the hell alone.

If you mess up the Host site VPN, you can correct it and the remote will reconnect when it can.  But you mess up the remote one.....tough luck!

  @Cepheus0815 

I forgot to add - there is a mitigation you can put in place with the port forward method.....

The controller at host site will happily fully manage the remote sites with only ports 29810-29816 being forwarded.  You only have to enable port 443 (or whatever) when you need to do a firmware update at the remote site, you can leave it disabled otherwise.

Thank you! Very helpful!