We did. It's called IPv6. It's 20 years old and still not usable universally. At the high end, like enterprise or telcos, it's fantastic. But at the grass roots level of residential and small businesses, it's still a nightmare.
The need is real. You are a service provider. You need to manage equipment at customer sites. You need to access them simultaneously. But all the customers are using the same subnet...
If Bell gave out cellphones with the same phone number, how can you call anybody? But they still do.
Many devices have cloud access, but every manufacturer is different. It is a nightmare at scale.
That does not happen here. The CGNAT addresses are in the VPN tunnel. And the tunnel connects private devices end-to-end. The LAN packets never see the Internet. They are inside the WireGuard packets.
The problem there is you still need to keep track of the subnets. It works for a while, but it's quite complex. NAT is actually easier when you get into hundreds of sites.
The way we did it, roting is not a problem. Any Netrinos client (Windows, Mac, or Linux, including the free version) can act as a gateway. It assigns a unique overlay IP to devices on the local network that can't run software themselves, like cameras, NAS units, or printers, and handles the NAT translation.
Think of it like a router's DMZ feature, but inverted. Instead of exposing one device to the internet, each device gets a private address that's only reachable inside your mesh network.
Hole punching actually works most of the time. A lot more often than you might think. But enterprise firewalls usually don't allow it. And some home routers fail when you check all the anti-intrusion options. But it's the same for other VPNs.
In the residential and small-business space, it's pretty rare. You might need to point it out to the network guy. If the customer wants the service, they should be open to it.
IPv6 is very badly supported at the low end of the market. Cheap webcams, doorbells, etc. And that not counting already old equipment...
If we had a nuclear war, we could start over. But for now, we are stuck. Blame it on Cisco for inventing NAT.
We chose Go as the development language. Go produces statically compiled binaries that include all dependencies. The only external deps are wireguard, nftables, nmap, etc. All easy stuff. So we have no need for Docker. We publish binaries for ARM64 and AMD64. Avoiding Docker has made it much easier to work with.
This works fine for your end. But the issue we are addressing is on the other end, when you don't control the network and need to reach devices. If all customer sites are running rfc-unroutable blocks, you eventually encounter conflicts. And the conflict will likely be with the 2nd one you try.
I like to think this is what we did. It's a simple Linux software stack - Linux, nftables, WireGuard, Go... But the goal was also to make it automatic and easy to use. It's not for my Mom. But you don't need a CCNP either.
The trick is in the automation and not the stack itself.
The initial idea started as a bunch of ssh tunnels. Been doing that for years. But WireGuard seemed a better solution at scale, and more efficient. When I first saw WiteGuard, it blew my mind how elegantly simple it was. I always hated VPNs. Now I seem to have made them my life...
Support for IPv6 is notoriously bad in residential modems. They can barely run IPv4. In an enterprise, you can do it properly. But here we are stuck with the junk the ISP gave out. Customers don't care. You have to work with what you've got.
How overlay addressing and 1:1 NAT solve the conflicting subnet problem across hundreds of sites. A technical walkthrough with WireGuard.
https://netrinos.com/blog/conflicting-subnets
We implement STUN and TURN functionality natively in WireGuard rather than using separate protocols.
Netrinos uses a central rendezvous server that participates in WireGuard handshakes solely to collect your devices' public endpoints and share that information with your other devices. When a device roams to a new location, the server learns the new endpoint and updates the other devices in your account.
When direct P2P fails, Netrinos connections fall back to a relay server. The relay is a WireGuard peer, but it can only relay traffic between peers in your account. All customer accounts are strictly firewalled from each other.
If you want more control, you can enable a device in your account as a relay server with a checkbox in the app. This could be a home PC with a stable connection or a low-cost cloud server.