Every device in the flat shows full Wi-Fi bars and not one of them can reach the internet. The TV cannot find the media server, and somebody’s cricket highlights have stopped mid-over. Nothing is broken in any dramatic way: the router’s DHCP range moved, a Pi-hole is still handing out the old gateway address, and every device now holds a perfectly valid lease with a dead route inside it. Eleven minutes to fix once you know that. Considerably longer if you are diagnosing it at eleven at night with an audience forming in the doorway. Home lab networking is not technically hard. What makes it hard is that the network is shared infrastructure belonging to people who never agreed to your hobby, so every change you make is a change to their evening. This is the useful half — stable addresses, local names, working around carrier NAT, light segmentation — in an order that keeps the household on your side.
give the server an address that never moves
Everything else depends on this. If your server’s address changes after a power cut, every bookmark, every port forward and every container pointing at it breaks at once. There are two ways to fix it, and one is better for reasons that only show up later.
DHCP reservation is usually the right answer
A reservation tells the router “whenever this MAC address asks, always give it this address”. The server still uses DHCP, so it picks up gateway, DNS and subnet automatically. Change the network layout later and it follows along without anyone editing a file on it. The configuration lives in one place, the router, which is where you will look for it in eight months.
Set it outside the pool the router hands out dynamically. If your router gives out addresses from 100 upwards, put infrastructure below that: router at 1, DNS server at 53 because it amuses me, file server at 50. Deliberate numbering makes a network readable.
a genuinely static address, when you need one
Configure the address on the machine itself when it must work even if the router is rebooting or replaced — a DNS server is the classic case, because if it waits for DHCP and the DHCP server is waiting for DNS, you get a stalemate. On Ubuntu that means netplan:
# /etc/netplan/99-server.yaml (sorts after any installer file; or edit that file instead)
network:
version: 2
ethernets:
enp3s0:
dhcp4: false
addresses:
- 192.168.1.50/24
routes:
- to: default
via: 192.168.1.1
nameservers:
addresses: [192.168.1.53, 1.1.1.1]# Netplan merges every file in /etc/netplan in name order and later files win,
# so check for an installer file that sets dhcp4 for the same interface first
ls /etc/netplan/
sudo chmod 600 /etc/netplan/99-server.yaml
# Applies the change, then reverts in 120 seconds unless you confirm
sudo netplan try
# Verify what you actually got
ip -brief address
ip route show default
resolvectl status | head -20netplan try saves you from locking yourself out of a headless box: it applies the configuration, waits for Enter, and rolls back if you never press it. That timer earns its keep the first time a typo lands in the gateway line.
local names, so you stop memorising numbers
Typing an address into a browser works until you have six services. Then you want media.home.arpa and cloud.home.arpa. You have three practical ways to get there.
The laziest is mDNS: most Linux and macOS machines answer to hostname.local with nothing configured, which covers two or three devices and is unreliable across some Wi-Fi setups. The most useful is a local DNS server — if you already run Pi-hole or AdGuard Home for the house, it can serve local names too. That is the arrangement I would choose, layered on top of the install from my Pi-hole setup guide.
# Pi-hole v6: add local records (or use Settings, Local DNS Records, in the web UI)
sudo pihole-FTL --config dns.hosts '["192.168.1.50 media.home.arpa", "192.168.1.50 cloud.home.arpa", "192.168.1.51 nas.home.arpa"]'
# Plain dnsmasq (Pi-hole v6 only reads this with misc.etc_dnsmasq_d enabled):
# /etc/dnsmasq.d/local-names.conf
address=/media.home.arpa/192.168.1.50
address=/cloud.home.arpa/192.168.1.50
address=/nas.home.arpa/192.168.1.51
# Test from any device on the network
dig +short media.home.arpa
nslookup cloud.home.arpa 192.168.1.53Use a suffix reserved for exactly this. Do not invent names under a public domain you do not own, and note that .local belongs to mDNS, so a DNS server answering for it confuses some clients. The standard choice is home.arpa (RFC 8375), giving names like media.home.arpa; ICANN has also reserved .internal for private use. Either stays out of everything else’s way.
why the router your ISP gave you fights back
The box that came with your Jio or Airtel fibre connection exists to get a household online cheaply and be supported over the phone. Here is roughly what to expect from stock ISP hardware.
| Capability | Typical ISP router | Notes |
|---|---|---|
| DHCP reservations | Usually yes | Sometimes buried under an odd menu name |
| Custom DNS for all clients | Sometimes | Many lock the LAN DNS to the ISP’s own servers |
| Port forwarding | Present, often useless | Blocked upstream by carrier-grade NAT anyway |
| VLAN tagging on LAN ports | Rarely | This is the main reason people buy their own router |
| Guest network isolation | Often yes | The poor man’s segmentation, and genuinely useful |
| Static routes | Sometimes | Needed if you run a second router behind it |
| Admin access at all | Varies | Some units ship with the interface restricted to the ISP |
If the DNS field is locked, you have two ways around it. Run your own DHCP server instead of the router’s, which works but makes the network depend on that one box. Or put your own router behind the ISP unit, use the ISP box as a dumb modem where possible, and do everything real on hardware you control. OpenWrt removes almost every limitation in that table at once.
carrier NAT, port forwarding, and the better alternative
Many Indian home broadband connections put you behind carrier-grade NAT. You share a public address with many other subscribers, your router’s “public” address is itself private, and no amount of port forwarding will make an inbound connection reach you. Confirm it in a minute: compare the WAN address on your router’s status page against what a “what is my IP” page reports. If they differ and your router shows something in the 100.64 range, that is carrier NAT.
Some ISPs will sell you a real public address. Before chasing that, consider not wanting it. An exposed service on a home connection collects automated scans and repeated login attempts from the moment it appears, and each one is something you now have to defend.
A mesh VPN solves the same problem without any of that. Tailscale, which is built on WireGuard, gives your phone an address on your home network from anywhere, nothing is published publicly, and the carrier NAT stops mattering. Done properly it means no forwarded ports at all, and every service in the flat stays reachable from a train. Plain WireGuard is the do-it-yourself version, but one end needs a reachable public address (a forwarded port at home, or a small VPS in the middle), so on its own it doesn’t get around carrier NAT. Setup for both is in my WireGuard VPN setup guide.
Not being able to forward ports is an inconvenience dressed as a security feature. Treat it as the nudge toward a VPN that it is.
VLANs: keeping the cheap smart plug away from your laptop
A VLAN splits one physical network into several logical ones that cannot talk to each other unless you allow it. The reason to care is simple. That budget smart bulb runs firmware nobody audits, phones home to a server you know nothing about, and sits on the same flat network as your laptop and file server. Segmentation means that if the bulb is compromised, the bulb is all that is compromised.
what you actually need for this
A router or firewall that understands VLANs and can filter between them, access points that can put a separate SSID onto a tagged VLAN, and a managed switch if you have more than a couple of wired ports. This is where ISP hardware runs out and you either buy your own, or take the simpler option below.
The simpler option covers most of the benefit for most flats: put every smart device on the router’s guest network with client isolation on. One checkbox, no new hardware, and untrusted gadgets are kept away from your computers. The cost is that your phone on the main network cannot reach them directly, which matters if you run local automation of the kind described in my cloud-free Home Assistant setup.
a three-segment plan that is enough
- Trusted: laptops, phones, the home server. Full access to everything, including the lab.
- Things: smart plugs, bulbs, cameras, the TV. Internet allowed, no access to trusted devices, and one narrow hole so the automation server can reach them.
- Guests: visitors. Internet only, isolated from both other segments and from each other.
If your server needs a presence on more than one segment, a tagged interface is cheaper than a second network card:
# netplan: one physical port, two networks
network:
version: 2
ethernets:
enp3s0:
dhcp4: true
vlans:
things:
id: 20
link: enp3s0
addresses:
- 192.168.20.10/24Start with two segments, not five. Every boundary is a rule you must remember when something stops working, and “why can the TV not see the media server” is a question you will ask at least once. Containers add their own networks on top, worth remembering if you run the stack from my Docker Compose home server guide — Docker bridges are a separate layer and do not inherit VLAN rules.
changing the network without a family incident
The technical work is the easy half. This is the part that decides whether you get a second attempt.
- Pick the time deliberately. Sunday morning, not Saturday night, with daylight left to undo a mistake.
- Record the current state: router address, DHCP range, DNS settings, existing reservations. A phone photo of each settings page is thirty seconds of work and the only rollback you will have.
- Keep one wired laptop plugged in with a known-good address, so you always have a way back into the router.
- Change one thing, then test from a phone that is not yours. Your own device caches DNS and hides problems.
- Keep the old Wi-Fi SSID until the new arrangement is proven. Renaming it means re-entering a password on every device, including the TV whose remote you hate.
- Tell the household before, not after. “The internet may blink for ten minutes around eleven” costs nothing and buys goodwill.
And set a rollback deadline. Not working after thirty minutes? Put the old settings back and try again next weekend. A home lab that makes the household’s internet unreliable does not survive contact with the household.
common mistakes
- Assigning a static address inside the router’s DHCP pool. Fine until the router hands the same address to a visiting phone.
- Running the household’s only DNS server on a machine you reboot for fun. When it is down, the internet looks broken to everyone.
- Editing network configuration over SSH with no console access and no rollback timer. Use
netplan try. - Building five VLANs before understanding two. Complexity you cannot debug at 11 PM is not security.
- Forgetting that the TV, speaker and printer rely on discovery traffic that does not cross segments. Plan for it or they vanish.
- Leaving the router’s admin password at the default. The network is the front door for everything else you build.
FAQ
do I need a managed switch to start a home lab?
No. A reservation for your server, local DNS names and the router’s guest network will carry you a long way on stock hardware. Buy a managed switch when you have a concrete need — tagged VLANs to a second access point, or more wired devices than ports. Buying it first tends to mean it sits in a box.
why can my laptop not reach the server after I changed the subnet?
Usually a cached lease or a stale DNS answer. Reconnect the Wi-Fi, then check with ip -brief address that you are on the network you think you are. If the address looks right and it still fails, confirm the gateway with ip route show default. That pair explains most of these, including the ones that present as a total outage and turn out to be one stale lease.
is a second router behind the ISP box a bad idea?
Common and workable, with one wrinkle: two layers of address translation make reaching devices across the boundary awkward. Put the ISP unit in bridge mode if it offers one. If not, hang your lab off your own router and accept that devices on the ISP side are effectively on a different network.
what breaks first during a power cut?
The router and the fibre unit, almost always, because nobody puts those on a battery. A server on a UPS with a dead router is a server nothing can reach. A small UPS powering the ONT, the router and one switch keeps the network alive through short cuts, and in my view that is the best first purchase on this list.
Do the two easy wins this week: reserve an address for your server and give it a local name. Leave VLANs for a Sunday morning when you have told everyone in advance.
Update history: switched local names to the reserved home.arpa suffix, replaced the dnsmasq file with Pi-hole v6’s own local-records setting, added a netplan file-order check, clarified that plain WireGuard needs a reachable address behind carrier NAT, and added Sources.
Sources
- OpenWrt documentation — VLAN configuration, DHCP and DNS options on router hardware you control.
- RFC 1918 — the private address ranges used for every example in this article.
- RFC 6598 — the shared address space that identifies a connection behind carrier-grade NAT.
- Netplan documentation — file structure and the order in which configuration files are merged.
- RFC 8375 — the home.arpa special-use domain for home networks.
- Pi-hole FTL configuration — local DNS records (dns.hosts) and the etc_dnsmasq_d switch.