How to Access Your Home Network While Traveling with Tailscale

Last updated: July 13, 2026

Reaching your home network from a hotel sounds like it should need port forwarding and a static IP. It does not. Tailscale sidesteps both, which is why it has become the default answer for travel routers.

First, decide what you actually want

A subnet router lets you reach devices on your home LAN. An exit node sends your internet traffic out through your home connection. Most people who ask about “tunneling my home IP” actually want an exit node.

These get conflated constantly, and picking the wrong one wastes hours. They solve different problems:

You can enable both on the same home device. But you have to enable them deliberately, because Tailscale does not turn either on by default.

Why CGNAT and a dynamic IP do not matter here

Tailscale devices connect outbound to a coordination server, then negotiate a direct peer-to-peer tunnel. Nothing ever needs to accept an inbound connection, so CGNAT and dynamic IPs are irrelevant.

This is the part that confuses people coming from traditional VPN setups. Port forwarding requires an inbound-reachable public IP, which CGNAT denies you. Our guide on public vs. private IP addresses explains why.

Tailscale never needs that. Both ends dial out, meet in the middle, and use NAT traversal to build a direct tunnel. If a direct path is impossible, traffic falls back to an encrypted relay.

So the common advice to “set a static IP first” is a red herring. It does not help, and skipping it costs you nothing.

Tailscale is the easier path for almost everyone reading this. If you specifically need Windows’ own built-in VPN client instead, for example a corporate policy that requires it, see our guide to reaching a home server behind CGNAT with a native Windows VPN and a cloud relay.

Setting up the home router as a subnet router

Install Tailscale on a device that stays home and advertise your home LAN subnet. Then approve that route in the admin console. The approval step is where most setups fail.

On a GL.iNet router, enable Tailscale under Applications. The setting labeled Allow Remote Access LAN turns the router into a subnet router for its own LAN devices.

If you are configuring by SSH instead, advertise the route explicitly. Use your actual home LAN range:

tailscale up --advertise-routes=192.168.8.0/24 --accept-routes --accept-dns=false

To also use it as an exit node, add the exit node flag:

tailscale up --advertise-exit-node --advertise-routes=192.168.8.0/24 --accept-routes

The step almost everyone misses

Advertising a route does not activate it. Tailscale requires explicit approval in the admin console, as a security measure. Until you approve it, nothing routes.

If your ping failed and you already toggled the router settings, this is the first thing to check.

Setting up the travel router

The travel router needs to accept the routes your home router advertises. On GL.iNet hardware, that is the remote LAN access setting, paired with route approval in the console.

Enable Tailscale on the travel router and sign into the same account. Turn on the setting that lets it receive remote LAN access. Then approve its routes in the console as well.

Once both ends are approved, devices connected to your travel router can reach your home LAN without running Tailscale themselves. That is the whole point of using a router as the gateway.

The subnet conflict that breaks everything quietly

If your home router and travel router both use the same LAN range, routing breaks. A device cannot tell whether 192.168.8.10 means “here” or “at home.”

GL.iNet routers commonly default to 192.168.8.0/24. If both of your routers ship with that default, they collide.

Change one of them. Set the travel router to something like 192.168.9.0/24 and leave home alone. The ranges simply must not overlap.

This failure is silent and confusing, because everything looks configured correctly. If you already changed one router’s LAN IP, you handled this correctly. See our subnetting guide if the ranges are unfamiliar.

Your ping failed. Here is why.

Windows Firewall blocks incoming ICMP echo requests from outside the local subnet by default. Your home PC will ignore a ping from a Tailscale address even when routing works perfectly.

This one wastes an enormous amount of troubleshooting time. People assume a failed ping proves the tunnel is broken. Often the tunnel is fine and the PC is simply refusing to answer.

Test with something other than ping before concluding anything:

• Try opening a service on the device, such as a NAS web interface or a shared folder.
• Ping the home router’s LAN IP instead, since routers usually answer ICMP.
• If you must test with ping, allow ICMP echo in Windows Firewall for private networks.

Also confirm the device you are testing from is actually on your tailnet. A phone must have Tailscale installed and connected, not just be near the travel router.

A working setup, end to end

Tailscale’s free tier covers personal use comfortably. That is why it beats paying someone to configure a traditional VPN. For broader context on tunnels and protocols, see our guide on what a VPN is and how it works.

Frequently Asked Questions