[HN Gopher] When Every Network is 192.168.1.x
___________________________________________________________________
When Every Network is 192.168.1.x
Author : pcarroll
Score : 53 points
Date : 2026-01-28 14:06 UTC (8 hours ago)
(HTM) web link (netrinos.com)
(TXT) w3m dump (netrinos.com)
| 1970-01-01 wrote:
| Why not IPv6? Pretending that it doesn't exist??
|
| https://en.wikipedia.org/wiki/List_of_IPv6_transition_mechan...
| lxgr wrote:
| 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 independently.
| 1970-01-01 wrote:
| With IPv6 you don't forward ports at all. The device already
| has a public address.
| jlokier wrote:
| That's the addressing problem, although I have some bad
| news on that: NAT is used with IPv6 in some places.
|
| The reachability problem is, even with public addresses,
| sometimes you have to do the same thing to "configure port
| forwarding" with stateful IPv6 firewalls as with double or
| triple NAT IPv4.
| lxgr wrote:
| That's why I said "open ports", not "forward ports".
|
| Stateful firewalls are very much a thing on v6. Many mobile
| ISPs don't allow incoming connections by default, for
| example.
|
| Many CPEs (home routers) also come with a v6 firewall (I'd
| guess it's probably more common than not?), and not
| everybody has admin access to theirs.
| bigstrat2003 wrote:
| 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.
| lxgr wrote:
| 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.
| digiown wrote:
| 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
| lxgr wrote:
| 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.
| pcarroll wrote:
| 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.
| lxgr wrote:
| The problem isn't that it doesn't work (and it does often
| not work - one "symmetric NAT" in the old/deprecated
| terminology is enough), it's that it's orders of
| magnitude more complex than it needs to be.
|
| I've also never seen it work for TCP in practice, and not
| everybody should have to roll their own UDP wrapper for
| their TCP-expecting application.
| mschuster91 wrote:
| > I'm not really seeing a reason why it would be impossible
| to open firewalls in that scenario.
|
| Cheap ass ISP-managed routers. Got to be lucky for these
| rubbish bins to even somewhat reliably provide IPv6
| connectivity to clients at all, or you run into bullshit
| like new /64's being assigned every 24 hours, or they may
| provide IPv6 but not provide any firewall control...
| themafia wrote:
| > 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.
| lxgr wrote:
| > 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.
| themafia wrote:
| 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.
| lxgr wrote:
| 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 and globally by name.
| themafia wrote:
| > 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.
| throwway120385 wrote:
| 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.
| pcarroll wrote:
| Yes! Exactly this.
| zamadatix wrote:
| The article's proposed solution for IPv4 is a combination of
| VPN+NAT. The solution in IPv6 can be just VPN, sans NAT.
| duskwuff wrote:
| 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.
| reactordev wrote:
| It's definitely on the software side... The human side.
| eqvinox wrote:
| 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).
| reactordev wrote:
| Right, IPv6 is baked into the NIC, so it's up to
| developers to use it.
| zokier wrote:
| 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.
| pcarroll wrote:
| 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.
| perakojotgenije wrote:
| 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.
| pcarroll wrote:
| 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...
| dgrin91 wrote:
| 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
| nxobject wrote:
| In your experience, how often does Tailscale have to resort to
| an external relay server to traverse? I've had that out the
| kibosh on bandwidth/latency sensitive applications before.
| BrandoElFollito wrote:
| I was about to say that. This is what I do too.
|
| 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.
| pcarroll wrote:
| The way we did it, roting is not a problem. Any Netrinos
| client (Windows, Mac, or Linux, including the free version)
| can act as a gateway. It assigns a unique overlay IP to
| devices on the local network that can't run software
| themselves, like cameras, NAS units, or printers, and handles
| the NAT translation.
|
| 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.
| venusenvy47 wrote:
| I need to implement this type of thing for supporting networks
| of family members, but without the media server aspect - just
| computer/networking support. I'm looking for a cheap and
| reliable device that I can put in each home, to give the
| Tailscale "foothold". Do you happen to know of any tiny
| devices? I was thinking there must be something even cheaper
| than a Raspberry Pi to perform this single function at each
| location.
| Atotalnoob wrote:
| Use a pi zero it's like $5
| digiown wrote:
| An old micro pc from dell/hp/lenovo. They are often cheaper
| and more capable than Raspberry Pis. You can just put up a
| random Linux distro and it will work.
| LTL_FTC wrote:
| If they have an Apple TV, you can just install the app and
| use it as an exit node. I would check out the devices that
| are on their network currently, chances are you can use one
| of those.
| pcarroll wrote:
| How do you handle embedded devices that cannot install
| software?
| pixl97 wrote:
| One step beyond this is the multi-subnetted network on each side.
| You get the DNAT working, but then suddenly the app gets more
| complex over time and suddenly you're calling 192.168.2.x, which
| leads to async routes. Some traffic works, some traffic works one
| way, and other traffic disappears.
|
| Then you as the client/app manager pull your hair out as the
| network team tells you everything is working fine.
| rtkwe wrote:
| 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.
| trollbridge wrote:
| I just use /24s in the lower-middle range of 172.16. Very
| unlikely to have a conflict there.
| EvanAnderson wrote:
| I find a lot of Docker containers using subnets inside
| 172.16.0.0/16.
| notpushkin wrote:
| Probably for the same reason - 172.16/12 is not as widely
| used for other networks :-)
| pclmulqdq wrote:
| I often use 172.31/16 for subnets and have never seen a
| conflict. I have seen 172.24 and 172.16 used before, though.
| dmd wrote:
| 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.
| dijit wrote:
| 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.
| x0 wrote:
| 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_add
| resses
| pcarroll wrote:
| I actually looked at using those before the CGNAT range,
| but many of those blocks have been returned to the public
| Internet.
| OptionOfT wrote:
| 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.
| pcarroll wrote:
| 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.
| pcarroll wrote:
| 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.
| solaris2007 wrote:
| > 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 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).
| organsnyder wrote:
| I don't have enough time for that.
| pcarroll wrote:
| 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.
| eqvinox wrote:
| 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-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.
| yardstick wrote:
| 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.
| eqvinox wrote:
| 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.)
| direwolf20 wrote:
| The Metro Ethernet Forum standardized a lot of services
| telcos can offer, many years ago
| pcarroll wrote:
| 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.
| eqvinox wrote:
| 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 trying to do, the statelessness can be anything
| from useless to service critical (the latter if you're under
| some risk of DoS due to excessive state creation). It can
| also alleviate NAT problems, e.g. SIP and RTP are "annoying"
| to NAT.
|
| (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.
| rpcope1 wrote:
| The suggested solution involves using the CGNAT /10 in
| conjunction with a VPN, but I've actually seen someone do this,
| and still have problems with certain end users where their next
| hop for routing also involves a router with an IPv4 address in
| the same space, so it's not really bulletproof either. We may as
| well consider doing other naughty things like co-opting DoD non-
| routable /8s or the test net in the RFCs you're not supposed to
| use, because basically anything you pick is going to have
| problems.
| pcarroll wrote:
| That does not happen here. The CGNAT addresses are in the VPN
| tunnel. And the tunnel connects private devices end-to-end. The
| LAN packets never see the Internet. They are inside the
| WireGuard packets.
| DontBreakAlex wrote:
| Can we please just use ipv6? PLEASE
| direwolf20 wrote:
| no because it wastes 24 bytes per packet!!!11111
| Frotag wrote:
| > 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.
| direwolf20 wrote:
| It's not enough to set fake routes. You have to edit the
| addresses in the packets, so the end devices will receive them.
| Frotag wrote:
| Yeah so instead DNAT, use NETMAP on the gateway device to
| that LAN. (Sorry if I'm abusing the terminology, I only do
| this stuff like once a year for homelab.)
|
| 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
|
| With other wg peers getting a 192.168.150.0/24 entry in the
| AllowedIPs for this gateway (if needed).
| pcarroll wrote:
| The problem there is you still need to keep track of the
| subnets. It works for a while, but it's quite complex. NAT is
| actually easier when you get into hundreds of sites.
___________________________________________________________________
(page generated 2026-01-28 23:01 UTC)