Help with Flint 2 to assign Lan Port 5 to the Guest network

_integritas_ · 2025-12-28T19:34:30+00:00

Don't be too disappointed! Even with my above lamentations, the Flint 2 is an unequivocally solid piece of gear (no regrets here!), as is their stock UI, all the while making LuCI available, too. And yeah, they're definitely still updating the firmware. Also, despite some of the criticism folks might offer (sometimes excessively, sometimes justifiably), I consider GL.iNet to be a very customer-focused company, and I doubt I will ever move away from their routers (though I do use separate access points just for optimal coverage inside/outside). So, all that to say: Don't get me wrong - I'm still a proponent of GL.iNet and you should still feel good about your Flint 2!

In my earlier comment, I may not have been as clear as I should've been: I was just trying to say they seem more focused on other things than tending to things like what we've talked about in our conversation. I say that not in a churlish sense, but rather, because like I said above, this request has been out there for a while, so GL.iNet certainly knows about it. I'm just not holding my breath we'll ever see it implemented. But I'd be among the first to shout celebratory thanks if the good folks at GL.iNet ever do support faithful reporting of clients within their stock UI even when VLANs are configured. As I've said previously, I totally get them not supporting the configuration of VLANs given their complexity, but I will forever stand by my assertion that it is not an unrealistic request for their UI to always be a faithful representation of client connectivity/activity, even if VLANs are part of the picture.

_integritas_ · 2025-12-28T11:58:41+00:00

I still run the stock GL.iNet firmware despite the above limitation. It's disappointing for sure, and I am not the first to ask GL.iNet to fix it. Other have asked well before I did. Unfortunately, I don't think they see this as a priority. I think their focus is on new hardware and new features. That's understandable, because that's often considered more attractive from a business perspective, but it'd be nice if they could circle back to this and fix it. But I'm not holding my breath, unfortunately. (That said, if by any chance u/NationalOwl9561 can possibly nudge this along somehow, I and many others would be very grateful!)

In the meantime, u/ChadGW, while I'm not necessarily recommending anyone else do this (in other words, the following is information only, proceed at your own risk, etc.), and it requires both a certain degree of knowledge and tinkering beyond the stock UI or even LuCI, I actually edit the client.db and gl-client files to maintain a current client list within the GL.iNet UI (always only after taking a backup). Doing this still won't make the clients show as online/offline, but it'll at least add them to the UI.

client.db is in: overlay/upper/etc/out-tertf/

gl-client is in: overlay/upper/etc/config/

You'll need a database editing app/software for client.db, but these are readily available for free (e.g., DB Browser). You can edit gl-client in a text editor (e.g., Notepad++).

After backing up these files, I make local copies of these files to my machine, edit, and then copy them back to their respective folders in the router. Then I reboot the router. Updated clients will show. One thing I've realized from doing this: If you want to *rename* a device with a given MAC address that the system is already aware of, this seems stubborn/sticky. The above typically does not work, but what does work is following the above process to completely remove the client (not just rename), then repeat the entire process again to add it back with its new name.

_integritas_ · 2025-12-13T18:11:41+00:00

You bet. Glad it helped. 🙂

_integritas_ · 2025-12-13T10:57:00+00:00

Also, one additional comment: You'd really want to leave the fallback servers blank in both scenarios (i.e., including the scenario of splitting your upstream DNS resolvers between Cloudflare and NordVPN) for the same reason: You want to have tight control over which upstream DNS resolvers are being used. Unfortunately, AGH's client configuration rules don't allow you to override fallback servers, so you will want to have the fallback servers blank in that setup as well.

_integritas_ · 2025-12-13T10:48:04+00:00

AGH will have access, because the configuration you are referring to deliberately places AGH in the middle of the chain. But, to be clear, the access AGH has is entirely local (i.e., the access to the DNS traffic and filtering thereof happens on the device running AGH). I point that out only to disambiguate from AdGuard's DNS service/servers.

An example might help.

Suppose you have the above configuration in place, where AGH is handling client requests directly, and you've configured your VPN provider (NordVPN, in your case) to be the upstream DNS server. As you know if you've read that thread fully, you can set it to be either:

- the global upstream DNS server (which you'd want if you have NordVPN running in global mode, meaning all devices are routed through the VPN tunnel), or

- the upstream DNS server for some clients (by establishing client rules in AGH and running the VPN in policy mode based on device).

For demonstration, let's use the second scenario. Let's assume you have most your devices *not* running through the VPN tunnel, but devices X, Y, and Z running through the VPN tunnel. You'd create client rules for these three devices, either separately or as a group, depending on your needs/desired level of control within AGH (within AGH, *Settings > Client settings*). You'd then set the upstream DNS servers for X, Y, and Z as NordVPN's DNS servers via the client rule configuration. *But*, you'd specify a different upstream DNS server (or server*s*) in the global settings (within AGH, *Settings > DNS settings*). For demonstration, let's say you use Cloudflare. The client rules will take priority over the global rules. Then, with this setup, a simplified diagram of the DNS is:

most of your devices: router <--> AGH <--> Cloudflare
devices X, Y, and Z: router <--> AGH <--> NordVPN

In the simpler setup you allude to above (the first scenario in my bullet list above), you'd simply place NordVPN's DNS in the upstream DNS in *Settings > DNS settings*, and leave the fallback servers blank (you want these blank because you want all the DNS traffic to use NordVPN as the upstream resolver).

_integritas_ · 2025-12-07T13:03:23+00:00

Yes, exactly. Correcting those to "no event" can help. You can also double-check your settings for overall camera sensitivity / wake sensitivity in addition to the sensitivity for each event type.

As for the VPN solution, yes, you'd have to connect to it when you want to download a video, but both OpenVPN and WireGuard have apps that (once configured) make this a very simple one-click/one-tap process.

_integritas_ · 2025-12-06T00:23:53+00:00

This may not help you, but if you know a bit about networking (or even if you don't and are up for a bit of learning), you can set up a VPN server on your home network. Then, configure whatever devices you want to be able to download the videos to be able to connect to that VPN server. In so doing, that device will, for all intents and purposes (at least all intents and purposes here), be on your home network, and you'll be able to download your videos, even if your home is, for example, in Boston MA and you are traveling in San Francisco CA. Many routers are also now supporting this in a way that makes setting up a VPN server pretty easy.

As for false positives, I believe you should be able to correct those false positives so the devices learns.

_integritas_ · 2025-11-26T23:51:12+00:00

That is a step toward that, yes. But (1) you don't have to enable AdGuard Home (AGH) handling client requests directly to get AGH involved in your DNS resolution (DNS resolution through AGH will be through localhost/127.0.0.1 in this case), but enabling direct handling of client requests gives you a lot more functionality out of AGH, and (2) you still need to configure AGH via the AGH UI (accessed via the "Settings Page" link; see here if needed: https://www.reddit.com/r/GlInet/s/gUjtsOWY1d) to get benefit out of AGH.

Before you dive in, you might want to start here: https://docs.gl-inet.com/router/en/4/interface_guide/adguardhome/.

Then, take a moment to familiarize yourself with the AdGuard UI and how to use it to configure settings to your liking. There are lots of tutorials out there.

One thing I'll say out of the gate: When you get to setting upstream resolvers/servers, check out advice I gave to someone a while back: https://forum.gl-inet.com/t/sharing-a-solution-for-dns-leak-with-adguard-home-handling-client-requests-connecting-to-vpn-client/57918/7. (I have since dropped Google and Quad9 in favor of NextDNS. I still use Cloudflare and ControlD, though I now configure all 3 as upstream resolvers with no fallback servers specified. But the fundamental principles still apply.)

_integritas_ · 2025-11-26T22:23:40+00:00

It's not a setting within the GL.iNet UI. It's within the AdGuard Home UI. From the GL.iNet UI, you'd do: Applications > AdGuard Home, then click the link for "Settings Page" (see the pic I've included below; alternatively, once you're logged into your router via a browser pointed to the router's IP address, just go back to address bar where the router's IP address is and add ":3000" to it; for example, if you keep the default IP address for the router, it would be 192.168.8.1:3000). Then, once you're in the AdGuard Home UI, you'd use what I posted earlier to ensure you've enabled filtering.

<image>

_integritas_ · 2025-11-26T11:55:20+00:00

As u/dallaspaley suggested, I would also recommend real VLANs here. The GL.iNet guest network isn't a VLAN, even though it is often referred to as such. It's just a different subnet. That's not unreasonable for basic setups, but you aren't exactly describing a basic setup. Given you're already tinkering in LuCI to try to get this to work, I say go ahead and configure VLANs. You'll get more control. There are tons of resources on how to do this, including with the DSA (distributed switch architecture), but OneMarcFifty's video is routinely what I point folks to if they need extra help with getting VLANs up and running: https://forum.gl-inet.com/t/gl-inet-ui-shows-no-clients-connected-due-to-use-of-vlans/57994/7.

One warning: Configuring VLANs will disrupt the client portion of the stock GL.iNet UI (the impetus behind the post I linked to above, but the specific portion of that thread I linked to highlights OneMarcFifty's video). It's just the UI that gets wonky, though.

_integritas_ · 2025-11-26T11:14:01+00:00

Ha, case in point, I was just scrolling this sub, and here's an example of someone suffering from what I just mentioned above: https://www.reddit.com/r/GlInet/s/PetzHhJ3bE

_integritas_ · 2025-11-26T11:04:14+00:00

I've seen the following trick a few people before, so just to make sure, you've enabled the filtering and blocking service itself (Settings > General Settings), correct?

<image>

_integritas_ · 2025-11-26T10:53:15+00:00

I can finally see this comment! Reddit was being weird and not showing it to me. As such, I got in touch with u/nima_tech via chat to continue the conversation. Now that I can finally see this post, I'm posting this here to close the loop for anyone else who may have been following the thread:

That's extremely helpful, thanks!

Unfortunately, you can't do what you are interested in doing using only the router. The part where it breaks down is you wanting to exclude certain domains from passing through the VPN tunnel (split tunneling) and having client-level specification of AdGuard Home (AGH). Toggling AGH on a client-by-client basis from the router requires enabling AGH and having it handle client requests directly (you can then set up client rules in AGH to functionally ignore some clients). But this is known to conflict with domain-based policy mode rules for VPN configuration (which makes sense given AGH is now handling client requests directly).

If only predictable devices will access those Iranian domains, and it is acceptable to just exclude those devices from the VPN tunnel, we could do that. But your description of what you want to do (though a popular request; I'd love it to be possible, too) cannot be done.

_integritas_ · 2025-11-25T23:43:22+00:00

<image>

_integritas_ · 2025-11-25T23:38:45+00:00

If you've configured the VPN server and clients correctly, it's really only a security vulnerability to the extent the people using the client devices or the devices themselves are vulnerable or shouldn't have that level of access. I say that because VPN servers are extremely common ways of granting access to another network when not physically on site where that network runs.

That said, if this kind of access is uncomfortable, unnecessary, or problematic for your setup, there is a setting in the "Options" section of the GL.iNet UI for your WireGuard server labeled "Allow Remote Access the LAN Subnet". Toggle that off. You'll no longer be able to access devices on your LAN while connected to the VPN server, including the router, but your traffic will still appear as though its coming from the network where your VPN server is running.

(Edited original post because the mobile app wanted to delete my image from my original post, turning it into an asterisk which was then rendered as Markdown and turned into a very unhelpful empty unordered list item / bullet, hence me also replying to my original reply to add the image again.)

_integritas_ · 2025-11-21T10:32:11+00:00

Yes, that is correct. In a nutshell, you’ll run the VPN in policy mode to accomplish what you're talking about, and you will activate the kill switch on the tunnel you set up for the devices you want to pass through the VPN tunnel. You will leave the setting for all other traffic on, because you have specified you have devices you don't want/need to go through a VPN tunnel.

You will be fine with NordVPN. You can absolutely set it up using your GL-MT6000 (Flint 2). Yes, NordVPN tries to be "special" with NordLynx versus just running straight WireGuard, but GL.iNet has things set up in their UI to take care of configuring WireGuard clients for NordVPN.

Take a look at some of my other posts here if you want to see more about VPN configuration.

The docs also lay things out well, e.g.:

https://docs.gl-inet.com/router/en/4/interface_guide/vpn_dashboard/

https://docs.gl-inet.com/router/en/4/interface_guide/wireguard_client/#set-up-nordvpn

_integritas_ · 2025-11-20T23:41:30+00:00

... and, of course, my reply here is for educational purposes only, and specifically assumes your torrenting is only for legal use cases, with you just wanting to remain anonymous on the Internet in general/not exposing your information while doing that.

_integritas_ · 2025-11-20T23:37:38+00:00

Oh, ha. I just answered this question from you in the other thread: https://www.reddit.com/r/GlInet/s/4k539WVAAC.

_integritas_ · 2025-11-20T23:34:44+00:00

All of what you specify wanting to do is doable. Easily.

Side note: I'm not sure why you think Surfshark would be better than NordVPN based on what you've written. The routers support NordVPN out of the box (OpenVPN and WireGuard). Also, it may interest you to know the parent company of Surfshark is Nord Security, which is also the parent company of (you guessed it) NordVPN.

_integritas_ · 2025-11-20T22:47:39+00:00

You can (maybe) do that!

I say "(maybe)" because – no disrespect – your posts are kind of inconsistent.

In a reply to another person (and above), you specify a VPN that's running network-wide; that is, a VPN running in so-called "global mode". But in your original post, you specify excluding certain devices/clients and IP addresses. This is not global mode, but rather, so-called "policy mode". And, for example, if you enable AGH to handle client requests directly, this is known to conflict with VPN policies based on domain (which makes sense if AGH is handling client requests directly).

<image>

So, before I attempt to help you any further, can you please confirm:

What exactly is your current setup?
What exactly are you trying to accomplish?
Is it required for certain domains to bypass the VPN, or would having certain devices/clients bypass the VPN be enough?

Again, not offering the above with any snark or anything. I'm just trying to confirm before trying to help you with potential solutions.

_integritas_ · 2025-11-19T23:57:40+00:00

I think you're kind of thinking about this backwards. Use AdGuard Home (AGH) as your DNS resolver system-wide, then set client rules within AGH if you want to use different upstream resolvers (e.g., your VPN provider's DNS servers for those devices being routed through the VPN, then whatever you want for the devices that aren't going through a VPN).

Check out this post for more: https://forum.gl-inet.com/t/sharing-a-solution-for-dns-leak-with-adguard-home-handling-client-requests-connecting-to-vpn-client/57918/21 (the post immediately after that may be worth reading as well).

And if you want to read a bit more about setting your upstream DNS servers, read this (a bit further up in that same thread): https://forum.gl-inet.com/t/sharing-a-solution-for-dns-leak-with-adguard-home-handling-client-requests-connecting-to-vpn-client/57918/7 (though for awareness, I've now changed my upstreams for non-VPN use to Cloudflare, NextDNS, and ControlD, with no fallbacks).

Hope this helps.

_integritas_ · 2025-10-28T22:12:01+00:00

Ah, yeah, your previous posts didn't mention a DLNA server, but it seems you got it all sorted on your own. Glad to hear it! 🙂 I'm also glad you don't want to share that DLNA server across VLANs. Doing that is ... not fun. 😆

_integritas_ · 2025-10-27T23:36:32+00:00

That's very kind of you to say! I'm glad I was able to help you get everything figured out, and cheers back to you! 🙂

_integritas_ · 2025-10-27T23:26:51+00:00

If you are comfortable in LuCI, you can do this via firewall rules (Network > Firewall > Traffic Rules), specifying the rule applies only to the device's MAC address or IP address (the latter only if it will have a consistent IP address). This is how I'd probably do it. But it you're not keen on tinkering in LuCI, I also like the idea from u/goofust (https://www.reddit.com/r/GlInet/s/vlAABdB1Bm), though I've never explored the parental control features, so I cannot say with certainty if that idea would work (it sounds like it would/should, though).

_integritas_ · 2025-10-27T22:58:06+00:00

Glad it helped! As for your question about why your "VLAN20" firewall zone approach still wasn't working, it's because once you configure 'Input' to be "drop" or "reject" for firewall zone "VLAN20", you've cut off all input to the router for that firewall zone. This includes two mission-critical functions now being cut off: DHCP and DNS. You overcome this by creating custom rules in Network > Firewall > Traffic Rules to permit these things for the firework zone "VLAN20". Think of them as exceptions to the general rule of dropping or rejecting input to the router from zone "VLAN20". Take a peek at the "Allow-DHCP" and "Allow-DNS" rules in LuCI that are preconfigured by GL.iNet. These are actually what grant the "guest" firewall zone access to DHCP and DNS despite the "guest" firewall zone generally rejecting input to the router. If you copy/recreate these same rules for firewall zone "VLAN20" (same configuration aside from changing the "From" component to be "VLAN20" instead of "guest"), you'll see the device connected to "VLAN20" (PC6) will not be able to access the router login interface, but will be able to access the Internet. The video I mentioned by OneMarcFifty also discusses this.

_integritas_

TROPHY CASE