pcarroll

I wanted to use 11.0.0.0 and call the company "Eleven," but by that time the DOD had given up the block for general use... GCNAT is perfect.

We did. It's called IPv6. It's 20 years old and still not usable universally. At the high end, like enterprise or telcos, it's fantastic. But at the grass roots level of residential and small businesses, it's still a nightmare.

The need is real. You are a service provider. You need to manage equipment at customer sites. You need to access them simultaneously. But all the customers are using the same subnet... If Bell gave out cellphones with the same phone number, how can you call anybody? But they still do. Many devices have cloud access, but every manufacturer is different. It is a nightmare at scale.

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.

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.

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.

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.

Yes! Exactly this.

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.

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.

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.

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

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.

How do you handle embedded devices that cannot install software?

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

How overlay addressing and 1:1 NAT solve the conflicting subnet problem across hundreds of sites. A technical walkthrough with WireGuard. https://netrinos.com/blog/conflicting-subnets

We implement STUN and TURN functionality natively in WireGuard rather than using separate protocols.

Netrinos uses a central rendezvous server that participates in WireGuard handshakes solely to collect your devices' public endpoints and share that information with your other devices. When a device roams to a new location, the server learns the new endpoint and updates the other devices in your account.

When direct P2P fails, Netrinos connections fall back to a relay server. The relay is a WireGuard peer, but it can only relay traffic between peers in your account. All customer accounts are strictly firewalled from each other.

If you want more control, you can enable a device in your account as a relay server with a checkbox in the app. This could be a home PC with a stable connection or a low-cost cloud server.

I have found that residential ISP routers are notoriously flaky. It doesn't take much to confuse them. A lot of edge cases could be just this.

Thanks to everybody who participated. This has been an excellent discussion and has resulted in some interesting ideas to pursue.

Maybe I should look into that... there are a few different ways to do it, and none of them are all that hard.

- i just put it in the roadmap

Netrinos can be entirely cli on all 3 platforms.

If you install the OpenSSH server on Windows, you can manage Netrinos in a terminal, just like on Linux or Mac. e.g.

https://netrinos.com/cdn/images/screens/windows-terminal.png

https://netrinos.com/cdn/images/screens/linux-terminal.png

On a trip to Europe last year, I tried it from the Air Canada in-flight WiFi somewhere over Iceland. I was able to RDP to my desktop at home, then RDP right back to my laptop on the plane. Performance wasn't great. And it's not a terribly useful use case. But it did work.

Wireguard deserves a lot of credit there. No ports were opened on my home end. And who knows what the plane has for NAT.

Could you please elaborate on what you found lacking? Always looking to improve.

Each device on your account gets a private static IP address in the network 100.x.x.x. The name is static as long as the device lives on your account.

Each also gets a friendly DNS name in the form device.account.2ho.ca (try finding a short domain these days).

So yes, you can...

$ ssh user@server.myaccount.2ho.ca

C:\ net use S: \\server.myaccount.2ho.ca\Home

etc.

We do have some comparisons on our site...

https://netrinos.com/compare

Thanks

To clarify, one of the big advantages of a Mesh VPN is that the traffic does not flow through the VPN provider at all. WireGuard encrypts the traffic from device interface to device interface. The connections are point-to-point and not hub-and-spoke. This is both faster and more secure.

If a direct connection cannot be established due to a very restrictive firewall or a messed-up ISP modem, it will fall back to a relay server. But in that case, the relay relays the traffic, but it does not have the keys to read it.

You can learn more here: https://www.wireguard.com/

TL;DR WireGuard itself is a relatively small project at roughly 4,000 lines of code. It has been thoroughly audited and is even built into the Linux kernel.

Pro has that. We call it a Gateway. See:

https://netrinos.com/help/gateways-routing

You can also have multiple gateways and send traffic through different locations. e.g. You can access a NAS on one site and a website through another.

WireGuard itself can be configured to work either way.

Our target market is smaller teams and people with limited IT skills. So, we chose not to send all traffic through the vpn. The only traffic going through the VPN is traffic to and from your other devices (in your account). Internet access is still through your default network.

In the Pro version, you can route specific destinations through other peers, also belonging to you. An example use case here would be accessing your web banking while on vacation in a distant country. You would route your bank website through your home connection.

Similarly, our access control is only restricting traffic that comes from your devices on the wireguard network. We do not interfere with the settings of your own personal firewall.

Thanks for that feedback. I share your feelings about Linux. It never occurred to us that it would be reminiscent of old MS days. We were going for "clean and uncluttered".

If it makes you feel better, all core development for Netrinos is done on Linux. Then, the code is adapted to work on macOS and Windows. Almost all of the code is cross-platform, including the UI. Only the implementation details are platform specific.

e.g. Linux uses nftables. MacOS uses pfctl. Windows, we had to write our own packet filter to avoid touching the often misconfigured Windows Firewall.

Would you mind revealing which one is banned? I wonder what they are using to make that determination.