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