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.
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.
Nor can everyone control whether their connection supports v6, unfortunately.
I’ve also never seen it work for TCP in practice, and not everybody should have to roll their own UDP wrapper for their TCP-expecting application.
The complexity makes sense if you need to transport a lot of data peer-to-peer or the lowest possible latency, but if you don't, you might as well use that coordination server (which outbound-only clients are connecting to) for payload communication as well.
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...
It'd be nice if DNS servers supported this. Save the 64 host bits in the zone and just use whatever 64 prefix bits happen to be issued right now.
Otherwise it makes a strong case for the continued use of "private networks" and the IPv6 ULA mechanism.
Let's please not. Even without inbound reachability, hole punching is significantly easier given globally routeable addresses.
Yeah, that works, but everything gets much easier if your internal DNS can just support the varying prefix natively, e.g. via integration with the external-facing DHCP or PPPoE or whatever other address configuration protocol you use, since then you can reach everything both locally and globally by name.
It also gets more fragile. If your ISP can't or doesn't issue you a prefix for whatever reason then your entire IPv6 network stops working even internally. This is even more pertinent if, like me, you're on a 4G LTE connection. Verizon has great IPv6 support, when you can get it, and when you can't I'd still prefer to have a stable internal network.
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.
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.
There's also 198.18.0.0/15, Wikipedia says it's "Used for benchmark testing of inter-network communications between two separate subnets"[1]. Use this if you really want to thumb your nose at the RFC police.
[1] https://en.wikipedia.org/wiki/List_of_reserved_IP_addresses
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.
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.
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
Then you as the client/app manager pull your hair out as the network team tells you everything is working fine.
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).