With all due respect, you guys are missing the most popular use case that draws people to mesh VPNs. Most people just want to setup two tailscale instances; one at home on their LAN (which has access to multiple vlans) on a router, VM, whatever and then they want to travel with another one (on a gl.inet travel router). The instance at home is likely setup as a subnet router and it’s likely advertising routes to multiple vlans; it could also be setup as an exit node (that’s a separate thing). The one their traveling with them and it’s could be setup as a subnet router and it could be setup as an exit node (thought not via the gl.inet web ui), however in most cases they’re just looking for the travel router to join their tailnet and then allow whatever clients are connected to the gl.inet travel router to reach ANY vlans that are advertised by any subnet router on the tailnet and you’re implementation does not allow that to happen at all. It doesn’t matter if you turn on “allow remote access WAN” or “allow remote access LAN” .. clients on the gl.inet router can still not access clients that are behind a subnet router on the tailnet.
Let me try to illustrate this another way by trying to describe the most popular use case…
Home network looks like this.. you have a router that has three VLANs: 192.168.1.x (default, likely has servers running like jellyfin, home assistant, a tailscale instance setup as a subnet router advertising routes to 1.x,2.x,3.x inside a VM, etc.. things in this vlan have one way + established/related access to every other vlan), 192.168.2.x (iot, likely has random untrusted devices, could also include Apple TVs, printers, etc), 192.168.3.x (kids, has devices kids use, maybe one of the kid’s is a teenager and runs a game server for their friends). The important thing to take notice of and remember is that this entire network (all 3 vlans) is accessible on the owner’s tailnet by way of a single subnet router. The ONLY thing appearing on the tailnet is a single tailscale instance (could be on anything.. that’s not even important), yet every single server/service/device is 100% accessible to ANY other device on the tailnet at their normal LAN IP (192.168.1/.2/.3.x). No tailscale magic dns, none of that nonsense..
GL.inet travel router (slate) travels with the owner/family to vacation. The slate connects to some random wifi and all the family’s devices (phones, computers, tablets, Apple TV) that traveled with them all connect to the travel router, that’s great and all, but what they want is to access everything back at home as if they were there. The owner says “oh hey, I have a tailscale subnet router at home.. let me connect this slate to my tailnet and then we should all be able to access all our stuff at home.” Except… the way GL.inet implemented tailscale, that isn’t even possible from the web ui no matter what you enable. You need to be masquerading tailscale out the wan, there is absolutely no way around this. This is highlighted time and time again almost everywhere on the internet.
If you refer back to all the posts I made in the other thread (this post in particular.. Tailscale cannot reach subnets on other devices - #72 by pcmike ) I explain the proper way to implement this so that actual tailscale client’s identities (their tailnet IPs) are preserved (not that anyone in the above circumstance even cares, because there is literally only two tailnet clients in play here).
So again, whatever it is you think you’re doing or preventing from happening is the very thing everyone wants! People just want their travel router to connect to their tailnet in a way that allows all the clients locally connected to the travel router the ability to access literally any device that may be available via the tailnet EVEN IF THAT DEVICE IS BEHIND A SUBNET ROUTER! You have no reason to protect or prevent this behavior.. it’s exactly the reason people are using tailscale on their travel router! You guys are too preoccupied with thinking that people are installing tailscale on every device/service that they may want to access via the travel router and that’s simply not the case. #subnetroutersmatter
IF I MAY BE SO BOLD… I recommend adding an additional option on the tailscale page on the web ui that reads “Allow access to devices behind subnet routers via masquerading” that when enabled disables the other two “Allow” options and then simply institutes the changes I recommended; then we can finally put this ongoing saga to rest. 
