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

61–70 of 123 posts

Re: When Every Network is 192.168.1.x

#61

Post by direwolf20 »

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.

The Metro Ethernet Forum standardized a lot of services telcos can offer, many years ago

Re: When Every Network is 192.168.1.x

#62

Post by direwolf20 »

Frotag wrote: post #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…

It's not enough to set fake routes. You have to edit the addresses in the packets, so the end devices will receive them.

Re: When Every Network is 192.168.1.x

#64

Post by pcarroll »

BrandoElFollito wrote: post #13
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

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.

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.

Re: When Every Network is 192.168.1.x

#65

Post by Frotag »

direwolf20 wrote: post #62
Frotag wrote: post #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…

It's not enough to set fake routes. You have to edit the addresses in the packets, so the end devices will receive them.

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

Re: When Every Network is 192.168.1.x

#66

Post by lxgr »

pcarroll wrote: post #60
lxgr wrote: post #10

Earlier quoted context omitted.

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.

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.

Re: When Every Network is 192.168.1.x

#67

Post by pcarroll »

direwolf20 wrote: post #62
Frotag wrote: post #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…

It's not enough to set fake routes. You have to edit the addresses in the packets, so the end devices will receive them.

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.

Re: When Every Network is 192.168.1.x

#68

Post by pcarroll »

rpcope1 wrote: post #25

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

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.

Re: When Every Network is 192.168.1.x

#69

Post by eqvinox »

pcarroll wrote: post #53
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…

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.

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.

Re: When Every Network is 192.168.1.x

#70

Post by BrandoElFollito »

pcarroll wrote: post #64
BrandoElFollito wrote: post #13

Earlier quoted context omitted.

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.

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

This overlay approach is fantastic, but I do not think it exists in Tailscale.
Post reply on HN