Feature Request: Independent VPN per WAN in Multi‑WAN Load Balancing

Hi all,

Would anyone else find it useful to run independent VPN tunnels on each WAN interface while using Multi‑WAN load balancing on GL.iNet routers? Currently, with VPN enabled, only failover mode is possible — true load balancing cannot be used simultaneously.

Earlier Multi‑WAN routers, like the TP‑Link TL‑R470T+ (2011), already offered this as a basic feature, even with older VPN protocols. I am convinced that modern GL.iNet hardware is more than capable of handling it.

If this feature would be useful for you, please reply or “like” this post — the more visible the demand, the higher the chances the PM team will prioritize it.

Thanks!

Hi

We noticed that you previously mentioned the same request. As Bruce said, we have already submitted it to the product team for evaluation.

However, the evaluation and integration of new features may not be completed quickly. We appreciate your understanding.

This thread will remain open. Everyone is welcome to share whether they have similar needs and their specific use cases, so we can better evaluate the demand and design the feature to further improve our products.

1 Like

Thank you for the clarification and for keeping this thread open.

You are right that I mentioned this request earlier in other discussions. In fact, it has been almost three years since I first raised this topic. Over that time, I asked about this feature in a few different contexts (for example in router-specific threads like Flint 2 / Flint 3 and also in a firmware discussion), because originally my question was related to those particular devices.

However, over time it became clear that this is not really a router-specific question, but rather a general feature request related to GL.iNet routers that support both Multi-WAN load balancing and VPN client connections.

Looking back, it was probably not the best approach to ask about it in several device-specific or firmware threads, since the request became scattered across different discussions and therefore did not get much visibility. That is why I decided to open this separate feature request thread, so the topic can be discussed in one place and the actual demand for it can be seen more clearly.

I believe this functionality could be very useful for users who rely on multiple WAN connections for redundancy while also wanting VPN protection on all active connections.

If anyone else would benefit from this feature, it would be great if you could share your use cases here as well. That should help the team better evaluate the demand.

Thanks again for taking the time to review this request.

2 Likes

Use case: Multi-WAN load balancing with full VPN protection requires additional hardware

One practical use case I’d like to share:

Let’s take a router like the GL.iNet Flint 2, which has:

  • multiple dedicated WAN ports

  • Multi-WAN load balancing

  • built-in VPN client support

However, with the current firmware, when VPN is used, the router can only operate in failover mode — true load balancing cannot be used at the same time.

If I want to have all WAN connections protected by VPN while still using load balancing, I currently need to introduce additional devices.

For example, with two wired internet connections:

ISP 1 → Brume 3 → Flint 2 (WAN1)
ISP 2 → Brume 3 → Flint 2 (WAN2)

In this setup:

  • the Brume 3 devices establish the VPN tunnels

  • the Flint 2 only performs load balancing

  • its built-in VPN capability remains unused

Another example with mixed connections:

Mobile network → Spitz Plus (VPN) → Flint 2 (WAN1)
Wired ISP → Brume 3 (VPN) → Flint 2 (WAN2)

Again, the Flint 2 is only used for load balancing.

Conclusion:

If I want true Multi-WAN load balancing and VPN protection on all active WAN connections, I currently need to purchase and operate additional hardware.

Being able to run independent VPN tunnels per WAN interface directly on the router would eliminate this complexity and make much better use of the router’s existing capabilities.

3 Likes

Another reason why I believe this feature would be valuable is that similar setups are already possible on platforms like MikroTik RouterOS using policy routing and per-interface VPN routing.

For example, routers such as the MikroTik RB5009 can be configured to use:

  • multiple WAN connections simultaneously,

  • load balancing,

  • and separate VPN tunnels bound to specific WAN interfaces.

So technically, this type of setup is clearly achievable on modern routing hardware.

However, MikroTik configuration is often quite complex and requires advanced networking knowledge. One of the biggest strengths of GL.iNet routers is exactly the opposite: the GL GUI and overall user experience are much more user-friendly and accessible, while still offering powerful networking features on top of OpenWrt.

That is why I think native support for independent VPN tunnels per WAN interface would fit very well into the GL.iNet ecosystem and would make advanced Multi-WAN setups available to a much wider group of users.

https://forum.gl-inet.com/t/vpn-client-not-adhering-to-dual-wan-setting/38054/3

https://forum.gl-inet.com/t/vpn-loadbalancing/51552

1 Like

Thank you for the update.

We have updated our internal records accordingly so that the product team can better evaluate the demand for this feature.

1 Like

Using the GL.iNet Flint 2 GL-MT6000 v.4.9.0 as a Wireguard VPN server with active Multi-WAN Load Balancing causes inbound VPN traffic to fail due to asymmetric routing. When a connection initiates on one WAN (ISP 1), the router's load balancer often routes the return packet through the other WAN (ISP 2), causing the upstream ISP or client to drop the connection. Waiting for bind function for native Wireguard server from gl panel like sticky connection or similar. Thanks.

1 Like

Thanks for sharing your use case.

My request is slightly different (multiple WireGuard clients on separate WAN interfaces with load balancing), but both scenarios seem to highlight the same limitation: VPN interfaces cannot currently be tied closely enough to specific WAN interfaces when Multi-WAN is enabled.

In your case this appears as asymmetric routing on a WireGuard server, while in my case it prevents using independent VPN tunnels across multiple WAN links.

It's useful to see another real-world Multi-WAN + VPN use case.

1 Like