Speed throttled in Multi-WAN Load Balance with VLANs on WAN port (GL-BE3600 / Slate 7)

Dear GL.iNet Support Team,first of all: thank you very much for creating such a capable and compact travel router with excellent hardware (2.5 Gbps ports, Wi-Fi 7, strong CPU). I really enjoy using the Slate 7 and appreciate the effort that goes into making OpenWrt-based devices accessible to a wider audience.I would like to share my current setup and a performance issue I’m experiencing, in the hope that you might have an idea or could consider it for future firmware improvements.

My current setup:

  • GL-BE3600 (Slate 7) running the latest stable firmware
  • WAN port (eth0) receives two VLAN-tagged services from upstream:
    • VLAN 10 → DSL (Deutsche Telekom, ~250/40 Mbit/s, DHCP client)
    • VLAN 20 → Starlink and LTE (via GL-X2000 in bypass mode, DHCP client)
  • In LuCI I created two VLAN devices (eth0.10 and eth0.20) and assigned them to the existing interfaces “wan” and “secondwan”
  • Multi-WAN is configured in Load Balance mode (not Failover) with a ratio that prefers DSL
  • No additional slow 100 Mbit/s devices are connected; only one LAN port is used for testing (laptop directly connected via cable).

The observed problem:

  • Download speed through the Slate 7 reaches nearly full DSL performance (~220–240 Mbit/s) only by LAN-port testing. On Wifi, the speed is throttled about 110 Mbit/s down.
  • Upload speed is massively throttled to ~3–12 Mbit/s (instead of the expected ~35–40 Mbit/s on DSL or ~20–40 Mbit/s on Starlink) by LAN-port testing. With WiFi testing, I've got full speed.
  • The same throttled upload behavior appears in both Load Balance and when forcing Failover to Starlink (DSL cable unplugged)
  • When bypassing the Slate 7 completely and connecting the laptop directly to the FritzBox LAN WLAN (DSL only), I get full symmetric performance (~220/37 Mbit/s). Same applies for my Starlink connection on GL-X2000. Both sources are running smoothly. Wired and wirelessly.
root@GL-BE3600:~# ethtool eth0.10
Settings for eth0.10:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
                                2500baseT/Full 
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
                                2500baseT/Full 
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  10baseT/Half 10baseT/Full 
                                             100baseT/Half 100baseT/Full 
                                             1000baseT/Full 
        Link partner advertised pause frame use: Transmit-only
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 24
        Transceiver: external
        Auto-negotiation: on
        Link detected: yes
root@GL-BE3600:~# ethtool eth0.20
Settings for eth0.20:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
                                2500baseT/Full 
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
                                2500baseT/Full 
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  10baseT/Half 10baseT/Full 
                                             100baseT/Half 100baseT/Full 
                                             1000baseT/Full 
        Link partner advertised pause frame use: Transmit-only
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 24
        Transceiver: external
        Auto-negotiation: on
        Link detected: yes

Why VLANs are essential for me:

I deliberately use VLANs on the single WAN RJ45 port because I want to keep the second physical port free as a normal LAN port for local devices (laptop, NAS, switch, etc.). Having two separate RJ45 WAN ports would be very convenient, but since the hardware only provides one WAN port, VLAN trunking on that port is the only realistic way to realize two independent WAN services without sacrificing LAN connectivity.

My feature request / feedback:

I understand that the Slate 7 is positioned as an end-user travel router and not primarily as an enterprise device. Still, the underlying OpenWrt platform makes it attractive for more advanced users who want to leverage VLANs, custom interfaces and Multi-WAN in non-standard ways. From my perspective it would be a fantastic pro-feature if the GL.iNet middleware (your nice and intuitive web interface) would offer native, first-class support for assigning VLANs directly to WAN interfaces in a way that does not degrade throughput (especially upload).

There already seem to be VLAN-related fields in the UI (e.g. for cellular/tethering use cases), but they appear limited in scope.

I would be very grateful if you could:

  • let me know whether this asymmetric upload throttling in Load Balance + VLANs on WAN is a known limitation
  • share any configuration tips that might mitigate the issue while keeping VLANs on the WAN port
  • consider improving VLAN handling on the WAN port for future firmware versions (better offloading compatibility, MTU/MSS handling, or explicit Load-Balance tuning options)

Thank you very much in advance for your time and support.

I’m happy to provide screenshots, configuration exports or SSH access logs if that helps.

Best regards.

The best and most stable connection I‘ve got is under 5 Ghz only. All the other wifi networks are disabled.

Hi

We attempted to reproduce a similar test locally using BE3600 v4.8.3, but were unable to replicate the issue.

Topology:

Speed test results (able to reach full speed on a single link):

We recommend the following:

  1. Connect to each ISP individually to verify the performance of the BE3600 and each single link:
PC - BE3600 - DSL
PC - BE3600 - Starlink 
  1. Test both wired and wireless connections separately to confirm that the bottleneck is not there.

Additionally, please note that the same website or application typically uses only a single interface in Load Balance mode, so the bandwidth will not be aggregated.

You may want to try using a P2P download application, such as BitTorrent. With enough peer connections, you may be able to observe aggregated bandwidth.

1 Like

Local connections work like a charm. :rabbit::dashing_away:
It must be an issue with load balancing / multi-wan.

LAN speed

WiFi (5G) sitting next to the Slate 7
821 Mbit/s down
748 Mbit/s up

Peer 2 Peer tests with downloading some linux iso‘s via transmission, that the speed is around 150-250 Mbit/s.

So at this point:

  1. When the BE3600 is connected to DSL or Starlink individually, both wired and wireless speeds are as expected.
  2. Regarding the OpenSpeedTest, could you clarify whether the server is deployed on the BE3600, or on an upstream router (as in our test setup)? Only the latter can accurately reflect whether performance remains normal after multi-WAN load balancing.
  3. If you disable our kmwan and switch to mwan3, does the behavior change?
/etc/init.d/kmwan stop
/etc/init.d/kmwan disable

opkg update && opkg install luci-app-mwan3

Feedback regarding Multi-WAN Testing on GL-BE3600

Issue: Technical failure when switching from kmwan to mwan3 as suggested.

1. Syntax Error in Default Firmware: The file /etc/hotplug.d/iface/99-ecm contains a syntax error in line 3: is_vpn=echo $INTERFACE | grep -e "^wg*" -e "^ovpn*` The closing quote and backtick are missing. This causes shell errors every time a network interface triggers a hotplug event.

2. Firewall / NFTables Incompatibility: The GL-BE3600 uses fw4 (nftables). The standard mwan3 package (or the configuration provided) still tries to create iptables rules in the mangle table. This resulted in the error: chain 'mwan3_hook' in table 'mangle' is incompatible, use 'nft' tool.

3. Infinite Loop / Console Flooding: After disabling kmwan and starting mwan3, the system entered an infinite loop of failed ip route commands. This flooded the SSH console with the "Usage: ip route" help text, making the CLI virtually unusable. The service was unable to correctly map the logical interfaces (like eth0.10) to the routing tables.

4. Performance/Stability: The transition from the kernel-based kmwan to the user-space mwan3 is not "plug-and-play" on this model. It breaks the integration with the Qualcomm hardware offloading (ECM/SFE).

The suggestion to switch to mwan3 is currently not viable for me and other end-users on the GL-BE3600 without a pre-configured, nftables-compatible mwan3 build and a fixed hotplug script.

I am reverting to factory defaults and staying with the stock kmwan solution.