> But the moment two sites share the same address range, you have an ambiguity that IP routing cannot resolve. 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 r…
I don't have enough time for that.
When Every Network is 192.168.1.x
31–40 of 123 posts
Re: When Every Network is 192.168.1.x
#32Why not IPv6? Pretending that it doesn't exist?? https://en.wikipedia.org/wiki/List_of_IPv6_transition_mechan...
I wouldn't be surprised if a lot of the hardware under management (e.g. IP cameras, NVRs, cable modems) lacks support for IPv6, and/or the customer networks that it's resident on don't have working IPv6 transit.
Re: When Every Network is 192.168.1.x
#33Earlier quoted context omitted.
IPv6 solves the addressing problem, not the reachability problem. Good luck opening ports in the stateful IPv6 firewalls in the scenarios outlined in TFA: > 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 independen…
I'm not really seeing a reason why it would be impossible to open firewalls in that scenario. More work, sure, but by no means impossible. In any case TFA says right up front that it is trying to solve the problem of overlapping subnets, which IPv6 solves nicely.
Re: When Every Network is 192.168.1.x
#34I recently just changed my default subnet to 10.X.Y.... rolling two random numbers to make it highly unlikely my home subnet through wireguard would conflict with the subnet where I am connecting from.
Re: When Every Network is 192.168.1.x
#35Earlier quoted context omitted.
> or you run into bullshit like new /64's being assigned every 24 hours 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.
> 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.
Re: When Every Network is 192.168.1.x
#36Re: When Every Network is 192.168.1.x
#37I recently just changed my default subnet to 10.X.Y.... rolling two random numbers to make it highly unlikely my home subnet through wireguard would conflict with the subnet where I am connecting from.
I just use /24s in the lower-middle range of 172.16. Very unlikely to have a conflict there.
Re: When Every Network is 192.168.1.x
#38I recently just changed my default subnet to 10.X.Y.... rolling two random numbers to make it highly unlikely my home subnet through wireguard would conflict with the subnet where I am connecting from.
I just use /24s in the lower-middle range of 172.16. Very unlikely to have a conflict there.
Re: When Every Network is 192.168.1.x
#39Earlier quoted context omitted.
> 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.
You can have /both/ a ULA and a Globally Routable address. In practice it works just fine. My internal DNS points to the ULA for internal connectivity and my hosts use their global addresses for external connectivity.
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.
Re: When Every Network is 192.168.1.x
#40They clearly haven't talked to a telco or network device vendor, they would've sold them a VRF/EVPN/L3VPN based solution… for a whole bunch of money :) 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-v…
Much easier to drop some router on site that is telco neutral and connect back to your telco neutral dc/hq.