Why this article exists
Use this when a client or partner asks whether a consumer VPN (PIA, Nord, etc.) “secures” their remote workforce. The short answer is no. The longer answer covers the reasoning, the correct stack to recommend, and travel-router guidance for the one narrow problem a VPN actually addresses.
The short version
A consumer VPN encrypts traffic between the user’s laptop and the provider’s exit node, so someone on the same Wi-Fi can’t read or tamper with it. That’s the entire security benefit — and TLS already covers most of it for normal web traffic. Making a remote worker actually safe is an identity, endpoint, and access problem, and a consumer VPN doesn’t touch any of them.
| Item | Value |
|---|---|
| Bottom line | Consumer VPN is a privacy product, not a security program |
| The real problem | Identity, endpoint, and access — not a VPN purchase |
| Correct internal-access answer | Uplevel ZTNA, not a flat tunnel |
| Travel router (fastest) | Slate AX (GL-AXT1800) |
| Travel router (balanced) | Beryl AX (GL-MT3000) |
| Travel router (smallest/economical) | Mango (GL-MT300N-V2) |
| Setup video | GL.iNet first-time setup (YouTube) |
What a consumer VPN does not do
- Doesn’t authenticate the user to client resources. The tunnel has no idea whether the device on the other end is the corporate laptop or a compromised personal machine.
- Doesn’t check device posture. Uplevel ZTNA can gate access on patched OS, disk encryption, EDR running, screen lock, and geo-location — allowing or denying per-resource. A consumer VPN does none of this.
- Doesn’t provide access to internal resources. Users still need file shares, line-of-business apps, RDP. A consumer VPN drops them onto the public Internet from a foreign exit IP and nothing more.
- Doesn’t stop phishing, credential theft, session hijacking, or endpoint compromise. If the laptop is owned, the VPN tunnels the attacker’s traffic right along with everything else.
- Gives zero visibility. No logs, no alerting, no per-user revocation, no audit trail.
The actual threat model
In rough order of impact:
- Phishing and credential theft.
- Endpoint compromise.
- Lost or stolen devices.
- Lateral movement after a credential is stolen.
- Local Wi-Fi snooping.
The one thing a consumer VPN addresses sits at the bottom of this list, and TLS already handles most of it.
The stack we actually recommend
Put these in front of the client. The VPN question is a distraction from these controls.
- SSO with strong MFA in front of everything. Passkeys or TOTP — never SMS.
- ZTNA for internal access. Per-application access brokered by identity, instead of a flat tunnel onto the LAN. A stolen credential exposes one app, not the whole network. This is exactly what Uplevel ZTNA does, and it’s the right answer for our customer base.
- Managed endpoints. Disk encryption, EDR, patching, screen lock, restricted admin rights. Device posture gates the ZTNA connection so a non-compliant machine can’t get in.
- DNS filtering on the device — the digital nomad is rarely behind the office gateway.
- Company-provisioned travel router for high-mobility staff (see below). Situational, not baseline.
- Backup. A lost device or a ransomware hit becomes an inconvenience instead of a disaster.
- Phishing-awareness training. It’s the #1 vector and the cheapest control to deploy.
When a travel router is the right tool
A travel router is the correct way to handle the one bottom-tier risk a VPN aims at: hostile local Wi-Fi.
A laptop-side VPN client is the weak way to do this — the laptop is still directly on the hostile LAN, so ARP spoofing, rogue DHCP, rogue DNS, and mDNS / LLMNR poisoning all reach it at layer 2 before (or alongside) the tunnel.
A GL.iNet travel router fixes this properly:
- Every user device sits behind the router’s own NAT. The hostile network only ever sees the router’s MAC and an opaque tunnel.
- The user’s actual devices never broadcast on the hostile segment.
- The kill switch is enforced at the gateway instead of per app.
- Captive-portal auth happens once on the router, instead of leaving each device naked on the LAN while a VPN client negotiates.
- It collapses the entire layer-2 attack surface and gives consistent egress protection and logging.
It still does nothing for the four risks above local Wi-Fi snooping.
Model selection
Vendor throughput figures are local-network lab maximums. Real-world VPN speeds will be lower and depend on the upstream link and exit.
| Model | Class | WireGuard (vendor max) | OpenVPN (vendor max) | Notes |
|---|---|---|---|---|
| Slate AX (GL-AXT1800) | Fastest, Wi-Fi 6, quad-core | ~550 Mbps | ~120 Mbps | Best pick when users need near-gigabit with the tunnel up |
| Beryl AX (GL-MT3000) | Balanced, Wi-Fi 6, 2.5 G WAN | ~300 Mbps | ~150 Mbps | Good all-rounder, smaller than Slate AX |
| Mango (GL-MT300N-V2) | Smallest, cheapest, 2.4 GHz only | ~45 Mbps | ~11 Mbps | Sufficient for typical work + a ZTNA tunnel, but caps well below gigabit |
The router becomes the trust boundary once deployed. Keep firmware current. Stale GL.iNet OpenWrt firmware has known CVEs.
Setup is straightforward. Send the field tech or end user the GL.iNet first-time setup video. It covers Ethernet, Repeater, Tethering, and Cellular WAN modes.
Talking points for the client
Use this framing directly:
- A consumer VPN protects against a technical adversary in a café or hotel sniffing internet traffic. That matters — but TLS already covers most of it.
- A travel router does that same job properly. Both still only protect against someone on the café or hotel network.
- Making a remote worker safe is an identity, endpoint, and access problem. None of those words are on the PIA or Nord marketing pages, though their copy is written to feel like they are.
- If the client wants the local-network protection, run a travel router — but it rides on top of the real controls, not in place of them.