Escaping the Hotel Subnet Trap: How Traveling Sporadically Broke My Wireguard VPN

We’ve all been there: you’re sitting in a hotel lobby, cafe, or airport terminal, hoping to get some work done. You connect to the public Wi-Fi, fire up your WireGuard VPN to tunnel back to your home lab, and… nothing. You can’t reach your home services - no Bitwarden, no Git repos, no Jellyfin, no RSS feeds, etc.

For the longest time, my home network was built on the classic consumer default: 192.168.0.*. It was simple, it worked, and I didn’t see a reason to change it. Until I started traveling enough to notice that some hotels had chosen the same range.

But doing a full network IP migration is a chore that you constantly put off—until you are forced to. In my case, my CenturyLink Fiber connection suddenly went offline. When I called to get it fixed, they informed me that they were retiring the legacy service and I was required to switch over to Quantum Fiber. To make matters worse, the soonest they could get a technician out to activate the new connection was a week away. 😱

With seven days of internet-free downtime, I had plenty of time to kill and no external access to worry about breaking. It was the perfect opportunity to wipe everything and overhaul of home network layout.

The Catalyst: The VPN IP Collisions

The underlying issue is simple but frustrating: default subnet overlaps.

When a public Wi-Fi network (like a hotel or coffee shop) and your home network both use 192.168.0.0/24 (or 192.168.1.0/24, or 10.0.0.0/24), your operating system’s routing table gets extremely confused.

When you establish a WireGuard connection, your client is configured to route traffic for your home subnet (192.168.0.0/24) through the WireGuard interface (wg0). But your physical Wi-Fi interface (wlan0) also thinks it is directly connected to 192.168.0.0/24 (the hotel gateway).

• Do you route packets to the local network to find the gateway to the internet?
• Or do you route them through the VPN tunnel to find your home server?

Usually, the local route wins, or routing conflicts make both paths fail. In my case, my local network was actually configured as 192.168.0.0/23 so its route was less specific than the hotel’s. Therefore traffic was routed to the local gateway instead of the wireguard interface.

The Solution: Re-numbering My Home Network

To fix this once and for all, I decided to migrate my entire home network away from standard consumer IP blocks. I chose a less common private subnet in the 10.0.0.0/8 range—specifically, using randomized middle octets (e.g., 10.151.0.0/16). Public networks almost never default to these, instantly curing my travel VPN headaches.

This meant I was going to re-IP every single device in my house touching:

• Revamp my UniFi network configurations
• Static IP configurations on servers (primarily my DHCP/DNS servers)
• DHCP reservations
• DNS host records and local reverse lookups

Subnets to Avoid in the 10.0.0.0/8 Range

While the 10.0.0.0/8 block gives you a massive sandbox of 16.7 million IP addresses, you shouldn’t just pick ranges at random. Several sub-blocks are commonly pre-empted by public networks, container engines, virtualizers, and VPN providers.

Here are some common 10.0.0.0/8 ranges you should avoid for your primary home subnets to prevent future routing clashes:

By choosing randomized middle octets (like my choice of 10.151.0.0/16 or 10.151.x.x), you steer clear of these default traps.

Designing a Scalable IP Layout: 10.[SITE].[VLAN].0/24

If you are going to go through the pain of re-numbering your entire network, you should consider doing it in a way that scales. I wanted a schema that would allow me to configure remote sites (like a second place, parent’s house, or cloud VPS) and VPN subnet ranges without ever worrying about overlapping subnets again.

I settled on a structured 10.[SITE].[VLAN].0/24 layout:

• Class A Foundation (10.0.0.0/8): Gives us a large space to partition.
• [SITE] (Second Octet): Unique ID for each physical or virtual location (e.g., 151 for Home, 152 for Remote Site 1, 153 for Remote Site 2, 159 for WireGuard VPN clients).
• [VLAN] (Third Octet): The VLAN ID or logical network segment (e.g., 10 for Server, 20 for Clients, 30 for IoT, 40 for Guest).

With this layout, an IP address instantly tells you its exact location and function. For example:

• 10.151.1.0/24 → Site 1 (Home), Default VLAN 1 (Default)
• 10.151.10.0/24 → Site 1 (Home), VLAN 10 (Server)
• 10.151.20.0/24 → Site 1 (Home), VLAN 20 (Clients)
• 10.151.30.0/24 → Site 1 (Home), VLAN 30 (IoT)
• 10.152.20.0/24 → Site 2 (Remote), VLAN 20 (Clients)
• 10.158.0.0/16 → Cloud VPS Site (158)
• 10.159.0.0/16 → VPN Site (159), WireGuard Clients

This structured scheme makes routing and firewall rules incredibly clean. For instance, if I set up a site-to-site VPN, I can route all of Site 2’s traffic back to Home by simply routing the 10.151.0.0/16 supernet, rather than writing individual rules for every single subnet.

Since I had to do all that heavy lifting anyway, I decided it was the perfect time to tackle another project I’d been putting off: revamping my home network VLANs for security and sanity.

In my next post, I’ll dive into the details of that VLAN revamp—including how inter-VLAN routing works, setting up wired hosts on multiple VLANs easily in Debian 13, and managing UniFi Wi-Fi network to VLAN mapping.