When Every Network is 192.168.1.x

IPv6 vs IPv4/VPN+NAT

  • Many argue IPv6 eliminates overlapping-subnet problems: every device can have a unique, globally routable address and you just run a VPN, no NAT.
  • Others counter that IPv6 mainly solves addressing, not reachability: stateful IPv6 firewalls, ISP policies, and lack of admin access often block inbound connections just like NAT.
  • Some note that IPv6 NAT and ULAs are already used in practice, re‑introducing “private” ranges and some of the same issues.
  • There’s sharp disagreement: one side insists IPv4‑only deployments are now inexcusable; the other points to messy reality in residential/small‑business networks.

Firewalls, NAT, and Hole Punching

  • Port forwarding with multi‑layer NAT is seen as fragile and hard to manage when you don’t control upstream gear.
  • Hole punching (as used by Tailscale, WebRTC, etc.) works surprisingly often, but fails on stricter enterprise firewalls and some home routers, and is complex to implement, especially for TCP.
  • Even with IPv6, opening firewall holes at remote customer sites can be politically or practically impossible.

Device, ISP, and “Human” Constraints

  • Cheap ISP routers and CPE often have poor or opaque IPv6 support, dynamic prefixes, or no firewall control for the customer.
  • Low‑end IoT gear (cameras, doorbells, NVRs) frequently lacks working IPv6, especially older hardware.
  • A recurring theme: the bottleneck is less technology and more “the squishy side” — customers who can’t or won’t reconfigure networks.

Overlay Solutions and Tools

  • The article’s pattern (WireGuard + CGNAT space + 1:1 NAT per device) is compared to:
    • Tailscale + MagicDNS for family/home servers.
    • SSH tunnel farms evolving into WireGuard‑based overlays.
    • Dedicated gateway boxes at each site that assign unique overlay IPs to non‑software devices.
  • These overlays are praised for being telco‑neutral and not requiring changes to existing LANs.

Address Space Choices and Alternatives

  • People share strategies for avoiding collisions: random 10.x.y, mid‑172.16/12 ranges, or even “naughty” public blocks (DoD /8s, TEST‑NET, 198.18/15).
  • Others describe using NETMAP/iptables to remap entire conflicting subnets, or more sophisticated VRF/L3VPN or IPv6+NAT64 schemes.
  • Consensus: every IPv4‑only scheme is a trade‑off; at scale, automation and operational simplicity matter more than the specific trick chosen.