Thanks a lot! It sounds good, but it seems too complicated for me. Still, if it can be done from the command line, I assume it can also be made to work from a GUI.
Thank you very much — I look forward to the development and to seeing this new feature appear in a future firmware release.
This makes me sad, because the Mango form factor is brilliant for travel. I understand though, because it is slow. The slow I can live with, but having two or three VPN connections for the WAN is useful for travel. You've added 4.8 to the Mudi, and that also is a single core chip only with a slightly higher clock rate.
I take it the Beryl is also going to be orphaned.
I think it is not perse about slowness or performance, but the router flash becomes too full.
My last visit on this device was when configuring for a print server, it was very tricky now is such requirement maybe 10kb, but I took note that the flash is really full to almost non functional, it is very normal that flash is also shared as ram.
Though I hope GL still takes this device as what the community wanted in regards of updates, even though that I haven't much use case for it, ironically it always was using the most recent OpenWrt and not vendor sdks 
A few years ago I used imagebuilder to add and subtract things from the firmware. I would happily jettison the captive portal and the 1mb of mac assignments to get the VPN setup in 4.8 on the Mango.
yuxin.zou the multi-vpn feature is made and works perfectly. This makes gl.inet the best router out there. You guys are incredible!
Hi Bruce
I’m following up on my previous question regarding the possibility of running independent VPN client tunnels on each WAN interface while using Multi-WAN load balancing.
Back in December you mentioned that you would collect this request and evaluate it with the PM team. I would like to kindly ask whether there has been any progress on this topic since then, or if it has been considered for upcoming firmware releases.
In particular, I’m interested to know whether this functionality is being planned or discussed for devices such as the Spitz Plus (GL-X2000), or if the current architecture makes this unlikely to be implemented.
Any update you can share about the status of this request would be greatly appreciated.
Thank you again for your time and assistance.
Best regards
Imre
Hello,
We have submitted this requirement to the PM team, and it is being opened, we have evaluated that the number of requests is not large, and it has not been scheduled for development.
We have to receive more requests before this demand can potentially be pushed.
Thank you very much for your feedback, we will continue to collect.
Hi Bruce,
Thank you very much for your reply and for following up with the PM team — I really appreciate it.
I must admit I find it hard to understand why GL.iNet routers that already support both load‑balancing and VPN individually cannot handle independent VPN client tunnels per WAN interface alongside Multi‑WAN load balancing. Earlier Multi‑WAN routers, such as the TP‑Link TL‑R470T+ (circa 2011), already offered this kind of combined functionality, even with older VPN protocols.
It also seems surprising that this feature has not generated more requests, as from a user perspective it is important to maintain redundant internet connections while ensuring that every WAN connection is secured with VPN. To help raise visibility, I’m considering opening a dedicated feature request thread in the forum, separate from the current firmware discussion.
Thanks again for your support, and I look forward to any further updates.
Kind regards,
Imre
Helle,
I understand that from a user's viewpoint, this combined functionality seems like a natural extension of Multi-WAN and VPN features. In modern firmware architectures based on OpenWrt, implementing independent VPN tunnels that bind strictly to specific WAN interfaces while maintaining a load-balancing weight involves complex routing policy interactions (kmwan, DNS/ADG and VPN policy). While it is technically achievable, ensuring stability for all users requires significant development and QA resources.
You can open a separate thread to discuss this request with more users.
We can keep an eye on that thread and continue to advocate for this internally.
Thank you again for helping us make GL.iNet products better!
Hi Bruce,
Thank you for the detailed explanation — I appreciate the insight into the technical challenges involved.
I have already opened a separate feature request thread to gather feedback and increase visibility:
Hopefully, with more user input, this can help demonstrate the demand more clearly.
Thanks again for your support!