[Bug] GL GUI: Multi-WAN Interface Priority not honored/have effect

Technical Support for Routers
1

Device: Burme 2 (GL-MT2500)
Firmware: 4.2.3 release 5 (OpenWrt 21.02-SNAPSHOT)

Goal

tethering interface to be the primary Internet connection for the Multi-WAN setup while the Ethernet is also connected to the Burme 2’s WAN port.

Issue

The Ethernet takes priority for all Internet connections in a Multi-WAN setup but the tethered device offers a faster connection. Interface Priority is reported to have been adjusted within the GL GUI → Network → Multi-WAN → Interface Priority but does not seem to be honored/have an effect.

Diagnosis

  • Network configuration details for network interfaces are stored in the text file /etc/config/network
  • The Ethernet uses the wan network interface with a metric of 10. This sets its priority over any other interfaces.
  • The tethered device uses the tethering network interface with a metric of 30. Its higher value places it at a lower priority.

Proposed Resolution

Manually inverse the metrics affecting the interface priorities.

  • Edit & save the /etc/config/network to set tethering’s metric to 10 & wan’s metric to 30.
    • nano /etc/config/network
  • Restart the networking system
    • service network reload or /etc/init.d/network reload
  • Confirm the results

Reported Result

Tethered device now set as primary Internet connection; SpeedTest.net now reports 363.09/57.18 Mbps up/down vs 50 Mbps Ethernet.

Further Details

  • Device runs OpenWrt 21.02-SNAPSHOT; 21.02.0 was released 2021 Sep 04.
  • On 2022 Aug 4 a bug report was filed to OpenWrt reporting metrics were not correctly processed on a Target Platform: ipq806x/generic.

Source thread:

2

Multi-WAN does not work via /etc/config/netowk, it works according to the iptable+ip route in mwan3.

I retested the MT2500 v4.2.3 for tethering first priority and found that it worked fine.

If you repeat this problem again, can you follow my screenshot to debug the message and share it?

image
image1424×889 69.4 KB

3

Would an active WireGuard Client session impact mwan3 by holding/locking the interface to the current set of iptables + route & not allow mwan3 to make the necessary adjustments? In the linked source thread there’s ip route output showing active WG while the metric was still 10 on eth0 after confirming the GL GUI → Network → Multi-WAN → Interface Priority was set but was was reported to have not changed as desired.

I overlooked the WG tunnel in the output at the time so I’m now wondering if the active WG Client was the true cause.

I had somewhat of a feeling it didn’t but I was under the impression GL GUI’s Interface Priority was already set but non-working so I went w/ what I knew.

See the source/originating thread. I’d think @scumball would be interested to know of a proper solution rather than my less than ideal workaround.

4

I can confirm this also becomes an issue when you set up a Wireguard server in Multi-WAN in load balance mode. Unless you change to failover mode or manually edit the metric values in LuCI or /etc/config/network, the Wireguard server will only listen on the ethernet port.

This was problematic in my case, since the ethernet port is actually plugged through a wireless bridge and as such less favourable than the direct WWAN. In order to get Wireguard to listen on WWAN, I had to edit the metric values for the interfaces /etc/config/network

1 Like
5

So I’m not as mistaken as I thought I was. Thank you.

It seems to me this could be resolved by a GL GUI modal box/prompt notifying/warning the user all interfaces in /etc/config/network would need to be force released before refreshing to allow mwan3’s updated configuration to take effect.

I’d think the user would want to explicitly be informed beforehand & the option be present to cancel the change least there be inadvertent VPN leaks.