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

41–50 of 123 posts

Re: When Every Network is 192.168.1.x

#41

Post by dmd »

trollbridge wrote: post #34
rtkwe wrote: 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.

My (very large) corporate network uses 172.16 and 10. heavily, which has lead me to set my docker/daemon.json default-address-pools to 84.54.64.0/18, as it's very unlikely we need to communicate with any IPs in Uzbekistan.

Re: When Every Network is 192.168.1.x

#42

Post by notpushkin »

EvanAnderson wrote: post #37
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.

I find a lot of Docker containers using subnets inside 172.16.0.0/16.

Probably for the same reason – 172.16/12 is not as widely used for other networks :-)

Re: When Every Network is 192.168.1.x

#43

Post by themafia »

lxgr wrote: post #39
themafia wrote: post #35

Earlier quoted context omitted.

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.

Ah, you mean for cases where you want both stable addresses (even if only internal) and globally reachable ones (even if non-constant)? 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…

> but everything gets much easier

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.

Re: When Every Network is 192.168.1.x

#44

Post by eqvinox »

yardstick wrote: post #40
eqvinox wrote: 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…

The problem with talking to a telco, is you have to talk with not just one but any your customer may use. And if at the customer location there’s multiple routers in between the cameras and that telco router, it’s a shitshow trying to configure anything. Much easier to drop some router on site that is telco neutral and connect back to your telco neutral dc/hq.

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

Re: When Every Network is 192.168.1.x

#45

Post by dijit »

dmd wrote: post #41
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.

My (very large) corporate network uses 172.16 and 10. heavily, which has lead me to set my docker/daemon.json default-address-pools to 84.54.64.0/18, as it's very unlikely we need to communicate with any IPs in Uzbekistan.

So, uh.

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.

Re: When Every Network is 192.168.1.x

#46

Post by eqvinox »

reactordev wrote: post #27
duskwuff wrote: post #18

Earlier quoted context omitted.

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.

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

Re: When Every Network is 192.168.1.x

#47

Post by x0 »

dijit wrote: post #45
dmd wrote: post #41

Earlier quoted context omitted.

My (very large) corporate network uses 172.16 and 10. heavily, which has lead me to set my docker/daemon.json default-address-pools to 84.54.64.0/18, as it's very unlikely we need to communicate with any IPs in Uzbekistan.

So, uh. 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…

In this vein there's also 3 TEST-NETs, all /24 but still useful. I've been known to use TEST-NET 1 for Wireguard: 192.0.2.0/24. The other two are 198.51.100.0/24 and 203.0.113.0/24.

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

Re: When Every Network is 192.168.1.x

#48

Post by pcarroll »

dijit wrote: post #45
dmd wrote: post #41

Earlier quoted context omitted.

My (very large) corporate network uses 172.16 and 10. heavily, which has lead me to set my docker/daemon.json default-address-pools to 84.54.64.0/18, as it's very unlikely we need to communicate with any IPs in Uzbekistan.

So, uh. 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…

I actually looked at using those before the CGNAT range, but many of those blocks have been returned to the public Internet.

Re: When Every Network is 192.168.1.x

#49

Post by pcarroll »

dgrin91 wrote: post #5

This is basically what I use tailscale & their magicdns feature for. I manage a few locally hosted jellyfin servers for myself and some family members, and its the same problem. I just added tailscale to them all and now I can basically do ssh parents.jellyfin.ts.net or inlaws.jellyfin.ts.net

How do you handle embedded devices that cannot install software?

Re: When Every Network is 192.168.1.x

#50

Post by pcarroll »

solaris2007 wrote: post #23

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

Support for IPv6 is notoriously bad in residential modems. They can barely run IPv4. In an enterprise, you can do it properly. But here we are stuck with the junk the ISP gave out. Customers don't care. You have to work with what you've got.
Post reply on HN