List of current feature requests 2023

[smiths]

Great list, I think it is going ot keep you busy!

Looking forward to kicking the SIP ALG arounf when it is added, my day job is VoIP. LINUX SIP ALG typically deployed as all on or off in the old days was very problematic. Modern LINUX lets you define on for only certain flows, and also lets you define the RTP from different IP address, useful for PBX behind NAT. Hopefully these use cases will all be considered!

Simon

[ad-d]

Can we please have an option for the switch on the side of the router (eg my GL-AR300M travel routers but also any others with switches) to be able to swap between VPN entries just like it can be used to switch VPN on/off? I’ve set mine to autoconnect to VPN when router starts up but sometimes I want to swap between VPN providers and having to login to the router just to do so (or carry around extra tech just in case I want to) seems pointless when the router has a switch that could easily do this for me and save so much hassle. That would easily be the most useful time saving feature you could add, a great many people would use this feature if it was available.

For example if I setup a working VPN config on the router named ‘VPN_Provider_1’ and a second named ‘VPN_Provider_2’ the action of the side switch should then be selectable to swap between VPN providers. If I have more than two VPN providers setup on the router it would be helpful if the GUI for side switch action then let you choose which the button would swap between, eg ‘VPN_Provider_2’ and ‘VPN_Provider_3’

I’d find it useful myself but I also have non technical friends and family that would find this feature very useful as well (rather than me getting a phone call each time if things aren’t working well to just be walked through simply changing the VPN provider).

An extremely high percentage of gl.inet router owners will be using them with a VPN and an extremely high percentage of those will have more than one VPN provider they wish to switch between, making doing so with a simple switch action vs logging into router just makes so much sense I’m a little surprised such an option doesn’t already exist - sounds like an easily implementable popular feature improvement gl.inet could add

Thanks

[yuxin.zou]

The use case sounds informative, but I’m concerned that this feature could cause confusion in a number of places. For example, we need to prevent switching back and forth for a short period of time, consider whether the switch is still valid after a profile rename, and whether switching when VPN is disabled should be enabled on VPN …
We need to discuss this. In fact, users want to use the switch for other things, so maybe opening up the script in LuCI would be a good option?

BTW, have you tried our App? For non-technical users, it might be better to use the App for quick switching.

[ahhydri]

Suggested feature:

Different SSIDs corresponding to different VPN connection let say router has 3SSIDs as follows.

1. SSID1 → uses USA VPN as gateway.
2. SSID2 → uses Germany VPN as gateway.
3. SSID3 → uses Asian VPN as gateway.

And each SSID should have a different user subnet using VLANs so that it will be easier to do segregation.

[marcog]

@yuxin.zou

• Optimize VPN policies to support multiple VPN clients at the same time and use composite VPN policies.

IMHO this would be a a really great addition. I hope to see this implemented

[ad-d]

Hi, Thanks, I’m glad you can see just how useful this option would be, I’d much rather this was part of the gl.inet firmware though so extremely easy for novice users, making this overly complicated and requiring LuCI (which as far as I remember isn’t even installed by default) just means the users who would benefit the most from this would be too scared to even attempt it. Would then take even more effort each time after firmware upgrades as well.

You mention a few possible confusions so I’d suggest you keep it as simple as possible so 100% clear to the end user, the less you need to consider the easier it would be to implement and the more likely we are to get this very useful feature added.

I’d suggest:

1. The switch option purely adjusts which VPN entry gets set as the ‘active’ VPN connection to be used (and automatically connected) when device next restarted - switch adjustment does not actually start the VPN connection at the time the switch is moved or that’s extra possibilities that have to be considered and becomes needlessly complicated
2. Since switch position purely changes which VPN entry gets set as the VPN connection to be used when device is next restarted (and switch does nothing else) there is no need for anything complicated like preventing switching back and forth for a short period of time etc or what happens to currently active VPN connections etc
3. Any adjustments to either of the VPN entries that have been set as either switch position A or B should reset side switch back to one of the other switch options (I’d suggest the ‘No function (default)’ option) and require switch to be setup again as VPN A/B and chosing which of the entries should be used for switch position A or B - this means you can only ever select VPN profiles that actually exist. You could add a banner note that this would occur after such changes during the side switch VPN A/B setup step or add reminder pop up during save when a VPN entry gets adjusted if you deem it sensible to remind user at this point. This stops any confusion issues of what settings are used for the switch positions or why switch wouldn’t then work after VPN profile rename etc

Keep it all as simple as possible - you can choose two VPN profiles to use for the switch but any changes at all to anything related to those settings and you need to reconfigure the button, all very easy to understand and very minimal complexity.

That should cover all scenarios in the easiest way possible but if you think of any other issues I’d be happy to offer suggestions.

Thanks

[nico3]

Any plans to support 802.11r i.e. roaming between base stations without need for a mesh?
This is supported by OpenWRT 23.03. Any plans to upgrade the base system to that version?
Thanks for all the good work!

[Aman]

@ad-d

I’d suggest:

Hi, I have GL-AX1800 (Flint) with firmware v4.2 and use OpenVPN client with “Block Non-VPN Traffic (KillSwitch)” and “VPN Policy Base on the VLAN > Private (not Guest)”. Then private network uses VPN client to connection and guest network uses WAN (Non-VPN) connection. But when OpenVPN connection was dropped, the router blocks guest network traffics too.
I think it not correct behaver and I’d suggest to correct that.

[marcowireless]

using ul multi wan load balance applying the rules even to those who do not use the vpn the dual wan stops working simultaneously

[yuxin.zou]

These types of features are not even on the plan list for now. It depends on the direction of our product. As of now, it will only be added to the schedule when we start doing home network coverage/enterprise network coverage.

[yuxin.zou]

Multi WAN currently conflict with VPN policies, this is a known bug and we are working on fixing it.

[marcowireless]

4.2.1 release3 >>>> what was changed?

[LupusE]

If you select a stable release at the Downloadcenter, you’ll get a ‘Release Note’ field: GL.iNet download center

You don’t get this for beta. This makes sense, because there are changes still in progress. And you don’t should use the Beta, if there is no specific reason.
Even if it would be nice to have a release note in every single step, it is a little much to demand for beta.

And: this is definitely the wrong topic for the ‘question’.

[marcowireless]

V4.2.1

Bug Fixes

• Fixed a problem where the WiFi configuration page showed unavailable channel options.
• Fixed a problem where NordVPN could not resolve DNS after keeping settings upgrade.
• Fixed a problem where GL-MT3000 failed to recognize USB3.0 modem.
• Fixed a problem where the IPV6 rate limiting does not take effect.
• Fixed a problem where GL-MT3000 failed to repeat to iPhone 13 and TP-LINK ACR700.
• Fixed a memory leak problem in GL-MT3000 when using QCM protocol.
• Fixed a probabilistic issue where GL-MT3000 could not apply OpenVPN username and password.
• Fixed switch button not taking effect when parental control is enabled on GL-A1300.

Optimizations

• Disabled nginx access logs.
• Optimized the MWAN3 online detection threshold.
• Optimized the synchronization of configuration files in abnormal situations.
• Optimized the repeater scan time of GL-MT3000.

Software Upgrade

• Upgraded AdguardHome to V0.107.26.

[Henry_Bruns]

Future request:

Dont offer for Tor only selecting the Country for Exit point with unknown configuration for “StrictNodes 0 or 1”. Offer by GUI the follow:

Exclusion of Entry, Middle and Exit points with unknown country location by:
ExcludeNodes {??} StrictNodes 1 # exclude nodes from unknown countrys for all node types
EntryNodes {at},{ch},{us} StrictNodes 1 # StrictNode1 will only use one of the sample countrys and no any othe one, if the sample country are not available
ExitNodes {at},{ch},{us} StrictNodes 1 # StrictNode1 will only use one of the sample countrys and no any othe one, if the sample country are not available

To configure Middle nodes is a little bit more complicated. Need to list all country which the user dont like by follow:
ExcludeNodes {de},{fr},{uk} StrictNodes 1

The two-character country code on samples above, according to ISO3166 can be used in either upper or lower case letters. You can find the list p.e. on wikipedia.

[bigbadwolf]

might not be a sw feature, but still is a feature… any plans to introduce a router capable of gbit wireguard speeds?

[Henry_Bruns]

If not already exist on actual FW versions, add:

• https support for the web interface
• answer http requests by https
• if http still offered, please offer the ability to disable http

Offer the possibility to disable the access to the web interface on wifi and if exist on WAN side.

Pls fix the known open bugs. Pls. check the buglists…

• you can find some bug lists on forum by the search term “shorttest”. Also start fixing the known bugs from deleted bug tracer…

THX

[alannts425]

Custom DNS over TLS, HTTPS and QUIC

[Henry_Bruns]

Kill Switch for Tor:

• Possible it still exist, but I didn’t find the menu item for this.

[yuxin.zou]

The current 4.x version of the firmware already supports https access. The ability to redirect http requests to https is already listed in the plans and will arrive in version 4.5.

Thank you very much for the bug list. However, version 3.x firmware is not expected to be updated after the 3.216 release. So we will be looking at and testing these issues on version 4.x.