GL.iNet

What Is GL.iNet?

You buy a VPN subscription, flip it on for your laptop, and still end up leaking traffic from your TV, game console, smart speakers, or that one “work-only” device you don’t want touching hotel Wi‑Fi unprotected. A GL.iNet router solves that by moving the VPN to the network edge: you run the VPN on the router and let every connected device benefit—without installing apps everywhere.

This is aimed at people who want VPN coverage for an entire home network, a travel setup, or a small office—especially when they need granular control (some devices through VPN, others direct) and a real “block traffic if VPN drops” option. GL.iNet’s angle is “OpenWrt power with a friendlier UI,” plus router-grade VPN features like policy-based routing and remote management options.

What makes GL.iNet distinctive is the mix: consumer-friendly setup, but with features that normally live in prosumer firmware. Many models ship with VPN tooling (WireGuard and OpenVPN), policy routing, and a kill switch style “block non‑VPN traffic” control baked into the admin panel. The ecosystem also includes a cloud management platform (GoodCloud) with personal and business-oriented tiers. (rtings.com)

GL.iNet Features and Performance

GL.iNet routers are built for running VPN tunnels on the router itself. On at least some current models, OpenVPN and WireGuard are pre-installed in firmware, and reviews of the platform commonly describe VPN connectivity as a core capability rather than an add-on. RTINGS’ Flint 2 review explicitly lists OpenVPN and WireGuard pre-installed (and also mentions Tailscale and ZeroTier support). (rtings.com)

Protocols (confirmed): WireGuard + OpenVPN. Your database already flags WireGuard and OpenVPN support, and GL.iNet’s own material and third-party reviews back that up in practical terms (these are exposed as “client” and “server” options in the router UI on many GL.iNet firmware builds).

A key practical feature is policy-based routing (GL.iNet calls these “VPN Policies”), which lets you decide what goes through the VPN and what doesn’t. Their documentation shows policies based on domain/IP or MAC address, with two basic modes: “only allow the following use VPN” or “do not use VPN for the following.” This is the difference between “protect everything by default” and “protect only these devices/sites.” (docs.gl-inet.com)

GL.iNet also documents a VPN kill switch / leak prevention mechanism under names like “Block Non‑VPN Traffic.” In firmware v4.8+, they describe two modes: a per-tunnel “Tunnel Kill Switch” (enabled by default once a VPN tunnel is activated) and an “Enhanced Kill Switch” behavior in Policy Mode that affects how unmatched traffic behaves. In plain terms: you can make the router block internet access if the VPN goes down, but you need to understand how it interacts with policy routing. (docs.gl-inet.com)

On performance, the honest answer is: it depends heavily on the specific model and your VPN type—but GL.iNet does publish model-level VPN throughput claims in datasheets, and some independent reviews test them. For example, GL.iNet’s Flint 2 (GL‑MT6000) datasheet claims “Maximum 900Mbps” for WireGuard and “Maximum 880Mbps” for OpenVPN (with DCO support). CNX Software’s Flint 2 review (Part 2) specifically set out to test whether the “900 Mbps WireGuard” claim had truth to it, and also notes support for Tor and AdGuard Home among other features (though that article doesn’t focus on those in detail).

Two important realities if you’re shopping GL.iNet as a VPN router platform:

1. WireGuard tends to be the faster option on router hardware (less CPU overhead than OpenVPN in many setups). GL.iNet’s own model datasheets reflect this pattern (for example, their Beryl AX datasheet lists higher “up to” speed for WireGuard than OpenVPN).

2. Wi‑Fi performance and VPN performance are separate problems. A given model can be an excellent Wi‑Fi router and a fast VPN endpoint—or one of those can be the bottleneck. RTINGS rates the Flint 2 as delivering strong overall speed/range for Wi‑Fi 6, while still emphasizing its configurable OpenWrt-based software and VPN feature set. (rtings.com)

Pricing and Plans

GL.iNet is not a VPN service with monthly/annual subscriptions in the way ExpressVPN or NordVPN are. The core purchase is hardware (a one-time router purchase), and that matches your database entry that the pricing model is paid.

There is also a paid component in the ecosystem: GoodCloud, GL.iNet’s remote management platform. GL.iNet presents three GoodCloud tracks—Personal, Enterprise, and VAR—with different capabilities listed (remote access, network configuration, logs/notifications, site-to-site features, and more advanced org/bulk-management options on higher tiers). The GoodCloud page also indicates a “Try for free” callout for Personal, and “Request Demo” for Enterprise/VAR, but it does not publish clear public pricing on that page. In other words: you can infer a tiered structure, but you can’t responsibly quote exact subscription prices from the official page alone. (gl-inet.com)

Refund windows and warranties vary by retailer and region, and GL.iNet sells through multiple channels. Nothing in the sources reviewed here provides a single, universally applicable refund policy you can treat as canonical for every purchase path—so this review won’t invent one.

Privacy and Security Assessment

Jurisdiction: Your database lists Hong Kong, and GL.iNet’s own legal documents reinforce that GL.iNet defines itself (for Terms) as GL Technologies (Hong Kong) Limited and provides a Hong Kong address for contact. Their privacy policy also lists GL Technologies (Hong Kong) Limited as a controller entity with a Hong Kong Science Park address.

Two implications matter for a privacy-tools audience:

1. A router vendor is not your VPN provider. GL.iNet doesn’t see what your VPN provider sees if you run a third-party VPN tunnel. The bigger privacy question is the router firmware itself (telemetry, cloud features, update practices) and whether you enable GL.iNet cloud management.

2. Cloud management changes the threat model. GL.iNet’s privacy policy states that, to provide products and services, GL.iNet may engage internal service providers, including “entities headquartered in China” providing functions like product research, data operations, and customer support. That doesn’t automatically mean “bad,” but it’s material for buyers who want minimal vendor contact and zero cloud dependency. (gl-inet.com)

On open-source posture: GL.iNet routers are commonly described as running a version of OpenWrt. RTINGS explicitly says the Flint 2 “runs a version of OpenWRT.” GL.iNet also maintains public repositories connected to its firmware base. At the same time, GL.iNet’s own public “gl-image” repository documentation is explicit that an “open-source configuration” builds a “Clean image” that excludes GL.iNet proprietary modules and applications (including proprietary applications and Web UI components). That means: parts are open (as required by upstream licenses), but the full shipping experience is not “fully open source.” (rtings.com)

Known incidents / issues: GL.iNet publicly documents security updates in firmware release notes. For example, GL.iNet’s firmware features page for v4.5 mentions a fix for CVE‑2023‑46456, describing it as a critical vulnerability where it was possible to inject arbitrary shell commands through OpenVPN client file upload functionality. That’s a serious class of bug—but also a positive sign that they’re naming the issue and claiming a fix in release documentation.

One more practical security note: kill switches and policy routing are tricky to implement perfectly, and GL.iNet’s own forum includes user-reported issues and edge cases involving kill switch behavior and VPN policy interactions on certain firmware versions. You should treat the kill switch as a feature you need to test in your exact setup (model + firmware + VPN provider) rather than blindly trusting the label.

Strengths and Limitations

Strengths

GL.iNet’s biggest strength is that it makes router-level VPN practical for normal people while keeping enough knobs for power users. The documentation and UI concepts around “VPN Policies” (domain/IP or MAC-based routing) and the v4.8+ split kill-switch behavior show an attempt to solve real-world routing conflicts rather than pretending “all traffic always goes one way.” (docs.gl-inet.com)

Performance potential is real on higher-end models. GL.iNet publishes very high “maximum” VPN throughput numbers for some devices (notably WireGuard), and independent reviewers have treated those claims as testable (e.g., CNX Software evaluating the Flint 2’s 900 Mbps WireGuard claim; RTINGS validating strong Wi‑Fi performance on the same platform). Just don’t generalize a flagship model’s results to every travel router they sell.

There’s also an ecosystem advantage: GL.iNet pairs local router features with an optional cloud layer (GoodCloud) for remote access, grouping, and (in higher tiers) bulk actions/templates and organization management. For some users—MSPs, small IT teams, or distributed remote workers—that’s the difference between “possible” and “operationally maintainable.” (gl-inet.com)

Limitations

GL.iNet’s “OpenWrt-based” story is real, but it’s not as simple as “everything is open.” Their own GitHub documentation for building an open-source image makes clear that GL.iNet proprietary modules/apps and web UI components are excluded from the public open-source build configuration. If your privacy standard is “auditable end-to-end,” you should assume you won’t get that from the stock firmware UI. (github.com)

Second, the most security-sensitive features—kill switch + policy routing—are where edge cases show up. GL.iNet documents multiple modes and defaults, and the user forums show that behavior can be surprising depending on firmware version and routing setup. Translation: you can get excellent leak resistance, but you must validate it yourself after updates. (docs.gl-inet.com)

Third, if you use vendor cloud management, you’re accepting an additional privacy surface. GL.iNet’s privacy policy describes cross-entity processing (including entities headquartered in China) for global services like support and operations. If your goal is “no vendor accounts, no cloud,” you’ll likely want to avoid GoodCloud entirely and run locally managed configuration only. (gl-inet.com)

Who Should Use GL.iNet?

Good fit if you are:

• A traveler or remote worker who wants router-level VPN (WireGuard/OpenVPN) to protect multiple devices on untrusted Wi‑Fi, without installing VPN apps everywhere. (rtings.com)
• A home user who wants selective routing—e.g., VPN only for a streaming box or only for specific domains/devices—using built-in VPN Policies. (docs.gl-inet.com)
• A small team that benefits from remote fleet-style access or management features via GoodCloud tiers (and is comfortable with the cloud tradeoff). (gl-inet.com)

Not a great fit if you are:

• Someone who wants a “set-and-forget” kill switch guarantee across all scenarios without testing after firmware changes (router VPN routing is nuanced, and documented modes/edge cases exist). (docs.gl-inet.com)
• A buyer whose definition of “open source router” is “the full shipping UI and feature set is fully auditable and buildable from public source.” GL.iNet’s own open-source build notes describe excluding proprietary modules/apps from the public build. (github.com)
• Anyone expecting GL.iNet to replace a VPN provider. You still need a VPN service (or your own VPN server) if you want internet-privacy benefits; GL.iNet is the router platform that runs the tunnel. (rtings.com)