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.
Much easier to drop some router on site that is telco neutral and connect back to your telco neutral dc/hq.
(btw, have you actually read past the first 7 words? I'm much more interested what people think about the latter parts.)
https://en.wikipedia.org/wiki/List_of_IPv6_transition_mechan...
> 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.
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.
Docker defaults to 172.16.0.0/16.
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 :)
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.