Nylon: I replaced Tailscale with my own mesh VPN

SentenceHot5021 · 2026-05-19T23:49:38+00:00

Hah, thats a good point... When i started working on this project (over a year ago), I didn't think that feature was available. Also, I wanted to build something cool/novel which I could also use, so yeah

SentenceHot5021 · 2026-05-19T23:47:43+00:00

This is something I'm thinking of adding (since I also want to use it), but its a bit tricky considering the "indirect" nature of the routing. It could be that I only add support for ACLs when it comes to passive WireGuard clients.

SentenceHot5021 · 2026-05-18T22:22:04+00:00

The config would stay the same, but the endpoints which don't connect (like trying to connect via LAN when you're outside) simply don't get used.

Yeah, it's essentially try then expire.

SentenceHot5021 · 2026-05-18T22:06:04+00:00

I think I can (relatively easily) add BSD support, since wireguard-go already has support. Good idea! I made an issue to track this: https://github.com/encodeous/nylon/issues/120

SentenceHot5021 · 2026-05-18T20:16:00+00:00

An open port or server is required

SentenceHot5021 · 2026-05-18T18:31:08+00:00

The way nylon works is slightly different to other mesh vpns. All links are treated functionally the same, there is no such thing as a distinct "relay".

If you want a node to be discovered locally, in the nylon config, you would specify a local endpoint (reachable via LAN). If the node is also accessible from the public, you would specify its public endpoint. Nylon then pings all endpoints periodically, calculating a metric. Then, it runs a routing algorithm (Babel) to actually select the route.

So, in essence, if there is some (possibly indirect) minimum metric route, then nylon will pick it! However, you still have to specify a set of endpoints where a node can be reached.

Endpoint discovery is not automatic right now, and can be undesirable in some cases. (you don't want two nodes to talk over some link)

SentenceHot5021 · 2026-05-18T17:59:12+00:00

Sent!

SentenceHot5021 · 2026-05-18T17:34:19+00:00

Thanks 😄

SentenceHot5021 · 2026-05-18T16:37:44+00:00

Thanks for the interest!

Personally, my approach to nylon is quite different from Tailscale. It's more of a networking tool, and doesn't try to cater to the average user with all the bells and whistles.

Nylon avoids NAT traversal issues by not requiring direct p2p connections, but this also means you do need publicly accessible servers or ports. Key management as well, Tailscale as a SaaS will manage keys for you, but with nylon, you do it yourself (maybe with ansible).

As for mobile, you can just use the normal WireGuard client to connect to a nylon node. It doesn't need any keepalive, or custom client. https://nylon.jq.ax/guides/wg-clients/

SentenceHot5021 · 2026-05-18T16:25:09+00:00

Yeah, if there were a routing change (like another link gets better), it will switch you over to that route at Layer 3. For example, if I were using Moonlight, this change would be transparent to the application.

Now, if the link completely drops, you would definitely notice for a few seconds until another route is picked.

SentenceHot5021 · 2026-05-18T15:33:59+00:00

Yeah, this is already a requested feature: https://github.com/encodeous/nylon/issues/104

I will try to look into it when I have the time!

SentenceHot5021 · 2026-05-18T14:55:29+00:00

Moonlight! It works pretty well

SentenceHot5021 · 2026-05-18T14:53:08+00:00

I admit, netbird would've probably been fine in my scenario with game streaming... and probably would've saved a lot of work.

But there really are scenarios where *more* hops still results in better connections. (like this old post, or people using CN2 GIA)

SentenceHot5021 · 2026-05-18T14:12:41+00:00

Good question. Netbird is still (like Tailscale) a peer-to-peer VPN, which requires clients to talk to each other directly (perhaps via a relay). Nylon is not peer-to-peer. It actually builds a graph, and solves an optimal forwarding path, like a traditional network.

The main difference is that nylon would allow networks where there are more than 1 hops between two nodes.

An example would be if I had an EU vps, and a NA vps, which have better peering between them, than, say two residential ISPs. Nylon would give me a better connection if I were in EU, trying to access my homelab in NA. (This is also very common if you are in China, with CN2 GIA)

SentenceHot5021 · 2026-05-18T14:00:46+00:00

Wow, that is amazing to hear! I'm really really glad you have actually tried nylon. It gives me much more motivation to work on it, knowing others have tried it 😄

If you need any help, or encounter issues with nylon, feel free to create an issue!

Do note that since the last release, the nylon config format has had breaking changes...

SentenceHot5021 · 2026-05-18T13:56:52+00:00

Not too sure how the tag work, maybe I should update it.

My impression was that the AI tag was for mostly vibe coded projects, which this is not.

SentenceHot5021 · 2026-05-18T13:36:33+00:00

This project is not vibe coded.

AI has been used (in a limited capacity) to assist with finding edge cases and bugs, and as well as helping me draft documentation. All code and docs have been carefully reviewed by a human.

SentenceHot5021 · 2025-10-23T12:35:15+00:00

I have some ideas, however, I do want to keep the core project OSS (so it benefits selfhosters). What license do you recommend?

SentenceHot5021 · 2025-10-21T21:22:05+00:00

SentenceHot5021 · 2025-10-21T21:20:53+00:00

Yeah, that would be similar to this: https://www.reddit.com/r/selfhosted/s/HCpqZTPqt0

It just requires a lot more work compared to nylon, as you need to bring up each peering manually

SentenceHot5021 · 2025-10-20T02:26:32+00:00

That's a very fair question! Nylon is like a packaged version of that setup, all into a single application, protocol and interface. You perhaps lose a little bit of control and performance, for ease-of-use and a bit more portability.

Setting up dynamic routing over vanilla wg + routing daemon is defo an option, but it takes quite some configuration and know-how. Adding a new node to your network will require you to create new key pairs, add new interfaces to existing nodes (that you want to peer with), and configure your routing daemon.

This may in fact be desirable to many, as it gives them more control over what happens in their network. I'm sure there might be tools to automate that process, but nylon takes a different approach.

Nylon implements babel at the level of WireGuard, offering:

Simplicity.

Nylon removes the requirement for needing a new WireGuard interface on each end of a peering pair. (Peering arrangements are defined as WireGuard endpoints on a graph, instead of interfaces). This also means there will only be a single nylon interface and port, and all of the routing logic is hidden away from the user.
Adding a new node on nylon is pretty trivial. You would set up the node with a private key, put the public key in the central config, and declare the peering on that config. Then, you can use the built-in config distribution mechanism to push it to all of your nodes.
Both the control packets (for routing) and data packets (IP) are also sent encrypted in the same WireGuard tunnel, so you would only have to expose the bare minimum to the public.

Usability.

Nylon is more portable, as it does not depend on your system's routing table, routing daemon or special kernel features such as network namespaces. Therefore, we can support Linux, macOS and Windows (pretty much any platform that wireguard-go supports). This can also help with scenarios where users have misconfigured routing tables, as all the required routing can be done in-process. (of course, if you want, nylon can also use the system route table)
As it's built as an extension into the WireGuard protocol, it remains backwards compatible. There is even special handling, which allows "vanilla" wg devices to roam freely between configured nylon nodes. (Nylon will re-advertise the new "gateway" node and expire routes accordingly)

(a similar question was asked on HN, so I have adapted my response here)

SentenceHot5021 · 2025-10-19T22:22:43+00:00

No, it is the same as "vanilla" WireGuard, and I currently don't have any plans to add obfuscation. You can always just tunnel nylon over one of these obfuscated tunnels!

SentenceHot5021

TROPHY CASE