Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When Every Network is 192.168.1.x

netrinos.com

Post reply on HN
Print view View original

91–100 of 123 posts

Re: When Every Network is 192.168.1.x

#91

Post by bad_username »

perakojotgenije wrote: post #3

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.

Your website landing page is great. No stock photo hipsters drinking coffee, no corporate fluff amid whitespace wasteland. Just straight to the point. Rare sight today.

Re: When Every Network is 192.168.1.x

#93

Post by zinekeller »

greyface- wrote: post #77
ivanjermakov wrote: post #72

Earlier quoted context omitted.

I subtly remember that 10.x.y address space is widely used by CGNATs.

CGNATs should be using 100.64/10 instead of 10/8 to avoid this problem, but I don't doubt that there are significant deployments on 10/8 anyway.

The IETF really dragged their heels on CGNAT because they thought that IPv6 is easy™ (of course not, it's intentionally designed not to be "almost the same but wider" but include unworkable stuff like Mobile IPv6[1] which is just a fancy VPN) until they were forced to allocate 100.64.0.0/10 because some ISPs are not just using 10.0.0.0/8 but also US-DoD addresses (especially 11.0.0.0/8, because it's basically 10.0.0.0/7) as "private" addresses.

[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

Re: When Every Network is 192.168.1.x

#94

Post by pmontra »

bigstrat2003 wrote: post #8
lxgr wrote: post #4

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

Companies with an IT department, maybe. Companies without IT, not much. People, nope.

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.

Re: When Every Network is 192.168.1.x

#95

Post by eqvinox »

yardstick wrote: post #82
eqvinox wrote: post #44

Earlier quoted context omitted.

That's all true, but you can also, you know, like, talk to people without buying your whole solution from them :) (btw, have you actually read past the first 7 words? I'm much more interested what people think about the latter parts.)

On the later parts, VRF in my scenarios won’t scale. 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.

That is a valid point. Though I would probably check first what the scaling limits on VRFs actually are; there was some netdev work a while back to fix scaling with 100k to 1M devices (a VRF is a device, though also a bit more than that). It's only the server ("technician") that needs to have all of these (depends on the setup if that helps or not), intermediate devices just need to forward without looking at the tags, and the VPN entry point only cares about its own subset of customers.

I'd probably use the IPv6 + NAT64 setup in your situation.

Re: When Every Network is 192.168.1.x

#96

Post by eqvinox »

mjevans wrote: post #78
eqvinox wrote: post #69

Earlier quoted context omitted.

The key distinction with a L3VPN setup is that the packets are unmodified from and including the IP layer upwards, they're just encapsulated/labelled/tagged (depending on your choice of distinguisher). That encapsulation/… is a stateless operation, but comes at the cost of MTU (which in your case should be a controllable factor since the inner flows don't really hit uncontrolled devices.) Depending on what you're try…

10. is /8 (24 payload bits), 172.16 is /12 (so 22) and 192.168 is /16. Very little need to spend more than 18 bits of space to map every 'usable' private IPv4 address once per customer. Probably also less than 14 bits (16k) of customers to service. 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). https://en.wikipedia.org/wik…

That's all true on a statement level, but doesn't make an IPv4:IPv4 NAT solution better than either VRF/encap or IPv6 mapping.

The benefit with VRF/encap is that the IPv4 packets are unmodified.

The benefit with IPv6 mapping is that you don't need to manage IPv4:IPv4 tables and have a clear boundary of concerns & zoning.

In both cases you don't give a rat's ass which prefixes the customer uses. That math/estimation you're doing there… just entirely not needed.

Re: When Every Network is 192.168.1.x

#97

Post by eqvinox »

wmf wrote: post #84
zokier wrote: post #32

Earlier quoted context omitted.

The solution is to run ipv6 on the overlay and have the customer site gateway thing they have to translate it to target ipv4. Conveniently you can do the translation it more or less statefully and very easily because you can just embed the ipv4 addr in ipv6. For example you could grab a /64 prefix, assign 32 bits to customer/gateway id and other 32 bits to target ipv4 addr.

Basically Teredo.

Basically NAT64. (Teredo requires the IPv4 hosts to have awareness of it, this doesn't.)

Re: When Every Network is 192.168.1.x

#98

Post by trollbridge »

OptionOfT wrote: post #52
trollbridge wrote: post #34

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.

Yes, we use Docker (or podman) but generally never rely on Docker’s internal address ranges.

Re: When Every Network is 192.168.1.x

#99

Post by direwolf20 »

lxgr wrote: post #28
digiown wrote: post #19

Earlier quoted context omitted.

Hole punching is a thing. Ports are not normally completely blocked. They allow replies, which can be exploited to do make a connection. Obviously this requires an out of band signaling mechanism. Tailscale does this, so does WebRTC, iirc. See: https://tailscale.com/blog/how-nat-traversal-works

Yes, but I don't believe all firewalls support that, especially for TCP, and as you've mentioned, now you also need to maintain a handshaking mechanism. 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.

Firewalls don't track connections as carefully as you might think. They don't delete the mapping when an RST is received, so you can keep using it and receive a SYN in the other direction and now you have a connection.
Post reply on HN