You can DIY that these days though, plain Linux software stack, with optional hardware offload on some specific things and devices. Basically, you have a traffic distinguisher (VXLAN tunnel, MPLS label, SRv6, heck even GRE tunnel), keep a whole bunch of VRFs (man ip-vrf) around, and have your end services (server side) bind into appropriate VRFs as needed.
Also, yeah, with IPv6 you wouldn't have this problem. Regardless of whether it's GUAs or ULAs.
Also-also, you can do IPv6 on the server side until the NAT (which is in the same place as in the article), and have that NAT be a NAT64 with distinct IPv6 prefixes for each customer.
(ed.: To be fair, 1:1 NAT can be almost stateless too, that is if your server side ["Technician"] can be 1:1 mapped into the customer's network, i.e. the other direction. This only works if you have very few devices on "your" side and/or/according to how many IPs you can grab on the customer network.)
The IPv6/NAT64 approach meanwhile is very similar to what you did, it just gets rid of the need to allocate unique IP addresses to devices. The first 96 bits of the IPv6 address become a customer/site ID, the last 32 bit are the unmodified device IPv4 address.
There's more addresses I didn't know about offhand but found when looking up the 'no DHCP server' autoconf IP address range (Link Local IPv4).
Much easier to drop some router on site that is telco neutral and connect back to your telco neutral dc/hq.
May as well pick a single solution that works across all Internet connections and weird setups, be an expert in that, vs having to manage varying network approaches based on telco presence, local network equipment, operating country, etc.
(btw, have you actually read past the first 7 words? I'm much more interested what people think about the latter parts.)
Need to provide support access to 10k-50k locations all with the same subnet (industry standard equipment where the vendor mandates specific IP addressing, for better or worse). They are always feeding in data into the core too.
Much easier to just VPN+NAT.
Why do all those devices need to talk to each other btw? It's never specified. Is it a user need or a data collection/spyware need?
In a world where security articles make the news saying that you could obtain access to something IF the attacker already has local root and IF the moon is in a quarter phase and IF the attacker is physically present in the same room as the machine and this means the sky is falling...
... we should be questioning why disparate devices on unrelated home networks need to talk to each other.
https://en.wikipedia.org/wiki/List_of_IPv6_transition_mechan...
Coincidentally I think that's an overestimation on the number of devices that don't support IPv6. At this point, vendors have to go out of their way to disable IPv6, and they lose out on some government/enterprise tenders that require IPv6 even if they're not running it (yet).
> And that assumes a single NAT. Many sites have a security firewall behind the ISP modem, or a cellular modem in front of it. Double or triple NAT means configuring port forwarding on two or three devices in series, any of which can be reset or replaced independently.
Cheap ass ISP-managed routers. Got to be lucky for these rubbish bins to even somewhat reliably provide IPv6 connectivity to clients at all, or you run into bullshit like new /64's being assigned every 24 hours, or they may provide IPv6 but not provide any firewall control...
Nor can everyone control whether their connection supports v6, unfortunately.
I can't see my neighbors opening ports on their switch. What's a switch, to start with. And what happens when they change provider and switch next month?
It's much easier to tell them: I install two boxes. One is the camera (or whatever), the other one is necessary to make the camera work properly, keep it online, don't switch it off.
Stateful firewalls are very much a thing on v6. Many mobile ISPs don't allow incoming connections by default, for example.
Many CPEs (home routers) also come with a v6 firewall (I'd guess it's probably more common than not?), and not everybody has admin access to theirs.
The reachability problem is, even with public addresses, sometimes you have to do the same thing to "configure port forwarding" with stateful IPv6 firewalls as with double or triple NAT IPv4.
The only drawback are routes - they won't work on the same CIDR (I mean the fact that you can say in Tailscale "if you want to reach the 192.168.16.13 device that does not support Tailscale, go through this Tailscale gateway"). For this I had to shift my parents' network to be able to access stuff like the printer, in a network that clashed with another one of mine.
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.
One day somebody working days or nights "helpfully" plugged one of IT's loose office-machine-network cables into one of my little lab ethernet switches which had a vacant spot :\
With separate IP subnets it really kept the traffic from crossing, no damage was done, and nobody ever knew until a PC configured for DHCP was plugged into the lab network, and their router wanted to autoassign an IP address to it.
I kinda don't want to share this because:
A) it's a bad idea
B) it means it will be less unique
and
C) I got teased for it a long time ago by my other nerd friends.
But the US DOD has huge blocks of prefixes that it doesn't do anything with, presumably they use it for internal routing so every device they have could publicly route without NAT..
One of those prefixes is 7.0.0.0/8.
My home network uses that. I have never had an issue with S2S VPNs.
However, there have been a few bits of software (pfsense for example) which have RFC1918 hardcoded in some areas and treat it like a public network and overwriting it means doing the entire network setup manually without the helping hand of the system to build-out a working boilerplate.
Docker defaults to 172.16.0.0/16.
It was pretty easy to cause myself problems with Docker compose. Eventually I run out of subnets in the 172.16 range and it happily created subnets in the 192.168. range. Some of them overlapped with subnets on my LAN.
Plus, most network admins think of you and aren’t so bold as to use the first subnet in the range, so I never had problems yet :)
[1] Not IPv6 on mobile devices but a fully-owned IPv6 range that is supposed to be the address for a device regardless of where it is, see RFC 3775
Couldn't you tell the WG devices that 192.168.2.0/24 refers to the 192.168.1.0/24 network at customer A, such that 192.168.2.55 is routed to 192.168.1.55. Same for 192.168.3.0/24 referring to customer B.
I think this is what the article is getting at but I don't see the value in manually assigning an alias to each non-wg device, versus assigning an alias to the entire LAN.
eg this is what I'm currently using to alias my home network
# Rewrite 192.168.150.?? as 192.168.50.??
PreUp = iptables -t nat -A PREROUTING -d 192.168.150.0/24 -j NETMAP --to 192.168.50.0/24
PostDown = iptables -t nat -D PREROUTING -d 192.168.150.0/24 -j NETMAP --to 192.168.50.0/24
The best strategy might be to maintain the ability to easily reassign the network for a site. If every site is non-overlapping the problem does become trivial. I'd much rather fight a one time "reboot your machines tonight" battle than the ongoing misery of mapping things that do not want to be.
Then you as the client/app manager pull your hair out as the network team tells you everything is working fine.
172.16.0.0/12 block
This is used on virtual private clouds and is not publicly addressable.
since switching to this I have not had any collisions.
Writing PF or nft rules to NAT these hyper-legacy subnets on the local side of the layer3 tunnel is actually super trivial, like 20 seconds of effort to reason about and write in a config manifest.
Like written the article, a device on the customer site is required. At that point you might as well deploy a router that has a supportable software stack and where possible sober IP instead of legacy IP.
.
I have been running IPv6-only networks since 2005 and have been deploying IPv6-only networks since 2009. When I encountered a small implementation gap in my favorite BSD, I wrote and submitted a patch.
Anyone who complained about their favorite open source OS having an IPv6 implementation gap or was using proprietary software (and then also dumb enough to complain about it), should be ashamed of themselves for doing so on any forum with "hacker" in the name. But we all know they aren't ashamed of themselves because the competency crisis is very real and the coddle culture let's such disease fester.
There is no excuse to not deploy at minimum a dual-stack network if not an IPv6-only network. If you deploy an IPv4-only network you are incompetent, you are shitting up the internet for everyone else, and it would be better for all of humanity if you kept any and all enthusiasm you have for computers entirely to yourself (not a single utterance).
No? Over here at (South) East Asia we have been deploying IPv6 for nearly a decade now. The users are getting their IPv6 connectivity. Before someone jumps out and shouts SeCuRiTy: the firewall is enabled by default.
I am not saying the support is perfect. I know some people moan about lackluster IPv6 configuration in many routers. But for 90% of residential internet users (who care about pretty much nothing but the ability to watch YouTube and browsing social media), it damn sure is.