Securing a Digital Nomad Worker

Securing a Digital Nomad Worker

Consumer VPN vs Digital Nomad Security: Client Guidance

Use this when a client or MSP partner asks whether a consumer VPN (PIA, Nord, etc.) "secures" their remote workforce. The short answer is no. This article gives the reasoning, the correct stack to recommend, and the travel-router guidance for the one narrow problem a VPN does address.

Overview

A consumer VPN encrypts traffic between the user's laptop and the provider's exit node so someone on the same Wi-Fi cannot read or tamper with it. That is the entire security benefit, and TLS already covers most of it for normal web use. Making a digital nomad safe is an identity, endpoint, and access problem, none of which a consumer VPN touches.

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)
Travel router (balanced)
Travel router (smallest/economical)
Router setup video
GL.iNet first-time setup (YouTube)

What a Consumer VPN Does Not Do

  • Does not 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.
  • Does not check device posture. By contrast, Uplevel ZTNA can gate access on patched OS, disk encryption, EDR running, screen lock, and geo-location, allowing or denying per resource based on device posture.
  • Does not provide access to internal resources. The user still needs file shares, LOB apps, and RDP. A consumer VPN drops them onto the public internet from a foreign exit IP and nothing more.
  • Does not stop phishing, credential theft, session hijacking, or endpoint compromise. If the laptop is owned, the VPN tunnels the attacker's traffic along with everything else.
  • Gives zero visibility. No logs, no alerting, no per-user revocation, no audit trail.

The Real Digital Nomad Threat Model

In order of impact:

  1. Phishing and credential theft.
  2. Endpoint compromise.
  3. Lost or stolen devices.
  4. Lateral movement once one credential is stolen.
  5. Local Wi-Fi snooping.

Local Wi-Fi snooping, the one thing a consumer VPN addresses, is at the bottom of the list, and TLS already handles most of it.

This is what to put in front of a client. The VPN question is a distraction from these controls.

  1. SSO with strong MFA in front of everything. Passkeys or TOTP, never SMS.
  2. ZTNA for internal access. Per-application access brokered by identity instead of a flat tunnel onto the LAN, so a stolen credential exposes one app, not the whole network. This is exactly what Uplevel ZTNA does and it is the correct answer to remote access for the client base.
  3. Managed endpoints. Disk encryption, EDR, patching, screen lock, restricted admin rights. Device posture gates the ZTNA connection so a non-compliant machine cannot get in.
  4. DNS filtering on the device, since the digital nomad is rarely behind the office gateway.
  5. Company-provisioned travel router for high-mobility staff. See the next section. This is a situational add for travelers, not a baseline control for everyone.
  6. Backup, so a lost device or a ransomware hit is an inconvenience instead of a disaster.
  7. Phishing awareness training, since that is the number one vector and the cheapest control to deploy.

Travel Router Guidance

A travel router is the correct way to address the one bottom-tier risk a VPN aims at. A laptop VPN client is the weak way to do it: the laptop is still directly on the hostile LAN, so ARP spoofing, rogue DHCP, rogue DNS, and mDNS or LLMNR poisoning all reach it at layer 2 before or alongside the tunnel.

A GL.iNet travel router fixes that properly:

  • Every 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 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 below are local-network lab maximums. Real-world VPN speeds are lower and depend on the upstream link and exit.

Model
Class
WireGuard (vendor max)
OpenVPN (vendor max)
Notes
Fastest, Wi-Fi 6, quad-core
~550 Mbps
~120 Mbps
Best pick for users who need near-gigabit with the tunnel up
Balanced, Wi-Fi 6, 2.5G WAN
~300 Mbps
~150 Mbps
Good all-rounder, smaller than Slate AX
Smallest, cheapest, 2.4GHz only
~45 Mbps
~11 Mbps
Good all-rounder, smaller than Slate AX

The Beryl AX or Slate AX class are the larger but faster models. The Mango is the smallest and cheapest and is sufficient for typical work plus a ZTNA tunnel, but it caps out well short of gigabit.

Warning
The router becomes the trust boundary once deployed, replacing the role PIA or Nord would have played. Keep firmware current. Stale GL.iNet OpenWrt firmware has known CVEs.

Notes
Setup is straightforward. Hand field techs or the end user the GL.iNet first-time setup video. It covers Ethernet, Repeater, Tethering, and Cellular WAN modes.

Client Summary and Talking Points

Use this framing directly with the client:

  • A consumer VPN protects against a technical adversary at a cafe or hotel snooping on internet traffic. That matters, but TLS already covers the majority of that threat.
  • A travel router does that same job properly. Both still only protect against someone on the cafe or hotel network.
  • Making a digital nomad safe is an identity, endpoint, and access problem. None of those words are on the PIA or Nord website, though their marketing uses language designed to make you feel like they are.
  • If the client wants the local-network protection, they can run a travel router, but it rides on top of the real controls, not in place of them.










    • Related Articles

    • Client VPN - ( L2TP-IPSEC, SSTP, SSL)

      Login to your Uplevel Portal From your Customer's Configuration Page choose VPN Click the Checkbox next to Enable VPN Choose Click here to add a VPN user Enter Username, Password, and the Security Group the User is a Member of Install SoftEther VPN ...
    • Site-to-Site VPN - Non-Uplevel (3rd Party VPN)

      Introduction You can quickly set up IPsec tunnels to connect to third-party firewalls and cloud services. We currently have 'pre-configured' configurations for Microsoft Azure, Amazon AWS, etc. to remove the complexity from connecting to those ...
    • Client VPN - OpenVPN with TOTP MFA

      Our legacy Client VPN Setup Article is located here for all Operating Systems Client VPN is an add-on, flat rate, paid feature. We do not charge per account created. MSP's are able to create 1 management Client VPN account per customer at no charge. ...
    • Site to Site VPN (Uplevel to Uplevel)

      Introduction Configuring site-to-site VPNs between Uplevel Gateways is done with a single click. In addition, routing, switching, firewalling, VLANs are all configured automatically to ensure security with maximum convenience. Configuration From your ...
    • ZTNA - Setup Your First Peers

      Getting started setting up ZTNA Prerequisites Two hosts running Windows, macOS, Linux, Android, or iOS Administrator credentials for both hosts Internet connection on both hosts.- For the best proof of concept, the hosts should not be on the same ...