Live data from Hacker News

When Every Network is 192.168.1.x

netrinos.com

51–60 of 123 posts

Re: When Every Network is 192.168.1.x

#51

Shameless plug - this is exactly the same problem that our team had when we had to maintain a bunch of our customer's servers. All of the subnets were same, and we had to jump through hoops just to access those servers - vpns, port forwarding, dynamic dns with vnc - we've tried it all. That is why we developed https://sshreach.me/ - now it's a click of a button.

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...

Re: When Every Network is 192.168.1.x

#52
post #17

I 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.

Do you run Docker? Because I remember having to VPN out to a client that used that range, and it caused conflicts where our docker containers couldn't reach the client side to fetch data.

Docker defaults to 172.16.0.0/16.

Re: When Every Network is 192.168.1.x

#53
post #24

They 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…

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.

Re: When Every Network is 192.168.1.x

#54
post #46

Earlier quoted context omitted.

It’s definitely on the software side… The human side.

The squishy side. 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).

Right, IPv6 is baked into the NIC, so it’s up to developers to use it.

Re: When Every Network is 192.168.1.x

#55
post #17

I 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.

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.

Re: When Every Network is 192.168.1.x

#56
> The gateway device performs 1:1 NAT. Traffic arriving for 100.97.14.3 is destination-translated to 192.168.1.100, and the source is masqueraded to the gateway's own LAN address.

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.

Re: When Every Network is 192.168.1.x

#57

Earlier quoted context omitted.

I just use /24s in the lower-middle range of 172.16. Very unlikely to have a conflict there.

Do you run Docker? Because I remember having to VPN out to a client that used that range, and it caused conflicts where our docker containers couldn't reach the client side to fetch data. Docker defaults to 172.16.0.0/16.

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.

Re: When Every Network is 192.168.1.x

#58

Why not IPv6? Pretending that it doesn't exist?? https://en.wikipedia.org/wiki/List_of_IPv6_transition_mechan...

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.

Re: When Every Network is 192.168.1.x

#59

Earlier quoted context omitted.

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.

Then you've probably never worked in any serious networked embedded systems space. Getting people to open ports on the firewall and making the firewall configuration palatable to the end customer is like a quarter of what I think about when my team makes new features.

Yes! Exactly this.

Re: When Every Network is 192.168.1.x

#60
post #10

Earlier quoted context omitted.

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.

It's completely impossible if you simply don't have the necessary access. Not everybody can administer all firewalls upstream from them. Nor can everyone control whether their connection supports v6, unfortunately.

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.
Post reply on HN