When Every Network is 192.168.1.x

Original Article ↗ Hacker News Discussion ↗

Overlapping private IPv4 address ranges like 192.168.1.x make it hard to reach devices across multiple customer networks, especially over VPNs and site‑to‑site links. Commenters compare workarounds such as WireGuard-based overlays, 1:1 NAT, subnet remapping, and VRF/L3VPN-style isolation, and note that tools like Tailscale or custom gateways can hide much of this complexity. IPv6 is often cited as the clean architectural fix, but inconsistent support in residential gear, ISP policies, stateful firewalls, and human/operational constraints mean many operators still rely on IPv4 plus NAT-based overlays in practice.

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.