Do you think that this feature will be available at some point? You mentioned in another post that this was already in the scheduled of devs. This would be such an improvement…
It has been implemented in the firmware 4.x.
If you use vpn policy manual route setup, you can use one Openvpn and one Wireguard at the same time.
mmm maybe I crossed-post the wrong feature.What I meant is the ability to have multiple Wireguard connections active at the same time, with the possibility to route different clients to different wireguard instances. So policy based routing based on the client, not on the target
In vanilla openwrt I believe it is possible to setup multiple wireguard tunnels as seperate interfaces and assign different vlans/wifi to them. It is just not quick and easy to switch to a different server.
Yes that is true. When everything needs to be set up manually, multiple interfaces is not a problems.
The most difficult set up is routing, what is the main reason that we made the modifications. Let’s make one interface each protocol works first.
I am having problems with selecting customize routing rules to set both WG and OpenVPN at the same time. I hope you can implement multiple wireguard tunnels once you have ironed out the bugs.
Let’s make one interface each protocol works first.
Sorry I didn’t get your last sentence, does this mean you are considering to implement the feature? I mean policy based routing based on the client…
Hello. My request is about upgrade function to Samba\FTP\Sftp service because its have lot of problem when you use it not just like noob with anonymous access one button etc. And you are not professional openwrt user.
- First, add SFTP server out of box to have access to router file, because its not obvious that router don’t have such necessary function. And you need manually install SFTP package for it.
You can add it in luci System → Administration SSH menu to enable it and do some setup, or even in main GUI.
- Second, in main GUI add option in folder sharing to add users\folders access for ftp\sftp like it made for smb\webdav
i even made illustration for this
- Third, add more option to smb setup for main GUI like it have luci-app-smb because its not obvious to use it by first time user and have problem with old smb-v1-v2, and by default you have lot of issues with it, better to have it out of box with some like extra options switch.
The current plan is for network storage to be refactored in 4.5 or 4.6 to address some of the issues.
It is planned that FTP will be added to this list. We will discuss about SFTP.
Although it is nice to see you have plans for firmware 4.5 and 4.6, some of us have been waiting for more then 2 years for 4.x for our routers, since @alzhao initial post that said 4.x would be available mid-2021. It would sure be nice to get 4.x across the full product line before everything earlier than the Flint goes EOL.
I don’t see it on the main list, so I’d like to add as feature requests. I have a GL-AX1800
- Multi-WAN via 2+ ethernet connections.
- Multi-WAN routing for specific IPs. Examples:
a. These 2 IPs only route through ethernet WAN #2 first, then ethernet WAN #1, all other IPs use WAN #1 first then WAN #2, for both IPv6 and IPv4
b. These 2 IPs for these ports on IPv6 and IPv4 only go through ethernet WAN #2
I know it’s all possible to set up through LuCi but it gets pretty complicated and takes a while.
It would be nice if the Puli could have services that use T-Mobile along with T-Mobile themselves added into the list of Operators that is shown in the drop down box when doing a Manual Setup and also use them when doing an Automatic Setup.
A couple more features:
- Ability to change the web interface port. The GL.iNet admin panel uses a different web server than luci, so it’s not even obvious how your do this via the command line. When you do this config change, it just changes the luci webserver: [OpenWrt Wiki] LuCI essentials
This would be super useful when you want to use wireguard and your coworking space blocks everything but the web ports of 80 and 443.
Lets Encrypt ddns support, or ‘gl-inet ddns lets encrypt support’: This would be useful so we can always have https:// on when we interact with the web interface externally and internally without having to use self signed certs
https by default vs http by default : typing in my password locally over http as a default can have it captured, even a self signed cert would be a minor improvement. Maybe a ui alert can show as an option on the login screen saying your on “http, click here for https”
Letsencrypt requires a domain name and requires an acme client to proof it controls the domains it requests the certificate for. Frequently this is done using a .well-known/acme-challenge file, which will need to be accessible from the internet on port 80. Technically the GL-inet DDNS could be used as domain, but would you really want a router to expose itself to the internet on port 80 for a letsencrypt certificate?
would you really want a router to expose itself to the internet on port 80 for a letsencrypt certificate?
Well there is already a choice to turn on external http / https access via the “Enable HTTP(S) Remote Access” options on the router, so maybe yes? It would especially useful for people who turn on that option, that way they can more easily ensure they are not being spoofed and they have the webserver on anyway. Or GL-inet can become a certificate authority just for it’s DDNS subdomains and do it automatically for all of their routers, you wouldn’t even need to involve lets encrypt for that.
But that is default off for security reasons (and also to allow someone to port-forward port 80 to whatever they would want.) The easiest way to keep things as save as possible is to limit the attack surface. That’s one of the reasons nearly NO router does that by default. Having a letsencrypt certificate is not worth the security implications by exposing a web-server and possibly additional control systems!
That certificate authority would not be trusted by devices/browsers and encryption-wise it offers absolutely no additional strength. Nor would I trust GL-inet to be a CA.
The only difference between a CA-signed and self-signed certificate is that the first only has a trusted source telling that that certificate actually belongs to who it says it is. If you want to prevent some weird man-in-the-middle attack, just remember the certificate’s its hashes and you would be able to determining if the cert is actually your router’s.
Nothing prevents you from doing letsencrypt with OpenWRT if you really want to do so. Acmebot should be available!