Your router’s status page shows a WAN address beginning 100.82, every port forward you configured has quietly stopped answering, and nothing on your side changed. No new firewall rule, no moved cable. What changed is the ISP. That address looks public if you squint and is not, and the moment your line moved behind carrier-grade NAT every forwarding rule on that router became decoration. Rebooting does not help, and neither does deleting and recreating the rule, which is how most people spend the first hour. This is the ordinary state of Indian home broadband rather than a fault, and it is not going to be reversed for you. The useful response is to stop trying to accept inbound connections at all. A mesh VPN gives every machine you own a stable private address and lets them find each other outward, so the port-forwarding page stays empty and you still reach your flat from anywhere. Here is how that works, and where it does not.
why your port forward quietly stopped working
Port forwarding rests on one assumption: that the address on your router’s WAN side is a real public address, reachable from outside. On Indian broadband that is increasingly untrue. IPv4 addresses ran short years ago, so rather than buy more, ISPs put many subscribers behind one shared public address. That is carrier-grade NAT, and it means nothing outside can start a connection to you, because no port on that shared address belongs to you. Dynamic DNS does not help either, since the name resolves to an address you do not own. Two-minute check:
# What the internet sees
curl -4 ifconfig.me
# Now read the WAN address on your router status page.
# Router showing 100.64.0.0 to 100.127.255.255, with a different
# address above, means you are behind carrier NAT.Some Jio, Airtel and BSNL plans will sell you a static public address as an add-on, and a few business plans include one. That is a valid route if you want it. Everything below is the route that needs nothing from your ISP at all.
what a mesh VPN is doing differently
A traditional VPN has a shape: one server with a public address, clients that dial into it. That is the model in my WireGuard setup guide, and it works well when you have a VPS to point at. A mesh VPN inverts it. Every device gets a stable private address on a network only your devices belong to, and any two of them talk directly instead of through a central box. Tailscale is the one this guide uses. It uses WireGuard for the encryption and adds the part WireGuard leaves out: working out where each peer currently is.
the coordination server’s job
Both devices make an outbound connection to a coordination service. Outbound works fine behind carrier NAT, since that is just ordinary browsing as far as the ISP is concerned. The service tells each peer the other’s public keys and the address and port its packets appear to come from. The two then send packets at each other simultaneously, and the NAT devices on both sides, having just seen outgoing traffic to that address, let the replies through. That is NAT traversal, and it is the whole reason no inbound port is needed.
when the punch fails
Some NAT implementations are hostile to this, notably ones that assign a fresh outbound port per destination. When no direct path can be established, traffic falls back to a relay: an encrypted hop through a server that cannot read what it carries, because the keys never leave your devices. Relayed links are slower, which you notice copying a large file and do not notice reading a dashboard. tailscale status tells you which of yours are direct.
setting it up on a home server and a phone
Start with the always-on machine. An old ThinkPad running Ubuntu is an ideal candidate, and that build is in my old laptop home server guide.
# On the home server
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
# It prints a login URL. Open it, sign in, and the machine joins.
tailscale status
tailscale ip -4
# Optional but very handy on a headless box:
sudo tailscale up --sshThen install the app on your phone and laptop, sign in with the same account, and that is it. Each device gets an address that stays the same on home Wi-Fi, mobile data or a hotel network, and your server answers on it from anywhere. No ports opened to the internet, nothing listening on a public address you do not have.
Turn off key expiry for the home server in the admin console, or it will drop off the network in a few months and you will be locked out of the one machine you cannot walk over to.
subnet routers and exit nodes, plainly
Two features carry confusing names. A subnet router lets one member device pass traffic to other machines on its LAN, so your printer, NAS or router admin page becomes reachable without installing anything on them. An exit node sends all of a device’s internet traffic out through that node, so a laptop in a hotel browses as though it were sitting on your home connection.
# Kernel forwarding first, or the subnet route silently does nothing
echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf
# Advertise the home LAN, and offer this box as an exit node
sudo tailscale set --advertise-routes=192.168.1.0/24 --advertise-exit-nodetailscale set changes only the settings you name. Both need approving once in the admin console, a sensible guard against a device advertising routes you did not intend. One caution: if your home LAN uses 192.168.1.0/24 and the café Wi-Fi uses the same range, the addresses collide. Move the home LAN onto something uncommon, 192.168.29.0/24 or similar, and that problem never arrives.
| Goal | What you switch on |
|---|---|
| Reach one server you control | Nothing extra, just install on both |
| Reach a printer or NAS with no client | Subnet router on any LAN machine |
| Send your browsing out via home | Exit node, enabled per client |
| Short names instead of addresses | MagicDNS in the admin console |
| Let a friend use one service only | Device sharing plus an ACL rule |
MagicDNS, ACLs and lending out one machine
MagicDNS gives every device a name, so ssh anurag@homeserver works instead of remembering an address. Enable it on day one. If a Pi-hole does the resolving on your LAN, set --accept-dns=false on the machines that must keep using it.
Access control is the part people skip and later regret. By default every device of yours reaches every other device of yours, which is fine for three machines you own and wrong the moment a family member joins. The policy file is small:
{
"hosts": { "homeserver": "100.101.102.103" },
"tagOwners": { "tag:family": ["you@example.com"] },
"acls": [
{ "action": "accept", "src": ["you@example.com"], "dst": ["*:*"] },
{ "action": "accept", "src": ["tag:family"], "dst": ["homeserver:8096"] }
]
}Replace 100.101.102.103 with the server’s address from tailscale ip -4, and you@example.com with your own login. There’s no catch-all rule for every member, so your account reaches everything and devices tagged tag:family reach only port 8096 on the server. Use the policy editor’s preview and tests before saving.
Sharing sends an invite for a single device to someone outside your network, so a relative can reach the media server and nothing else. Their machines never appear on your network and yours never appear on theirs.
what the coordination service sees
Be clear-eyed about this, because it is the trade you are making. The service holds your account, your device list and names, public keys, and the addresses your devices connect from. That is metadata about your network, and it is not nothing. What it does not hold is your private keys, generated on each device and never sent anywhere, so traffic between your own machines is not readable by the service. A relay, when one is needed, forwards ciphertext it cannot open.
So this is not anonymity and was never sold as such. It is confidentiality between your devices plus a directory that knows those devices exist. If the directory is what you object to, a plain WireGuard tunnel avoids the third party entirely. A VPN of any shape moves trust rather than removing it, and the VPN explainer covers that trade in more detail.
the free tier, and when plain WireGuard wins
The free Personal plan, as listed on Tailscale’s pricing page on 9 October 2026, allows up to six users, unlimited user devices and 50 tagged resources such as exit nodes. That covers a household. The paid Standard and Premium plans are priced per user and aimed at teams. Check the current terms before relying on this, since tiers do shift.
| Situation | Better choice |
|---|---|
| Behind carrier NAT, several devices | Mesh VPN |
| You already rent a VPS with a public address | Plain WireGuard |
| No third party in the path, at any cost | Plain WireGuard |
| Phones roaming between data and Wi-Fi | Mesh VPN |
| Giving one person access to one service | Mesh VPN |
common mistakes
- Leaving key expiry on for the always-on server. When the key expires, the server drops off the network. The admin console’s Temporarily extend key option gives you a 30-minute window to fix it, but it’s simpler to disable expiry for that one trusted server in advance.
- Advertising a subnet route without IP forwarding enabled. The route appears in the console, traffic goes nowhere, nothing explains why.
- Keeping 192.168.1.0/24 at home, then wondering why subnet routing breaks on other people’s Wi-Fi.
- Assuming an exit node speeds things up. It adds a hop, and your home upload becomes the ceiling for everything.
- Skipping ACLs until a second person joins, by which point every laptop can see every NAS.
- Treating a private network as a reason to stop patching. One layer never covers the rest, the same argument I make in my encrypted DNS guide.
FAQ
does this replace a commercial VPN subscription?
Only partly. For reaching your own machines, and for keeping traffic confidential on an untrusted network by routing it through your own home, an exit node does that job well. For anything that depends on many server locations, no, because your only exit is your own line.
will it drain my phone battery?
Not meaningfully, which surprises people. WireGuard is quiet when idle, so a phone with the tunnel up and no traffic is mostly keeping a connection alive. Routing everything through an exit node all day is a different matter. A sensible default is the tunnel on and the exit node off unless you don’t trust the network.
is a mesh VPN slower than a port forward was?
A direct connection costs you encryption overhead and very little else, so for reaching a file server it feels the same. A relayed connection is noticeably slower on large transfers because the packets travel further. Check tailscale status, and if a pair is stuck on a relay, allowing outbound UDP on both networks usually fixes it.
does IPv6 change anything?
It helps. Many Indian connections now carry working IPv6 alongside carrier NAT on IPv4, and with no address translation to work around, direct paths come up more often. You configure nothing differently.
The first test worth passing is a small one: two machines on the network, one of them reached from mobile data while the port-forwarding page on your router stays empty. Get that working before you build anything on top of it, and the rest of this guide is refinement.
Update history: the ACL example no longer gives every member access to everything, the free-plan limits match Tailscale’s pricing page, IPv6 forwarding is added for exit nodes, and route changes now use tailscale set.
Sources
- Tailscale knowledge base — subnet routers, exit nodes, MagicDNS, key expiry and the ACL policy syntax used here.
- WireGuard protocol description — the key exchange and packet handling underneath the mesh.
- RFC 4787 — NAT behavioural requirements for UDP, which explains why traversal succeeds on some networks and not others.