This is a technical reference, not a sales page. The DIY path is fully documented. The productized path is also mentioned so the picture is complete.
What A Two Router VPN System Actually Is
Two routers, one job. The router at your home stays put on your home internet connection and terminates an inbound VPN tunnel. The travel router is a small battery-powered or USB-powered device you pack in your bag. When you power the travel router on and connect to whatever local WiFi is available (hotel, Airbnb, cafe, coworking space), it opens a persistent tunnel to the router at home and then advertises its own WiFi network. Every device you connect to the travel router's WiFi has its traffic tunneled to the home router first, then sent out from your home internet as normal.
The setup goes by several names in different corners of the internet. Some people call it a dual router VPN. Others call it a home IP relay, a residential VPN, or just "hosting your own VPN at home." The mechanics are the same regardless of the label.
The reason people build one, or buy a productized version, is that a home IP looks completely different to the rest of the internet than a commercial VPN IP looks. A destination server can see the difference in seconds using free-to-query databases. The home-IP relay versus consumer VPN guide covers the structural comparison in depth. Short version: commercial VPN IPs are on public blocklists that any risk engine can subscribe to. Residential ISP IPs are not.
Why This Works When A Consumer VPN Does Not
A consumer VPN client on your laptop opens a tunnel to a datacenter server run by the VPN vendor. Traffic exits from that datacenter. The destination sees a datacenter IP.
Three things go wrong with that pattern for anyone whose goal is to look like they are at home:
Datacenter IP
- Exit IP is in a commercial hosting range that any risk engine can look up
- Same IP is shared with thousands of other VPN users, some abusive
- Employer SIEM flags "datacenter origin" as a policy signal on its own
- Streaming platforms proactively block the ranges
Residential IP
- Exit IP is your home internet, on the same ISP range as your neighbors
- IP is used only by you and your household, no shared-abuse history
- SIEM sees a residential ASN, which is expected for a remote employee
- Streaming and geo-fenced services see a normal home connection
The second problem with a laptop-installed VPN is that the client is visible on the device. Corporate MDM tools, endpoint agents, and even the OS itself can enumerate installed applications and running services. An enterprise IT team that sees an unauthorized VPN client on a work laptop can treat that as a policy violation on its own, before any traffic even leaves the machine.
A two router VPN system moves the tunnel off the laptop entirely. The work device just sees a normal WiFi network. There is nothing to install, nothing to detect, and no configuration for a corporate policy scan to catch.
The third problem is impossible-travel detection. Enterprise identity providers (Okta, Azure AD, Ping, Duo) log the IP of every authentication and compare successive logins for physical plausibility. A user who signs in from Chicago at 9 AM and Prague at 11 AM triggers an alert regardless of what VPN was used, because the second IP is a Prague IP. If your traffic keeps emerging from your Chicago home the whole time, the identity provider only ever sees a Chicago IP, and the impossible-travel logic has nothing to fire on.
The Traffic Flow, Step By Step
Here is what happens when you open a work app from a hotel in Paris while your home router is in Tampa.
The important thing to notice in this diagram: the laptop never talks directly to the internet. It talks to the travel router. The travel router talks to the hotel WiFi, but only to reach the home router. Once the tunnel is up, all laptop traffic goes into the tunnel first. The laptop does not know or care that it is in Paris. From its perspective, it is on a WiFi network called (for example) MyHouse, exactly like at home.
The employer's monitoring stack sees the connection arriving from the home ISP's IP address in Tampa. Impossible-travel checks pass because the login IP is stable. Zscaler or Cisco Secure Client posture checks pass because the tunnel is coming from an expected residential ASN. Corporate DNS resolves to normal internal endpoints because DNS queries are travelling inside the tunnel to the home network, not leaking to the local hotel resolver.
Building It Yourself With WireGuard
You can build this yourself for the cost of two travel-class routers plus your time. The most popular hardware is GL.iNet's Slate or Beryl line, both of which run OpenWrt with WireGuard support out of the box. You need one for home and one for travel. The following is a real, working WireGuard configuration.
Hardware you need
A home router with WireGuard server support and a public IP on its WAN interface (or port forwarding through your ISP router). A small travel router with WireGuard client support and a USB-C or micro-USB power input for the road. A cable to plug the travel router into the wall or a power bank. That is all.
Home router WireGuard server config
On the home router, generate a keypair and configure a WireGuard server that listens on UDP port 51820. Below is a minimal wg0.conf that accepts one client (the travel router) and lets it use the home internet as an exit.
Travel router WireGuard client config
On the travel router, configure a client that connects to the home router, uses the home IP as the default route for all traffic, and pushes DNS to a resolver you trust (either the home router itself or a public resolver like 1.1.1.1).
The AllowedIPs = 0.0.0.0/0, ::/0 line is the important one. It tells the travel router to send every packet from every connected client into the WireGuard tunnel. Without it, only traffic addressed to the home network subnet would be tunneled, and everything else would leak to the local hotel WiFi.
Verifying the setup
Connect a laptop to the travel router's WiFi. Open a browser and go to a "what is my IP" service like ifconfig.co. The result should show your home ISP's IP and location, not the hotel WiFi's IP. Run a DNS leak test at dnsleak.com. The reported resolver should be your home network or the resolver you set in the travel router config, not the hotel's local resolver. If either check fails, revisit the AllowedIPs and DNS lines in the travel router config.
Skip the assembly?
The two router pattern is straightforward but the failure modes below take time to run into and diagnose. HomeLink ships the same setup pre-paired, with the failure modes already handled in firmware.
See HomeLink pricingSix Things That Break In The Wild
The tunnel coming up is the easy part. What actually catches DIY builders (and what most guides skip) is the six-way collection of side channels and edge cases that can undo the whole effort. Each is fixable. Most people learn about them only after a nasty surprise.
Timezone drift on the OS
Most operating systems auto-adjust the clock based on the network. If the laptop connects to hotel WiFi (even briefly before the travel router is up), macOS or Windows may set the timezone to Central European Time. Your home IP still says Tampa. Some enterprise monitoring tools (and more subtly, most calendar and email applications) send the local timezone along with authentication tokens or as a header. A mismatch between the timezone and the IP-implied location is a detection signal on its own.
Fix: turn off automatic timezone adjustment. Set the timezone manually to match your home. Keep it manual for the duration of the trip.
DNS leaks to the local network
If the travel router config forgets to route DNS through the tunnel, every DNS lookup goes to the local ISP's resolver (the hotel WiFi). The web request itself may exit through your home IP, but the DNS lookup that came milliseconds before it exposes the fact that a device is querying from the local network. Passive DNS monitoring at your employer or on the destination side can correlate this.
Fix: set an explicit DNS line in the travel router's WireGuard client config that points at the home router or a public resolver reachable through the tunnel. Verify with a DNS leak test.
WebRTC leaks in the browser
WebRTC is the peer-to-peer protocol behind most video calling. When a browser initiates a WebRTC session, it enumerates every local network interface and sends candidate IP addresses to the remote peer. On a two router VPN setup, one of those candidates can be the laptop's private IP on the local hotel WiFi, revealing to the receiving service (Zoom, Meet, Teams, or any WebRTC app) that the device has an active interface on a network the tunnel does not cover.
Fix: disable WebRTC in the browser or use a WebRTC-blocking extension. On Chrome, install a policy that forces WebRTCIPHandling to disable_non_proxied_udp. On the travel router, disable the local WiFi interface for the laptop if possible (wired-only connection eliminates the alternate candidate).
OS-level WiFi geolocation
Even with your IP address masked, Windows and macOS run their own location services that scan the nearby WiFi networks and query Apple's or Google's databases to look up the physical location of those BSSIDs. This location is available to any application on the OS that asks for it. Many enterprise MDM tools and some monitoring vendors query the OS location API and see the true location, not the home IP location.
Fix: disable OS location services entirely on the work device, or use firewall rules at the travel router to block outbound connections to ls.apple.com and Google's location endpoints. On a corporate-managed laptop where you cannot disable location services, the travel router block is the only viable approach.
Captive portals blocking WireGuard
Hotel, airport, and coworking WiFi almost always require captive portal login. Some captive portals block outbound UDP entirely (WireGuard uses UDP by default). The travel router can associate with the WiFi and pass the captive portal, but the tunnel to home refuses to come up because the return traffic is silently dropped.
Fix: use a TCP-over-WebSocket relay in front of WireGuard (wstunnel is the common choice) so the tunnel traffic looks like ordinary HTTPS from the network's perspective. This adds a small overhead but works on almost every captive network.
Home internet outage
If your home internet goes down while you are abroad, the tunnel breaks and the travel router falls back to routing directly through the local WiFi. Suddenly your work laptop is connecting from a Paris IP, all the impossible-travel alerts fire, and you may not notice until a support ticket lands.
Fix: configure a strict kill switch on the travel router so it drops all traffic if the tunnel drops. Watch for tunnel-down events yourself (a status LED or push notification if the firmware supports it). Have a plan for temporary home internet outages when planning long trips.
Build Versus Buy: The Real Trade-Off
The DIY path is a real option and a lot of technical people run this setup successfully for years. If you are comfortable in OpenWrt, own the failure modes, and want the flexibility to customize, building your own is the right call.
The productized path exists because the six failure modes above take time to run into and time to fix, and because keeping the tunnel up reliably over the long term requires firmware maintenance, DDNS management, and eventual hardware replacement. HomeLink is one option. There are others (GL.iNet's own cloud product, and a few small competitors). The comparison below is not a pitch, it is the trade-off itself.
Full DIY on GL.iNet
- Hardware cost around $150 for two routers
- Initial setup time realistically 4 to 8 hours end to end
- You own the firmware upgrades and the DDNS
- You own the six failure modes and every debug session
- No recurring cost
- Full customization and portability of your setup
HomeLink or similar
- Hardware cost around $200 to $300 for the pair
- Setup time under 10 minutes, no config editing
- Firmware updates and failure-mode fixes ship automatically
- Kill switch, DNS routing, TCP fallback all built in
- Monthly subscription (varies by provider)
- No customization beyond what the UI exposes
The honest answer to "which should I choose" is: if you would enjoy the build for its own sake and have time to maintain it, build. If the setup is a means to an end and your time is worth more than the hardware markup, buy. Neither is wrong.
Frequently Asked Questions
Do I need a static IP at home?
Technically no. Most residential ISPs assign dynamic IPs that change infrequently. You can use a Dynamic DNS service (like DuckDNS or the free tier of Cloudflare DNS) to give your home router a stable hostname that always resolves to the current IP. In practice, static IPs make the whole setup more predictable. Some ISPs will provide a static IP for a small monthly fee. Ask.
Can I use this to bypass Netflix or streaming region blocks?
Yes for services that block based on IP location. Your home IP is a residential IP in your home country, so streaming services see you as being in your home country. This is not the primary use case, but it does work as a side effect. Note that some streaming services also check DNS behavior and browser signals, so the tunnel needs to be configured correctly (see the DNS leak section above).
Will this hide me from my employer's monitoring?
It hides your location. It does not hide what you do on the work laptop from monitoring software that runs on the laptop itself. If your employer uses screen-recording tools, keystroke loggers, or endpoint activity monitoring, those still see everything you do. The two router VPN system only affects what the network layer reveals about where you are.
Does it work with Zscaler or Cisco Secure Client?
Yes, and this is one of the strongest reasons people build the setup. Zscaler, Global Protect, Cisco AnyConnect, and similar enterprise VPN clients typically check the IP the tunnel is connecting from and look for anomaly signals. Because the tunnel appears to originate from your home IP the whole time, these tools do not fire. Note that this only covers the network posture. If your employer also does device-level GPS or WiFi-BSSID location checks, those are a separate concern and need OS-level configuration.
What if my home internet goes down?
You lose connectivity through the tunnel. With a properly configured kill switch on the travel router, no traffic leaks out through the local WiFi, so your employer does not suddenly see you connecting from a foreign IP. But you are also offline until the home internet comes back. For extended trips, this is a real operational risk. Some people mitigate by putting the home router on a UPS and having a family member available to restart the home ISP router if needed.
Is this legal?
The technical setup itself is legal in most jurisdictions. Using it to violate an employer's remote-work policy is a contract issue, not a legal one, but the consequences of getting caught can include termination. Using it to violate specific laws (like data residency laws for regulated data such as healthcare or financial records) is a legal issue. Understand what your employer's policy actually says, and understand what regulations apply to the specific data you work with, before making a decision.
How does this compare to a service like Perimeter 81 or Twingate?
Perimeter 81, Twingate, and similar zero-trust network access products are business-to-business tools that let a company grant selective access to internal resources. They are the opposite of what a two router VPN system does. A ZTNA product controls what resources you can reach. A two router VPN system controls what IP you appear to come from. They solve different problems.
The two router pattern, pre-built
Two routers, paired at the factory. Kill switch, DNS routing, TCP fallback, and DDNS all handled. Ships in a box, works in ten minutes.
Learn more about HomeLink