[HOW TO/FEATURE REQUEST] Easily selectable LAN ports for VPN + multiple OpenVPN connections

I have a few different VPN accounts but the two I use the most often do not have reliable Wireguard option and occasionally something will work through one VPN but not the other, given my Flint has 4 LAN ports and I rarely need any more than 1 LAN (occasionally 2) for VPN. It would be extremely helpful if I could run two OpenVPN client connections at the same time with easy gl.inet GUI ability to select which LAN ports are used for which VPN connection. For Example LAN ports 1 and 2 for OpenVPN connection 1 and LAN ports 3 and 4 for OpenVPN connection 2. Currently if I want to swap between VPNs I have to login to the device, stop current VPN, select new VPN and connect - all 4 LAN ports are then used for the VPN.

I have a few fairly powerful gl.inet devices (eg Flint, Brume 1, Brume 2), even the slowest Brume 1 device can handle 'up to 97mbps' OpenVPN so has plenty of processing power in reserve even if such a feature would slow it down a little, my internet max is limited to around 50mbps and 30mbps over VPN would be sufficient anyway - is rare I'd be trying to use both VPN connections at the same time so with one simply idling the other connection should easily manage that throughput given hardware specs.

I did a basic mock up of how I'd love it to look - the same very easy to understand gl.inet GUI we're used to but with additional basic on/off switches relating to each LAN port against each OpenVPN connection (of course can only enable each LAN port for one VPN connection or the other). Would be even better if disabling a LAN port on both VPNs meant it got local non VPN internet.

I know gl.inet GUI can use OpenVPN and Wireguard at the same time but my VPN providers don't have reliable Wireguard option and I don't want to spend yet more money on new VPN providers especially given I've been using existing ones for years and good track record of them doing what I want vs unknown of trying someone new. Regardless if I did try running OpenVPN and Wireguard at the same time there's no easy GUI options for controlling what LAN ports would be using what VPN anyway.

-> In the meantime it would be useful to know just how much effort this would involve to try and configure equivalent via Luci (ie LAN1+2:OpenVPN connection 1, LAN3+4:OpenVPN connection 2) if anyone knows how and could give some pointers?, it's many years since I really played around with much networking stuff so step by step would be better! I'm sure a great many people would love to split the LAN ports up in this way.

I did see 'Policy-Based Routing' mentioned on some threads (which apparently doesn't work properly with gl.inet firmware) but that looks to be for those wanting to selectively route traffic to VPN for some specific hosts/subnets/domains which is completely overkill for what I was looking for and there must be an easier way? I just want all traffic for anything connected to LAN1+2 to use OpenVPN connection 1, all traffic for anything connected to LAN3+4 to use OpenVPN connection 2 with no interaction between the two connections (basically splitting a 4 port Flint and making it behave like two separate 2 port VPN devices).

@alzhao

1 Like

It works totally fine - why do you think it does not?

Here's a shortened version of the original question:

I have multiple VPN accounts that don't support reliable Wireguard. I'd like to use two OpenVPN connections simultaneously on a gl.inet device like the Flint.

Ideally, I'd like to assign specific LAN ports to each VPN connection: LAN1 and 2 for VPN1, LAN3 and 4 for VPN2. This would allow me to switch between VPNs without disconnecting and reconnecting.

I'm looking for a simple GUI-based solution, but if not, detailed instructions on how to configure this using Luci would be helpful.

I understand Policy-Based Routing might be an option, but it seems overly complex for my needs. I simply want to split the LAN ports and assign them to different VPN connections.

1 Like

Thanks for the nice mock up.

Understood what you want to do. It includes setting up vlans and routing. So not difficult if manually setup. But using the UI should include a lot of more work.

For example,

  1. Need to have a page to set up vlans. The LAN ports are bridged by default. Need to separate them first. Then you will need to setup netmask etc.
  2. As this is a wifi router, LAN ports are not the only consideration. Eventually you need to consider how to router the wifi devices. Now the router has Mac address based policy which can achieve what you are doing easily.
  3. There are more consideration than what you think. For example, if OpenVPN2 is broken, how do you want to router LAN3 and LAN4? Need to set up killswitch etc. Users also demand rotating the vpn profiles in such cases.
  4. Taking consideration of all the above, eventually the function will be too complicated to use.
1 Like

Hi alzhao, thanks for the reply, yes I probably should have included wifi within my original mock up but that doesn't really add any additional complexity, I redid the mock up image to cover those below (although if wifi/guest wifi are disabled would be nice if they aren't shown on that screen so original mockup would be valid scenario when all wifi disabled). Obviously for any exotic config (eg if user created any extra wifi connections) people should use Luci but having this ability for the gl.inet provided 'out the box' options (LAN1-4, wifi, guest wifi for Flint) in the gl.inet simple GUI would be of great benefit - turning something many people find complex but would love to use into a few simple button clicks is where the gl.inet GUI excels and the only reason I and many others own any gl.inet products. To answer your above points:

  1. A separate simple gl.inet GUI page to setup VLANs would be one way of doing it but really seems overly complex for this ask. Would be far easier for the user and remove this consideration if:
    When a new VPN connection is setup a VLAN for it gets created in the background, the simple enable/disable switches then determine the membership for that VLAN (eg enable LAN 1, LAN 2 and guest wifi and that's what goes via that VPN connection)

  2. Yes I added wifi in below updated mock up image, mac address routing of individual wifi devices (or even LAN connected devices) is far too complex for the basic functionality we're trying to achieve here and that would be better covered by Luci, we just want the basics of assigning entirety of each LAN port, wifi or guest wifi connection to a specific VPN connection (I imagine most of these basic use cases would use guest wifi for VPN and other wifi for anything they don't want via VPN anyway). I want to keep this as simple as possible so it can be easily covered by simple GUI on/off switches and therefore be easily achievable within the gl.inet GUI. The average non technical user does NOT want to be trying to track down mac addresses and entering in Luci, that's making a simple request hundreds of times harder than it needs to be.

  3. I'd expect that to work the same as it already does - ie if OpenVPN2 has not connected for any reason (eg dead server, expired VPN credentials etc) then with the global 'block non-vpn traffic' option enabled the LAN ports 3 and 4 in this example would have no internet.

  4. As clarified above I don't think any of the points you raised make this too complicated to easily show/configure in the gl.inet GUI, just adding wifi and guest wifi on/off switches to my original mock up has covered all of these points raised whilst still being very easy for even amateur users to understand what's happening. Yes there's a fair few on/off switches shown in the GUI for mock up but it's impossible to misunderstand their function so isn't making the screen too complicated and keeps everying on one page without the added complexity of having to create a new VLANs screen etc which definitely will confuse some people. They'd be less on/off switches needed for majority of gl.inet products as well since most have less LAN ports.

Basically what I mocked up in above image is very easy for the user to understand, is very easy to display in the gl.inet GUI without needing any additional pages, doesn't sound all that difficult to implement and should also cover 99% of what most 'non power users' would be after - for any considerations outside of that basic scope that you think would make the feature too complicated to add into the basic gl.inet GUI then exclude those scenarios from this feature request and direct those use cases to the Luci option that already exists (those wanting that level of complexity would probably be well acquainted with Luci anyway).

Thanks

@alzhao

2 Likes

This looks great indeed. Product managers are working on this.

3 Likes

That would be fantastic, really looking forward to using this :smile:

I'm sure it's too early to know when this might make it into a firmware release but if you have some idea of timeline that would be really helpful to know, can't wait!

@alzhao

1 Like

What would be excellent is if in addition to LAN port VPN on/off, this could be extended to easily assigning different WIFI SSIDs for either VPN on or off.

My use case is that I want most devices going through the VPN all the time (LAN & WIFI).

However, my work PC (using WIFI), I need to quickly and easily switch between VPN / NO VPN occasionally as some website do not work with VPN active.

I know there is MAC filtering, but to log into the router admin panel and add/remove the MAC of my PC just to access one website without VPN from my PC is not very elegant.

I think the quickest way to do this would be to switch between SSID-VPN and SSID-NOVPN.

I have a Beryl GL-MT1300 and have achieved this by flashing Vanilla OpenWRT and setting up a new device / interface (br-vpn / VPN) with a different subnet to br-lan / LAN and then using policy-based-routing to route the VPN-subnet through a newly created WG interface.

This now works great, but as a noob to OpenWRT and networking in general, it took me a very long time to figure out.

Now I have SSID1-VPN, SSID2-VPN, SSID3-NOVPN and LAN1-VPN and LAN2-NOVPN.

Also my devices can still communicate over the internal network, whether they are attached to LAN or VPN subnet. This is what took me the longest to solve.

I expect my use case is not that unusual and would be helpful for many.

Thank you for considering!

If you want different SSID-VPN and SSID-NOVPN, you can use guest wifi for now.

Using SSID to differenciate VPN also has shortcomings. It is easy to mess up different connections and cause leaks.

Hi, Any update for when we are likely to see this major VPN usability and functionality improvement?

Would be great to be able to use multiple OpenVPN connections to different ports simultaneously from the same Flint and have it so easy in the GUI that I could talk a completely non technical family member through setting it up over the phone in just a few minutes - that's exactly what my mock up solution would give and I know there's a great many who would love such easy control. In fact looking at the forum there's more than a few help request posts that would never have been made if things were already this easy.

No-one wants to be going anywhere near Luci (if they even have a clue where to start, majority don't) when this can be easily achieved in seconds with a handful of button clicks from a friendly UI.

Hoping this is coming soon (or even already in a beta firmware I missed? Perhaps unlikely but I can hope!). I'd love to start using these features rather than swapping between physical devices, far too much effort to try and achieve this in Luci and then (if I actually managed it correctly) the significant hassle needed for setting it all up again in Luci after a firmware update!

Thanks

@alzhao

4.8 implement what you want but seems still have room to improve now.

Which router do you have? Maybe you can get a firmware to try.

1 Like

OK great, really excited about this, I can't remember there ever being a gl.inet feature update as 'game changing' as what this should give us!

I have a couple of AX1800 Flint devices I'd like to use this feature with and can certainly test with one of them, if I could get a 4.8 firmware I'd love to give it a go :joy:

Is there a 4.8 beta firmware anywhere for AX1800 Flint I could try out (even just to give feedback on this VPN port assignment feature)? I'd be using this feature extensively so more than happy to do some testing of how it works and usability suggestions to make sure we get this right at release :slight_smile: Firmware page just has the 4.7 beta available.

Just to confirm: firmware 4.8 gives option to use multiple OpenVPN connections from multiple providers (including different connections from the same VPN provider) and easily assign to different physical ports using the easy gl.inet GUI? Eg:
OpenVPN Provider 1 (Chicago): LAN port 1
OpenVPN Provider 1 (New York): LAN port 2
OpenVPN Provider 2 (Los Angeles): LAN ports 3+4

thanks
@alzhao

Now only available for Beryl AX. Will available to other models later.

1 Like

OK that device only has 2 network ports so a poor choice for testing this feature, any chance we can prioritise AX1800 Flint as next in line for 4.8 firmware, with 5 ports available this can get a real workout using 4x openvpn connections each to a single port and is when the real world usability of the feature implementation will start to show, a Beryl AX just doesn't have the ports to take advantage of this feature or provide useful feedback.

That said I do have a Brume 2 and since that's basically a Beryl AX minus the wifi (minimal effort required) is Brume 2 going to get 4.8 shortly as well?

Makes sense to get a one of the routers with plenty of network ports onto 4.8 firmware early for testing and as AX1800 Flint is the oldest there's many more out there vs Flint 2 (and more people with one spare to test with if they upgraded to Flint 2 etc), the natural most sensible choice.

Is there anywhere to track progress of 4.8 firmware for AX1800 Flint so I can get an early build as soon as something exists for the device?

@alzhao

v4.8 firmware arrived for Flint 1 but looking at comments from Renato and Lun on 4.8 beta thread it seems this request was NOT implemented. From the screenshots it looks like a very messy convoluted VPN implementation was added that cannot perform this basic functionality.

As a recap we just want the ability to use multiple OpenVPN connections at the same time with each assigned to a LAN port so any device connected to the port goes via that VPN route. If a device is moved between ports it will of course then route through the VPN of that LAN port instead. There should be no communication between LAN ports of course (eg a device connected to LAN 1 cannot see a device connected to LAN 3). Each OpenVPN connection should ideally have its own VPN kill switch although I'd expect majority of users to enable kill switch for each anyway so a global VPN kill switch should also be acceptable.

With current stable v4.6 firmware and gl.inet GUI you'd need FOUR routers to achieve this which is more than a little crazy when a single Flint should be capable of this, v4.8 firmware was meant to give us this but seems it didn't.

Another example image if that helps, showing 4 random VPN providers:

@alzhao It looks like v4.8 was nothing like what was indicated unless Lun was wrong and there is a way within the new convoluted VPN setup screens to achieve this? If so a guide would be helpful, certainly not self explanatory. Regardless it all looks a mess to be honest and no way the average user would want to go through that, can we just have something like the basic easy to understand GUI I did a mock up for instead (via a 'basic' vs 'advanced' mode if needs be)?
The whole point of the gl.inet GUI was to try and make the more complex setup very easy to achieve even for non technical users, at first glance v4.8 VPN config looks more like a Luci redesign than an unintimidating feature non technical users would dare go anywhere near.

In the meantime can this topic be marked as 'unsolved' whilst it is still not possible to achieve? That way people can see this topic still needs work and not get their hopes up only to be disappointed.

Thanks

1 Like

Now there is no vlan management in the firmware so you cannot match each physical port to a vlan in the UI.

You can set up one vpn for each device to achieve what you want for now.

Each vpn comes with a killswitch in 4.8.

4.8 vpn design will be improved further.

For vlans plans you can ask Lun.

Hi, Thanks but that's not going to help, the whole point of this feature request is that if a VPN connection doesn't work for a device (for any reason) you can just move the LAN cable to another port to try with a different VPN connection - if the MAC of device for instance determines which VPN to use then it would always be linked to the failed VPN connection, pointless. Only way then to fix the issue is to have multiple gl.inet routers pre configured to have to swap between (like now but expensive and wasteful) or have to login to the router to change settings (way more hassle than should be needed plus if used by a non technical family member etc they wouldn't have a clue how to).

Since v4.8 was meant to bring these features and didn't do we have any idea when they will be added? Will still come as part of a v4.8.1 soon for instance or is this miss indefinitely delayed with no new expected timeline?

This request was to make things as easy as possible for the majority of your customers, with up to 4 VPNs setup (one per LAN port) you get four chances from just one router before the hassle of fetching a device to have to login and start messing about with settings, pure bliss for the non technical family members who can easily understand moving a physical LAN cable between 4 ports on a Flint - the chance of all 4 VPN connections failing at the destination end is highly remote.

Gl.inet seem to be making some odd choices on where to invest their time to develop ever more niche features at the expense of things almost every user (technical or not) would greatly benefit from. Remember that for every one user asking in the forum for new options to do the latest specialist use case they just dreamt up there at least 50 times that amount who aren't technical enough to join the forum and make their ask to just keep it simple, forever chasing complexity and cluttering the GUI will almost certainly lose more repeat business than it could ever gain. I guess it's good that new features are being added in the gl.inet firmware but the whole point of the gl.inet GUI was that it was very very easy to understand, from feedback of others (and what I've seen of v4.8) the consensus is it just looks intimidatingly overcomplex, for most of gl.inet's users that is entirely counterproductive.

Of the ten or so other gl.inet users I've shown v4.8 beta to the majority have said they'd never install 4.8 ever (or any later versions) unless the VPN section gets a serious redesign for usability. Not one of them could accurately guess where traffic would now route to (understandable since there's a fair few experienced gl.inet users in the v4.8 thread who are really struggling to understand what/why gl.inet built, average non techy user has no chance).

At this rate when VLANs eventually appear those who would benefit the most will miss out because they can't opt out of all the very very messy counterintuitive mish mash of VPN setup changes that comes with it.

v4.8 desperately needs a GUI usability redesign to hide many of the niche features behind 'advanced' menus to clean things up and make the basics easier to understand so average users aren't left behind. I very highly recommend gl.inet to take another look at my mock ups for simplicity (to further prove how easy this could be for end users I did another mock up and even managed to simplify it again!) - it is so easy to understand and uses GUI layout all users are already familiar with, all relevant settings are on one page and literally impossible to get confused what the end result would be. By all means provide your new exotic niche routing options but PLEASE just give us a 'basic mode' VPN page like the above where we can very easily choose OPENVPN_1 -> ALL TRAFFIC -> LAN_1, OPENVPN_2 -> ALL TRAFFIC -> LAN_2 etc, it simply doesn't need to be more complicated than that for 90%+ of your users (not 90%+ of active forum members obviously, I mean the REAL end users).

When a small v0.1 upgrade requires a networking course/retraining just for most existing users to understand how to do what they were previously able to do easily it has most certainly gone in the wrong direction. I know many friends and family that I recommended gl.inet devices to because of how easy they were to use, there's no way I'm being lumbered with having to support v4.8 in current form for them, would be like working a second job!! Sorry for the long post but it's important the wishes of gl.inet's existing non techy users aren't ignored, better to catch this whilst still in beta and improvements can be made.

Please let me know when this feature request is possible and I'd still really like to give it a try even if I wouldn't dare let anyone else I know near it. Thanks

@alzhao @Lun

1 Like

Why do you want to reconnect the device to a different Ethernet port to use another vpn?

If you need a VPN failover, i.e. one device can use the first VPN, when the firmware vpn fails, the device will use the 2nd vpn to connect, this has already been implemented inthe current firmwware v4.8. Don't need to reconnect cables.


@ad-d
My understanding is that on the basis of version 4.8, extending the LAN function of "Specified Connection Methods" can distinguish between LAN1 and LAN2, which can meet your needs.

The VPN Dashboard in version 4.8 will receive a major UI update, featuring a refreshed visual style and an improved layout that helps users better understand the VPN panel and tunnel priority. The new design makes the tunnel on/off status more intuitive and visually clear.

However, the feature for distinguishing between different LAN ports will not be included in this release.