Per-Device VPN Policies on GL.iNet: A Practical Guide

Here's a scenario every traveling household hits: your work laptop must appear at your home IP, but your partner's tablet streaming local shows shouldn't waste tunnel bandwidth, and the hotel smart TV just needs plain internet. One tunnel, three different needs. GL.iNet VPN policy per device routing is how you give each device its own rule, and it's one of the most underused features on these routers.

> Quick answer: GL.iNet routers let you set per-device VPN policies: choose which devices (by MAC address) route through your home IP tunnel and which go direct. A common setup is work laptop via VPN, everything else direct, or VPN-by-default with exceptions. Configure it in the router's VPN dashboard under VPN Policy, then verify each device's visible IP to confirm it takes the intended path.

How VPN Policies Route Devices Differently

By default, a travel router's VPN is all or nothing: tunnel up, everything goes through it. VPN policies break that into per-device (or per-domain, per-IP) rules. The router checks each packet against your policy list and decides: tunnel or direct.

GL.iNet's implementation (in the VPN dashboard, usually labeled "VPN Policy" or "Proxy Mode") typically offers:

• Global modes: all traffic through VPN, or all traffic direct (tunnel off).
• Per-device rules: pick specific devices by MAC address to use the VPN or bypass it.
• Domain/IP-based rules: route only certain sites or addresses through the tunnel (useful for "only banking and work go home").

The mental model that helps: the policy is a guest list. Devices on the VPN list get the tunnel; everyone else walks straight out the local connection. And like any guest list, it's worth reviewing occasionally because devices change.

Why MAC addresses and not IPs? Because the router's DHCP can reassign IPs, but a device's MAC is (mostly) stable. One caveat: modern phones randomize MAC addresses per network for privacy. If your phone keeps falling off the VPN list, that's why: either disable MAC randomization for your router's SSID (in the phone's WiFi settings) or re-add the new MAC when it changes.

Example: Work Laptop via Home IP, Rest Direct

The most common policy I recommend for traveling workers:

1. Open the GL.iNet admin panel and go to the VPN dashboard. Confirm your WireGuard tunnel to home is up and working.
2. Open VPN Policy (sometimes under "VPN" > "Policy" or within the WireGuard client settings, depending on firmware).
3. Set the base mode to direct (no VPN by default).
4. Add your work laptop's MAC address to the use VPN list. Find the MAC in the router's client list, which shows connected devices.
5. Optionally add your phone too, if you do banking on it.
6. Leave everything else (partner's devices, streaming sticks, guest gadgets) on direct.

Result: your work laptop always exits from home with the kill switch protecting it, while the Fire Stick streams at full local speed without touching your home upload bandwidth. Your partner's video calls don't compete with your tunnel.

The inverse (VPN by default, exceptions direct) suits people whose primary need is location consistency: base mode VPN, then exempt the streaming stick and any device that needs local services. Pick whichever default matches the majority of your devices; exceptions should be the minority.

A third pattern, the domain-based split: instead of per-device, route only specific destinations through the tunnel (your bank, your company's domains, a couple of streaming services) and send everything else direct, for all devices. This is the bandwidth-miser's setup: minimal tunnel load, but you must maintain the domain list and accept that anything not listed goes direct.

Testing That Each Device Takes the Intended Path

Policies are silent when they work and silent when they don't, so verify deliberately:

1. Check the visible IP per device. From the work laptop, visit an IP checker: it should show your home IP. From the exempted tablet: it should show the hotel's IP. If both show the same thing, the policy isn't applying.
2. Check after reconnects. Policies apply when devices join; have each device forget and rejoin the WiFi, then re-check. This catches the "policy only applies to devices connected after the rule was created" quirk some firmware has.
3. Watch for MAC randomization. On iPhones and Androids, check the WiFi settings for your router's SSID: if "Private WiFi Address" (iOS) or "Randomized MAC" (Android) is on, the MAC the router sees may differ from what you added. Either turn it off for this network or update the policy with the randomized MAC.
4. Test the kill switch interaction. With per-device policies, confirm the kill switch (block non-VPN traffic) behaves as you expect: typically it applies to VPN-routed devices. A policy-exempt device going direct is supposed to bypass the tunnel, so don't mistake that for a leak. Know which devices are in which bucket.
5. Re-verify after firmware updates. Router updates occasionally reset or reinterpret policy settings. After any update, spend two minutes re-checking the IP on each device class.

Troubleshooting the usual suspects:

• Device shows wrong IP: MAC mismatch (randomization), policy not saved/applied, or device connected before the rule existed. Rejoin WiFi.
• Everything goes through VPN despite policy: base mode is set to VPN, or the policy engine didn't restart after changes. Toggle the VPN client off and on.
• Nothing goes through VPN: tunnel itself is down. Policies don't matter if the tunnel isn't up; check the tunnel first, policy second.

FAQ

Need help setting this up?

Per-device policies are quick to configure and easy to get subtly wrong. We'll set yours up and verify every device on a $79 consultation: https://homeipvpn.com/appointment. Consultations run remotely via remote desktop at your scheduled appointment, and the $79 counts toward the $379 Secure Home IP VPN System session.