Yes, the firewall/ACL can also be used to block internet access for specific devices.
Thank you for your suggestion.
Could you please provide more details about the use case for this feature? Are you simply looking to see how long the PPPoE connection / WAN has been active, or is there another scenario you would like to address?
Regarding IPoE, we currently do not officially support it.
Force HTTPS only forces access to the Admin Panel to use HTTPS. However, the default built-in HTTPS certificate is still a self-signed certificate — its CA is not trusted by browsers or operating systems by default, which is why you see the security warning.
You can follow the guide below to import the CA certificate into your browser/system to resolve this issue:
By default, SSH is only accessible from the local network, so there is no need to disable it if the devices within your LAN are trusted.
Of course, if you want to maximize security, disabling SSH is also an option.
Regarding Remote Access Control, unless the MT3000 has a public IP address and you specifically need to access the Admin Panel / SSH directly from the internet (which is not recommended, as using a VPN is generally a safer option), or you need to access the MT3000 from the upstream network it is connected to (for example, when the MT3000 is being used as a repeater for a home network router), we recommend keeping these options disabled at all times.
Wow, this is needlessly complicated. It's almost like the easier method is to flash back to v4.8, set everything up, and then upgrade to v4.9 so that it'll retain previous settings along with the no VPN tunnel.
@will.qiu, is there a reason why you didn't reply to my post? Wouldn't it be more consumer-friendly to have the no VPN tunnel available without resorting to using SSH?
I've been thinking about this all day. I know this won't be an option with the Flint 4 since it won't launch with firmware v4.8. For older devices, I currently have the Beryl AX, Slate 7, Mudi 7, and the Brume 3. Would it be safe security-wise to flash back to the latest v4.8 series firmware, configure the VPN section, then upgrade to v4.9 to have the no-VPN tunnel rather than using SSH to create it? Then I'll fine-tune the settings in the other sections of the GUI. As a total newbie who isn't comfortable with SSH, is this the "easiest" way to add back the no VPN tunnel?
yes, how long is the pppoe connected and the devices connected to the router.
Another issue is that accessing the panel via Wi-Fi is probably not a good idea.
I skipped this question because slubman had already answered the questions related to Not Use VPN.
Regarding why this option is no longer available in the UI, please refer to:
We are also discussing with the product team whether this option can be added back in the future:
In our previous guide, we also provided another method: "Use a Non-Functional WireGuard Profile as a WAN Fallback", which allows users who are not familiar with SSH to achieve a similar result:
Of course, downgrading to v4.8 and then upgrading to v4.9 while keeping the configuration is also an option.
Thank you for the clarification. We will further discuss this with the product team.
Do you mean that you would like to prevent Wi-Fi-connected clients from accessing the Admin Panel?
If so, you can connect these clients to the Guest/IoT network instead of the Main LAN.
For Wi-Fi clients connected to the Main LAN / SSID, we believe access to the Admin Panel is necessary in many cases. This allows users to manage and configure the router without a wired connection, for example through a phone, laptop, or other devices that cannot be connected via Ethernet.
Is there any bug or security concern downgrading to v4.8 and then upgrading to v4.9 while keeping the configuration? It seems odd that I'll have to do it this way. Do you think there is a good chance this will be added back in the next few months? I'm not sure what the technical issue is if I can upgrade from v4.8 to v4.9 to get the no VPN option. @Nick-US said he has raised the issue previously.
Does GL.iNet prevent firmware downgrade over time? It sucks that I'll have to do things like this, but this is the easiest way I can think of.
What I mean by this is that the whitelist is not used and an unauthorized person from outside will break the Wi-Fi network security and monitor the panel page to find out the password 
Another thing is that if I have https disabled, I can still access the panel via https. Is this normal?
How I work around this issue is, I keep the wifi and network as is, even the web ui is visible for legacy support if things don't work well.
But normally my rule is not to login via here, instead I create a wireguard server called 'wifivpn' and from my quick settings in Android I can enable it, this way I got a very sleak admin system safe from wifi vulnerabilities and sniffing.
I also ACL all my server administrative things to this tunnel but not over the normal network.
as for now it is not super easy to implement on gl firmware but I got it working, perhaps this can be introduced as a feature or just for multi wireguard servers.
How do I use ACL?
Based on the firmware 4.9 and above.
If you navigate to the security tab, there you have a menu tab named ACL.
This is the same as in luci under network -> firewall -> traffic rules this has even more options.
you create a typical acl like:
name: to fill in yourself
src: the source zone, here you specify wifivpn or a other zone.
dest: destination zone to where the device need to be managed, in luci you also have 'this device' that is the router.
dest ip: ip of device
action: accept
All traffic goes from source to destination, so if source to destination is allowed the other side is allowed to respond on the same line, this mean it is rare to specify destination traffic as source.
With the upcomming vlan features this is even more useful with firewall zones from the gl ui and network segmentation.
Where can I get more information and examples of how to use ACL?
I think on the forum, if you need a specific use case to allow access between zones then this can be used.
But with the given example 80% is based on source to destination, so if i want to allow wifivpn to talk to device 192.168.8.5 it becomes like:
name: to be filled by you
src:wifivpn
dest: lan
destination ip: 192.168.8.5
action: accept
now wifivpn can communicate to that ip in lan but not others in lan, if you remove that destination ip it would be for the full lan (basically that is the same as pointing one zone to a other in luci).
If I also append a src ip, then basically only a specific source ip in wifivpn this rule applies to.
What it cannot:
isolate clients in the same zone, and same network, you can however still make a reject rule to a specific client in lan.
they explained something here ACL - GL.iNet Router Docs 4
In the ACL, I couldn't add a device that had never connected to the router before. I entered the MAC address and couldn't save it. However, in Luci, it accepted the configuration with just the MAC address without any problems.
With regards to DPI, I know @will.qiu said there are some issues with extending the retention period beyond a week. I would really like to see a monthly and annual retention period. Even two years would be awesome. Why not permit the storage of the logs on a USB stick to mitigate internal storage capacity concerns and its lifespan? Can this issue be brought up with the GL.iNet team?
The more I use DPI, the more I'm wondering what the difference is between using DPI and a DNS service like Control D.
Is anyone using the malware protection under the filters? Is it necessary to use that if I'm already using Control D for malware protection?
How are you configuring and using ACL at the moment? Looking for ideas before I try playing around with it in a spare GL.iNet device to avoid disrupting my main network.
Well it is still optional, it won't hurt to have both but this will reduce the visibility if you need to debug it when a wrong site or ip gets blocked, it is not known for me what the dpi malware filter currently adds in value as it is still in WIP, from my own experience I never noticed a block on their malware filter, but you will not see what ip or domain was the trigger so it is also not clear to me how effective it is, too much security and less visibility can become a administrative nightmare.
We do not recommend keeping the existing configuration when downgrading the firmware, and we cannot guarantee that doing so will not cause any issues.
We would instead recommend configuring the necessary settings on v4.8, and then upgrading to v4.9 or later while keeping the configuration.
Regarding restoring the “Not Use VPN” option in the GUI, we are still exploring whether this is feasible. There is currently no ETA available.
Sorry, but we may not have fully understood what you mean here.
Could you please clarify what you mean by “prevent firmware downgrade over time”?
I was asking if there were any bugs or security concerns with configuring the necessary settings on v4.8, and then upgrading to v4.9 or later while keeping the configuration.
Apple generally prevents users from downgrading to older OS updates. Will GL.iNet do that, or will all firmware versions be available for download and allow the downgrade and upgrade as needed? Given the current situation with the no-VPN option, I hope that v4.8 will continue to be made available for download for the foreseeable future even when v4.9 and v4.10 become final.