Your instructions did not work. And the VPN providerās instructions also did not work. When I followed the VPN service providerās instructions after trying the GL.inet instructions, a routing conflict effectively bricked my router, because I could not log in any more.
I need Wireguard because OpenVPN does not provide adequate performance on small devices. So I purchased another GL.inet router because your web site implies that Wireguard functions correctly. But for me it did not work correctly:
It seems these instructions only work if the user controls both end points. Where one is using a VPN proxy service, the instructions provided by GL.inet and the VPN provider both do not work. Yet the VPN providerās instructions did work correctly on a different brand of router running LEDE.
There are also some syntax errors in your instructions, for example, in āWireGuard - GL.iNet Docsā
config zone
option name 'wg-vpn'
ā āwg-vpnā is an invalid name for the interface. (The ā-ā character is not allowed, and the GUI will give a warning if you attempt to add this interface name in LuCI.)
I did not post on this subject to annoy you or complain about the wait for the new GUI. I just want you to be aware that the Wireguard setup instructions on your web site do not always work if the user does not control both end points.
I also want you to know that an API exists which will permit the internet proxy service provider to automatically configure the clientās router for Wireguard. Your GUI should support this feature if you want VPN users to purchase the hardware. That is not a complaint, it is valuable business intelligence:
In another year or two, when Wireguard is more widely deployed by commercial VPN service providers, the client devices which support this API will have a big advantage in the market.
The point I am trying to make here is that the GUI support for Wireguard clients will be the primary selection criteria for many people who purchase a travel router. A simple setup procedure will be all that matters, and the hardware specifications will become less important. So I think you should devote more resources to software development, and less on creating new models of hardware.
Despite all of these problems, I did not give you a bad review on any web site. I still like GL.inet because the products ship with extensible open source software that automatically updates. This means I do not need to spend time on manually updating custom-configured endpoints which I have to manage for clients. So I still recommend GLi in many cases, but I still need better Wireguard support. Until then, it should not be too difficult to include the monitoring module in the repo:
āI also created a monitoring module. It is called luci-app-wireguard and should be available in all major repositories.ā
https://danrl.com/blog/2017/luci-proto-wireguard/
Both systems were running in the same local subnet.
