@RicardoVzqz 

you can simply change to the same 192.168.0.1/16 and test again

It is a misconception to think that you can route traffic between subnets by changing subnet masks, for example from /24 to /16. This way you just make one of the subnets (broadcast domain) bigger and create yourself problems. To route traffic between subnets, you need gateways in those subnets with proper routes. That’s probably not possible In this particular case, because two different VPN solutions are used.

  @RicardoVzqz 

Sorry, I can’t offer you any solution. I don’t have much VPN experience. However, I would certainly try other VPN implementations. I find the ER7206’s VPN implementations too limited even for my modest needs.

  @KJK 

can you explain a little bit more on this: https://www.tp-link.com/en/support/faq/3363/

  @RicardoVzqz 

so here's the guide, you can either follow this guide which I sent earlier. read it carefully. don't expect others to correct your settings. https://www.tp-link.com/en/support/faq/3363/

if you implement this and it fails, then it is not supported on the controller yet. this is a guide to achieve what you asked for in standalone mode. 

the reason why the controller warns you could be the controller design. but this should work because I've sent the same thing to other people like you. 

  @Tedd404 

That’s the first article I see where TP-Link instructs using subnet masks in that way. Without trying that out, I need to give TP-Link the benefit of doubt. However, their explanation of the use of the /16 mask is wrong. Just by looking at any routing table, one does not need to be a networking expert to see that more information is needed than one single subnet mask to set up IP routing. They must be looking at the whole router configuration for that. Although that’s a wrong explanation, I do not think that they really suggest that one can establish routing between subnets by simply changing a subnet mask.

It’s been a while when I tried to use the OpenVPN server on ER7206 in my multi-subnet network. Although at that time the router was handling inter-subnet routing, all I could do is to connect to just one any given subnet without access to the other subnets. After analyzing the issue, I came to the conclusion that TP-Link implemented one of the two OpenVPN server modes that required setting up IP routes on the OpenVPN server itself. Lacking options on the router to achieve that, I set up an OpenVPN server on my Synology NAS. That worked very well. It turned out that Synology implemented the other OpenVPN server mode that easily and nicely integrates with multi-subnet networks. Maybe the OP can try that, too.