Tighten security of access to router GUI

I am a newbie to OpenWRT. Have been looking around for steps needed to restrict GUI access to my GL-MT3000 AX6 Travel Router.

Although it runs on OpenWRT 21.02 with a sleek interface on the top. Access to LuCI is still available where advanced features of LuCI are hidden.

Just wondering how i can restrict access to the router's GUI to:
i) a specific IP address, say, AND
ii) only via a specific port, say, 22212 so that

ONLY the device with IP of can access the router's GUI, using a browser with:

Many thanks in advance.

You probably know that 21.05 is already end-of-support, end-of-life, so if you want security, you should move to 22.03 or 23.05.

You can secure the port I web server config, https://openwrt.org/docs/guide-user/services/webserver/uhttpd
But the connection's source IP address limiting might need firewall rules.


Are you using this as a travel router? Typically, it would only be your own devices (and/or those of your friends and family that you are with) that are connected to a travel router, so usually you won't be granting access to untrusted users/devices. In that scenario, a good password is usually sufficient to keep your device safe. If you're using this as a home or business router I could see more users/devices that could be potential threats, of course.

Another approach is to create an additional network for untrusted devices to connect, and set the firewall to disallow local connections. Or, for that matter, use that network for trusted devices, too, and configure your use lan as the "management" network, making this management network the only one that has access to administer the router.

1 Like

Thanks for your reply. Will take a closer look.

I have to say coming from DDWRT background i have to make quite a bit of adjustments to syntax (not being a coder) as well as the way additional features needed to be added, instead of already part of OS. But i'll get over it in due course.

At this stage, I walk slowly first before running. So to speak.

It's intended as a travel router. And you're right about the smaller number of connected devices while travelling. But, given that it's capable of having up to 70 devices connected, i can see that it can easily fit in nicely for homes with two people. So my wanting to make it work as a normal home router is along this line. Though not necessarily for me.

As its maker has OpenWRT as native OS, so is my steep learning about it. I have a reasonable level of familiarity with DDWRT which i hope can help speed up my learning of OpenWRT.

Keep in mind that the gl-inet version of OpenWrt is a fork meaning that it is not the same as official OpenWrt. You should consider installing official OpenWrt (from openwrt.org), or asking for help on their forums -- there are material differences in the way that their customized firmware works.

Thanks for that important insight. It's important at this stage to me to know that relationship b/w GL.iNet and OpenWRT. I am sort of aware of the trade-offs between nice GI and beefier functionalities of CLI from MS DOS days! I am old folk. :slight_smile:

Thanks again.

Sometimes this is unfair. Yes may be 21.05 is EOS/EOL, but there can be a reason for someone to still use 21.05 regardless of they like it or not.

No, there can't, as security bugs aren't getting fixed anymore - and an unsupported/ EOLed version has no business of being powered up and on the internet. On top of that you aren't even using OpenWrt 21.05.x, but some vendor fork disregarding OpenWrt's trademark, so don't start about fairness, just don't; it's certainly not fair to expect support for an OEM firmware from the OpenWrt project either.

1 Like

I also agree with @slh regarding security. But even more so in this specific case where the OP is actively working to further harden their system. Using an EOL version of OpenWrt would be counter to the stated goals. Imaigne trying to increase a car's fuel efficiency by spending tons of effort on making the bodywork more aerodynamic around a big early 1970's muscle car engine... you would obviously be best served by starting by upgrading to a fuel efficient engine.

You can move the Wifi interface into its own zone and block the WiFi zone to LAN zone.

Without getting too deep into philosophy but software is like a spoken language, say, English. The more people speak English, the more 'lively & useful' it becomes.

But it's also true that English is spoken with different accents and slightly different grammar all over the world. Partly because it is MUCH easier to learn than, say, French (apart from the might of USA since end of WWII). Though French is much more elegant and precise as a language. I learned French in high school.

It's true that OpenWRT is the original and GL-iNet is a variation (fork) of it. But the latter was specifically designed to make Internet-related activities provided at places like airports, hotels, airBNB and so on, SAFER and WITH EASE by travelers such as family members on vacation.

I wrote this post after several hours playing around with GL-MT3000 (aka Beryl AX). And i think i can tell my (living-away-from-home-producing-movie) daughter to use one with minimum knowledge transfer needed. And that is because the GUI of GL-iNet makes it so easy to master. Certainly not OpenWRT even though GL-iNet is based on it.

The argument of staying loyal with OpenWRT as original or whatever would likely result in the loss of many travelers. It reminds me of Latin, in its written form, as the original from which may European languages got their root from if i am not wrong. But i think only Catholic clergy use it nowadays.

I raised the question in this forum because GL-iNet defers to OpenWRT for advanced features. It says so. And i am not sure if upgrading OpenWRT alone and by itself would result in an out-of-sync scenario with the GUI, at this stage of my leaning curve.

I know that i can not automatically expect anything from strangers on OpenWRT forum, except kind assistance from fellow travelers, in life as in this ...forum.

The post is getting too long, sorry...

this isn't a question of loyalty. Use whatever firmware works best for you. Honestly... I use and love OpenWrt, but my home network is actually a full Unifi stack. OpenWrt is my VPN server/endpoint, and also my travel router. But for those that are better served by the vendor firmware or other open source projects, there are many options and there's no ask to be loyal here...

The actual issue is about the supportability of firmware forks that are "based on OpenWrt" -- they share a lineage, sure, but they are different... much like how humans and the great apes also share a lineage. Many elements of our bodies are similar enough that a doctor (for human patients) would be able to use reasonable logic and intuition to understand some ailments that a chimp may experience, but there are many other things that require very specialized knowledge about how they are different than humans -- that's when you turn to a vet who specializes in chimps and other similar animals. Similarly, if you're using gl-inet's firmware, they (and their users) are the ones who know the details of how it works, which may be very very different than OpenWrt.

One could question the reasoning for this, but fundamentally, they've modified things sufficiently that their firmware is a different animal. Punting to OpenWrt for the 'advanced features' is not really appropriate, IMO, insofar as they are a commercial/for-profit company asking an open source project with a volunteer community to support for layering complex advanced features on top of their black box firmware. They're certainly not paying our volunteers to support their product, and they don't contribute back to the OpenWrt project, so they're kinda just pasing the buck here, if they really do 'defer' to OpenWrt.

They made modifications that give you a monolithic firmware with some things that are indeed easier for a beginner to use. However, this type of tradeoff is often at the expense of flexibility. The simple bass and treble controls on a basic stereo or speaker system are easy to understand and easy to use, but they will not allow you the tunability of a full multi-band parametric equalizer.

The basics of OpenWrt are actually not that hard to learn -- they're only marginally more complex than most decent vendor firmware options. The complexity comes with how you might then implement advanced features (which are notably missing from many consumer grade vendor firmware offerings, even if they're actually operating under the hood). For things like the travel context, there is the travelmate package which is fantastic and makes things much easier, including auto-start for VPNs an other cool integrations.

We do honestly hope that this forum is welcoming and friendly and helpful. It is a fine line, though, for how much support can practically be offered forks that materially change some underlying methods and behaviors in unknown ways, especially when that support shoudl be provided by the for-profit company that originated these changes.

If you move to the official OpenWrt firmware (hosted here at openwrt.org), you'll be able to get much better help because the firmware is a known quanitty.

From a rather simple question as a newcomer, followed up with what i thought as a cheerful way of getting an answer, but still without getting a direct one in the end. Instead, it's getting further away from what i am seeking in the first place.

So, i regretfully say good bye to the forum.

I apologize nobody actually answered your inquiry:

  1. change LAN firewall to Drop
  2. manually make rules to Allow things like DNS requests, DHCP queries, etc.
  • Change the bind port in /etc/config/uhttpd to 22212
  • You'll need a separate ports for HTTP and HTTPS
  • Make a firewall rule that only allows input to 22212/tcp and the other port you choose

first of 21.05.x was a typo. should have been 21.02.05 .. anyhow, I very well understand the security concerns you are trying so hard to highlight. my comment is not about GL-iNet mods.

I personally have a valid reason to stick to 21.02.07 because I am using MWAN3 to route traffic to different WANS based on Iipsets. this doesn't work on 22.03.00 and on because they use FW4 instead.

I am not familiar with NFtables so I have to use 21.02.07 though I don't like to be using older firmware/OS. unless someone could point me in the right direction to get the same functionality using nftables,

people have reasons whether you like it or not. whether it is justifiable or not. one's negligence or reluctance to update is something than you are left with no other options or lack knowledge.

my IT expertise is into a different field and I am not a programmer to tinker.

In case you haven't already seen it, https://github.com/openwrt/packages/issues/16818 might be of interest; it looks as if the issue is known and solutions are being contemplated. Doesn't look like there is a solution yet, though.

https://openwrt.org/docs/guide-user/network/wan/multiwan/mwan3 suggests that some sort of iptables/nftables compatibility layer might be a possible interim workaround.

1 Like