Hello Everyone,
I’m new here, nice to find out this forum.
I have an issue with connectivity. I would like to reach webserver of the device connected to LAN of the MT300N-V2 router, by an external PC connected to VPN. In this project MT300 is VPN Client and Asus router is VPN server. I’m using Open VPN connection.
I’m able to establish VPN connection between routers. Then I tried to make forwarding ports from the Device to VPN. I even got the connection between PC and DEVICE, but the connection is very poor, need to wait ~1min to show something. HTTP doesn’t load correctly. The speed of the internet in both side is OK. It looks like something inside the MT300N-V2 is blocking packages. What should I do to fix it? Can you help me? In the attachment you can find a simple diagram what I’m saying about.
This project could be extended to at least 300 MT300 routers is VPN network if everything will be OK.
If I understand your setup correctly, you should not have to forward ports from the Device to VPN.
On the GL-MT300N-V2 OpenVPN Client settings, have you tried turning on Access Local Network?
I do not work for and I do not have formal association with GL.iNet
Thanks for reply. Yes I tried both scenarios. Didn’t help. What should I do then, instead of forward?
Can you run a trace route (Windows tracert) from PC (VPN Client) to the DEVICE (Webserver)? Also, try connecting a different device on the GL-MT300N-V2 to see if you can access it. I suspect the traffic is not being directly passed onto the local LAN.
Unfortunately I can’t trace DEVICE by PC VPN Client. Maybe I should make some static route instead of forwarding?
You need to do port forward from vpn zone to lan on MT300N-V2, then use the vpn IP to access.
Openvpn is slow on the router. Maybe try wireguard.
Asus router doesn’t support WireGuard, only OpenVPN and PPTP… 
It would be helpful to know what model of Asus router you have. On the Asus, you will need to define a route, so that the PC VPN Client knows how to reach the Device. Also, normally the OpenVPN server will block traffic from one VPN client to another VPN client.
I don’t follow, also, what you mean by extending to 300 MT300N clients. Do you envision 300 webservers connected through those clients? and reached by whom? Simultaneously? If you want possibly as many as 300 clients connecting over vpn to the webserver, but not simultaneously, you might be able to do it, but you will want to put the webserver off the OpenVPN server, with multiple clients connecting to the server at any one time.
Don’t use Asus router. Use tailsacle or zero tier which work as relay.
What is the purpose of the OpenVPN Client setting Access Local Network? I thought it should handle port forwarding and any router changes to access attached client devices. If not, do you have a link to a procedure?
This is the correct solution, but probably want to pick a different port 8080 and forward to the LAN client at port 80. You’ll also need to make sure that the VPN server allows clients to talk to each other. So from the PC you’ll hit http://10.10.5.6:8080, and get that forwarded down to the device.
If you’re actually going to scale this to 300 clients, you’re going to need something more than a stock ASUS router. For one thing, you’re going to need to go up to a /23 or /22 address block, since you’ll run out of addresses on a /24. I’d recommend getting a pfSense or OPNsense box, which are going to be able to handle that traffic. I would absolutely not recommend using WireGuard for a solution that involves hundreds of endpoints. Whatever its virtues, it is not manageable at scale. Depending on what the actual device is, you could run Tailscale or Zerotier (or Nebula) with your own self hosted control server (headscale) and then it’s kind of taken care of for you, and the MT300 isn’t doing the heavy lifting on the processing side of things.
The issue in this case is that he wants to access the local network from a different VPN client rather than the VPN server (which is what the access local network part does). You’d have to write routing rules on both the 10.10.5.10 client (to know to send 192.168.8.0/24 to the VPN server) and on the server to forward that traffic back out to the 10.10.5.6 client. This can be done, but then you have another issue - each subnet on the other clients has to be unique, which is a severe PITA if you have 300 clients (don’t ask me how I know). IMO it’s easier to do all of this in pf rather than iptables, but it can be done either way. It’s just a huge pain.
Does your Asus router have OpenVPN settings for Manage Client Specific Options? The following is from my RT-AX88U running AsusWRT Merlin Firmware 386.x, but may be somewhat different on other models/versions.
If so, then you can try adding an Allowed Clients for the DEVICE (webserver) subnet to create an additional VPN route from the Asus router to the GL.iNet router. In your case, the subnet would be 192.168.8.0 and try ping 192.168.8.198.
EDIT:
I tested this on another GL.iNet router as OpenVPN client (I do not have a GL-MT300N-V2) and it works with the additional VPN route created.
I was able to access a website on a PC connected to LAN port on the GL.iNet router. I was also able to access the Admin Portal of the GL.iNet router. I also pinged both.
The principle is described in the following URL:
To quote the famous movie, “I do not think it means what you think it means.” (https://www.youtube.com/watch?v=dTRKCXC0JFg)
That “Allow client ↔ client” setting is important, though.
The option only make the firewall from drop to accept. But does not handle port forward etc.
It cannot handle port forward, but can do DMZ, which may not be the user want.
It can also handle routing, but routing should be processed in all the nodes of the vpn, not only one node. Like our S2S solution need to push the routing to all nodes via cloud.
It would be good to document the Access Local Network setting, in terms of what it does and does not.
Per my previous post, I tested that it functions with the OpenVPN server on Asus router (at least on my RT-AX88U), so server LAN devices are able to access client LAN devices.
AsusMerlin opens up a lot of flexibility, which is why I asked what model he had; what @wcs2228 describes is how I have three sites more or less permanently connected site to site, with other devices connecting on occasion with access to any of them but not with their local networks accessible. But this is where memory comes into play and the topology needs to be addressed. If it is a question of possibly 300 clients accessing 1 server on one of the clients, that is one thing. Doable, but it would make more sense to move the server to the openvpn server and then use duplicate-cn. But 300 site to sites is another thing entirely and requires unique user names, which if I recall in Merlin is limited to 32 for memory reasons. If, as I suspect, those 300 clients are not connected simultaneously, then the Asus might handle it or a farm of openvpn servers behind it could be deployed to match the needed capacity with roundrobin remotes in the configuration.
I’m still unclear on what the OP is looking to do.
I could be wrong, but what it seems like they’re trying to do is a pretty common use case in edge sensor/IoT platforms - you’ve got some sort of low powered devices in the field that you need to poll data from. It’s generally better practice to have those devices push, but for various reasons people still like to do polling. That’s not the use case that most people on this forum have, though, so their immediate thought is to set up 300 site-to-site networks, when that’s really not needed (disclosure: that was my first thought when I had to set up a product like this. I ended up with almost 100 /29’s before I figured out that was a stupid idea. And better solutions were developed).
The easiest solution for something like this (today) is to use something like Nebula or Tailscale on the actual device that takes care of things for you, more or less. Both will let you self-host your own control servers, let you expire keys/machines, deal well with weird NAT situations, and will even let you subnet route/relay if you need to. They also scale a lot better than OpenVPN does in terms of clients (I’ve got about 800 ovpn clients connecting in right now and even on powerful hardware it’s a mess). If you have to go the OpenVPN route, forwarding ports from the client VPN IP to the internal subnet (and keeping the internal subnet constant across all your client devices) is a much more clean solution.
My current deployment uses a couple of routes - 1) OpenVPN clients connecting in from our routers using individual user/pw combinations and certificates. 2) Nebula for all units going forward, which is actually a super easy PKI to manage programmatically. Of course, our main data channels actually don’t run over the VPNs in most cases, and we’ve got plenty of redundancy built in to do disaster recovery if necessary.
Again, I may be wrong, but this looks a lot like what we did early on in our product cycle, and what a lot of papers I review try to do in the beginning before they realize how hard it is to operate something like that at scale.
Since the link I provided is directly from Asus, it is likely that the feature already exists in stock Asus firmware.
In looking at the OpenVPN server startup log and the routing table, the only difference is that a route is added for Destination 192.168.253.0/24 via Gateway 10.8.0.2 on the Interface tun21.. It may be possible that a number of routes can be manually added to accomplish the same effect, instead of entering in Allowed Clients with unique CN’s (I have not tested this).
I agree that consumer routers are not intended support 300 VPN tunnels at the same time and the router represents a single point of failure that can take down the entire network. A farm of OpenVPN servers may be better, which will require more ongoing administration/maintenance. Enterprise-level equipment and/or commercial cloud solution may be more suitable. I would also reconsider the VPN approach in general.
We do not have much detail on the overall design/application. To that end, I can only provide information on the specific issues.