Stop using 192.168.1.0/24: A Contrarian Guide to Home Network Addressing

If you’re a contractor, consultant, or anyone who VPNs into multiple client networks, you’ve experienced the pain. You connect to a Client’s VPN, and suddenly you can’t print to your local printer. Or worse, you’re trying to hit 10.1.1.50 on the client network, but your traffic is going to your own NAS instead. Split tunneling helps, but it’s not always an option, and sometimes it just makes things worse.

The problem is simple: everyone uses the same IP space. And I mean everyone.

The Unholy Trinity of Home Networking

Let’s be honest about what 90% of home and small business networks look like:

• 192.168.1.0/24 - The SOHO default. Every Netgear, Linksys, and TP-Link ships with this.
• 192.168.0.0/24 - The “I’m slightly different” crowd.
• 10.0.0.0/24 - The “I read a blog post once” enthusiasts.

Enterprise networks aren’t much better. In my experience, most fall into predictable patterns:

• 10.0.0.0/8 carved into /16s or /24s
• 172.16.0.0/12 for “special” segments
• 192.168.x.0/24 for branch offices that were “temporary” 15 years ago

When you’re a contractor connecting to 5, 10, or 20 different client networks per month, you will hit conflicts. It’s not a matter of if, it’s when.

The Nuclear Option: Use Different Space

Here’s my controversial take: stop using RFC 1918 space at home entirely.

“But those are the designated private ranges!”… Yep. And that’s exactly the problem. Everyone uses them, which means everyone conflicts with each other.

Instead, consider these alternatives… each with it’s own tradeoffs.

Option 1: RFC 2544 Benchmarking Space (198.18.0.0/15)

This is my personal favorite. RFC 2544 reserves 198.18.0.0 through 198.19.255.255 for “benchmarking purposes”, testing network devices, and detecting PMTU issues. In practice:

• Nobody routes it on the public internet - It’s filtered by every reasonable ISP
• Almost no enterprise uses it internally - IT departments stick to RFC 1918 like gospel (or sometimes other random public networks)
• It’s a /15 - That’s 131,072 addresses, plenty for even the most ambitious home lab
• Your ISP will never assign it to you - It’s permanently reserved

I’m planning to migrate my home network to 198.19.x.x space. My UniFi gear won’t care. My Palo Alto home lab won’t care. DHCP works. DNS works. NAT works. See the Implementation Notes for my full addressing scheme.

The Downsides:

• Benchmarking tool conflicts. If you actually use iperf, RFC 2544 test suites, or network performance testing tools, some of them use this space by default. You’d be testing against your own LAN. Easily worked around by reconfiguring the tools, but worth knowing.

• Overzealous security tools. Some IDS/IPS systems, endpoint protection, or corporate security agents may flag traffic to/from this range as suspicious or block it outright. I haven’t hit this personally, but I’ve heard reports.

• “That’s not what it’s for” pedants. If you ever share your network config publicly or have someone else admin your network, be prepared for the “well, actually” crowd. They’re not wrong, but they’re also not helping.

• Limited size. At 131k addresses, it’s smaller than the RFC 1918 ranges. Not a real issue for home use, but if you’re running a massive lab with dozens of VLANs, you might feel constrained.

Best for: Contractors, consultants, and MSP engineers who VPN into many client networks and want near-guaranteed conflict avoidance.

Option 2: RFC 6598 CGNAT Space (100.64.0.0/10)

RFC 6598 carved out 100.64.0.0 through 100.127.255.255 for Carrier Grade NAT, the extra layer of NAT that ISPs use when they’ve run out of public IPv4 addresses. This gives you over 4 million addresses in a range that almost no enterprise uses internally.

The Upside:

• Massive address space. A /10 is enormous, 4,194,304 addresses. You could run a small datacenter in here.
• Enterprise rarely uses it. Traditional corporate IT sticks to RFC 1918 religiously. The odds of a client network using 100.64.x.x internally are very low.
• Well-defined “not public” status. ISPs are required to filter this at their borders, so it won’t leak to the internet.

The Downsides:

• ISPs actually use this. This is the big one. If your home internet connection is behind CGNAT, and many are, your ISP is already using this space between your router and their NAT gateway. You’d be creating conflicts on your WAN side, not your LAN side. This includes:

  • Starlink
  • T-Mobile Home Internet / 5G Home
  • Many mobile hotspots
  • Some cable ISPs in congested markets
  • Most cellular tethering

  If you’re on traditional cable/fiber with a real public IP, you’re probably fine. But check first: if your WAN IP starts with 100.64-100.127, do not use this space.

• Growing enterprise adoption. As IPv4 exhaustion bites harder, some large enterprises are starting to use CGNAT space internally as “extra private space.” It’s still rare, but the trend is upward. In 5 years, this might be as crowded as RFC 1918.

• VPN clients may block it. Some corporate VPN clients explicitly include 100.64.0.0/10 in their “protected” ranges, assuming it’s ISP infrastructure. You might find your home network unreachable while connected.

• Confusing troubleshooting. When something breaks, “is this my CGNAT or my ISP’s CGNAT?” is not a fun question to debug at 11 PM.

Best for: Users with traditional ISP connections (real public IP) who want maximum address space and are confident their clients don’t use CGNAT space internally.

Option 3: RFC 5737 Documentation Space (TEST-NETs)

RFC 5737 reserves three /24 blocks explicitly for documentation and examples:

• 192.0.2.0/24 (TEST-NET-1)
• 198.51.100.0/24 (TEST-NET-2)
• 203.0.113.0/24 (TEST-NET-3)

These are the IP equivalents of “example.com”, reserved forever, never to be routed, safe to use in any documentation without risk of hitting real infrastructure.

The Upside:

• Absolutely zero chance of internet routing. These are as “reserved” as it gets.
• Nobody uses them for production. They’re explicitly for examples only.
• Multiple non-contiguous blocks. If you’re paranoid about single-block conflicts, you could spread across all three.

The Downsides:

• Tiny. You get 254 usable hosts per block, 762 total. If you have a home lab with multiple VLANs, IoT devices, and DHCP pools, you’ll run out fast.

• Documentation collision. This is the ironic one. Anyone who actually follows RFC examples in their configs might use these blocks. Training labs, vendor documentation, certification study guides, they all use TEST-NET addresses. If your client’s network team learned from the same Cisco Press book, you might still conflict.

• Feels wrong. Using documentation space for production (even home production) violates the spirit of the RFC more directly than the others. It’s like using example.com as your real domain because “nobody else will.”

• Split across three blocks. If you need more than 254 hosts in a single broadcast domain, you’re out of luck. You can’t combine them into a larger subnet.

Best for: Minimalist home networks with few devices and a high tolerance for irony.

Option 4: Class E Space (240.0.0.0/4) - The Chaotic Evil Choice

Here’s where we go off the deep end. Class E (240.0.0.0 through 255.255.255.254) was reserved “for future use” back in 1981 and has been sitting unused ever since. That’s 268 million addresses gathering dust.

In theory, you could use this space. In practice…

The Downsides (there are no real upsides):

• Operating system rejection. Many OS network stacks treat 240.0.0.0/4 as invalid and will refuse to assign or route these addresses. Linux has gotten better about this in recent kernels, but Windows has historically been problematic, and macOS behavior varies.

• Hardware filtering. Older routers, switches, and firewalls may silently drop Class E traffic as “invalid” or “martian.” Your carefully configured home network might just… not work.

• Software assumptions. Applications, libraries, and network tools often hardcode “240.0.0.0/4 = invalid” because that’s what they were taught. Expect random breakage.

• Future conflicts. If IANA ever does allocate Class E space (there have been proposals), you’d need to renumber. Unlikely at this point, but not impossible.

• Zero community support. When something breaks, you’re on your own. “I’m using Class E and my network doesn’t work” is a support request that will get you laughed out of most forums.

Best for: People who enjoy suffering and have a deep need to be contrarian.

What About Multicast Space (224.0.0.0/4)?

I knew you would ask about this. No. You cannot use multicast addresses (224.0.0.0 - 239.255.255.255) for unicast host addressing. These are fundamentally different at the protocol level… your NIC, your OS, your switches, everything treats multicast traffic differently. You cannot assign 224.0.0.50 to your NAS. It won’t work. Don’t try it.

“But This Is Wrong!”

Yes, technically, using any of these ranges for your home LAN violates the spirit of their respective RFCs. The benchmarking space was reserved for benchmarking. CGNAT space was reserved for carriers. Documentation space was reserved for documentation.

But let’s be pragmatic:

1. You’re not hurting anyone. This traffic never leaves your network (it NATs to your public IP like any other private space).

2. The alternative is worse. Constantly fighting routing conflicts, remembering which client uses which space, or maintaining complex policy-based routing just to print a document is not a good use of anyone’s time.

3. RFCs are guidelines, not laws. The IETF police aren’t going to kick down your door. The space is reserved specifically because it won’t be routed publicly, which is exactly the property you need for private addressing.

4. You’re probably already violating RFCs. Using 1.1.1.1 for testing before Cloudflare owned it? Running a recursive resolver on a non-standard port? Hosting services on residential connections against your ISP’s ToS? Glass houses, friends.

My Recommendation

For most contractors and multi-VPN users, RFC 2544 space (198.18.0.0/15) is the sweet spot. It’s large enough for any reasonable home network, universally non-routed, and virtually unused by enterprises. The downsides are minor and easily managed.

If you’re on a traditional ISP with a real public IP and want more address space, CGNAT space (100.64.0.0/10) is a viable alternative, but verify your WAN IP first and accept the risk that it may become more crowded over time.

Avoid TEST-NET space unless you have very few devices and enjoy the irony. Avoid Class E entirely unless you’re writing a blog post about it.

Implementation Notes

If you’re convinced, here’s how to actually do this:

Pick your addressing scheme. I keep it dead simple with one rule:

Third octet < 100 = TRUSTED Third octet ≥ 100 = UNTRUSTED

When you’re scanning firewall logs at 2 AM, you can instantly tell what zone traffic is coming from without looking anything up. No CIDR math required, just glance at the third octet.

I went with 198.19.x.x rather than 198.18.x.x to stay clear of any benchmarking tool defaults that might ship with 198.18.0.0/24 hardcoded.

Trusted Zone(s) - 198.19.64.0/19

Core Infrastructure

Docker MACVLAN Networks

Lab Environment

Untrusted Zones - 198.19.X.0 where x ≥ 100

IoT & Guest

DMZ

For DHCP, I’m currently running a dual Pi-hole setup with active/active DHCP, clients just grab a lease from whichever responds first. This gives me DNS redundancy without the complexity of keepalived or failover scripts. Clients might flip between Pi-holes on lease renewal, but who cares? They both resolve the same way.

The MACVLAN networks let Docker containers have their own IPs on the physical network-great for services like Pi-hole, Home Assistant, or anything that needs to appear as a “real” device for discovery protocols.

The IoT VLAN is firewalled off from the trusted network but has internet access. To keep device discovery working (Chromecast, Sonos, HomeKit, etc.), I run mDNS reflection in UniFi between the trusted and IoT VLANs. It’s not perfect… some SSDP/UPnP stuff still breaks, but it handles 90% of the “why can’t I see my TV” complaints.

Update your router/firewall. Change your LAN interface IP and DHCP scope. Most prosumer and enterprise gear handles this without complaint.

Update static assignments. Your NAS, printer, Proxmox host, etc. need new IPs.

Update DNS. If you’re running local DNS (and you should be), update your records.

Update firewall rules. Any rules referencing RFC 1918 space need updating. On Palo Alto, update your “private-networks” address group if you’ve customized it.

Test your VPNs. Connect to each client and verify you can reach both their resources and your local network simultaneously (assuming split tunnel or appropriate routing).

The whole migration took me about two hours, most of which was updating static IPs and waiting for DHCP leases to renew.

The Results

After switching to 198.19.x.x:

• Zero VPN conflicts with any network
• Split tunneling actually works without routing table gymnastics
• Local resources always accessible regardless of VPN state
• No issues with any software or hardware, everything treats it as private space for NAT purposes
• Smug satisfaction when other contractors complain about IP conflicts

Should You Actually Do This?

If you’re a home user who connects to one corporate VPN occasionally, probably not. Just pick a weird RFC 1918 subnet like 10.173.42.0/24 and call it a day.

But if you’re a contractor, MSP engineer, consultant, or anyone who regularly connects to multiple unfamiliar networks? Seriously consider it. The minor “RFC violation” is vastly outweighed by the operational simplicity.

Your home network is your network. Use whatever addressing makes your life easier.

Disclaimer: I’m a network engineer, not a lawyer or IETF representative. This post reflects my personal experience and opinions. If using non-standard address space for your home LAN somehow causes problems, that’s on you. But it probably won’t.

What do you think? Anyone else using non-standard address space at home? Hit me up on social media or drop a comment below. I’d love to hear about your setup.