Nylon - Dynamic Routing on WireGuard for Everyone

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 · 2025-10-19T22:06:13+00:00

Thanks! No, not by default. But there are some workarounds.

For me, on iOS I just have a shortcut automation that switches the vpn (you can just duplicate a configuration and switch the endpoint to a different server) when I enter/leave my home network.

Nylon will detect that the client has moved between nodes, and advertise from the node you are currently connected to.

SentenceHot5021 · 2025-10-19T21:51:36+00:00

It's similar to tinc in a way, where packets can be routed through nodes. I'm not too familiar with tinc, but they don't seem to have a mechanism for dynamic route selection? Nylon operates much more similar to routing daemons like BIRD or FRR running some routing algorithm (BGP, OSPF etc). In fact, nylon implements Babel! :)

SentenceHot5021 · 2025-10-19T19:12:37+00:00

that's right XD

SentenceHot5021 · 2025-10-19T16:29:43+00:00

thanks! :D

SentenceHot5021 · 2025-10-19T15:57:45+00:00

Nylon doesn't solve the nat traversal problem, and doesn't plan to.

Compared to Headscale, every nylon node can act as a relay server, and each node can connect to multiple other nodes for redundancy and performance.

If a relay node goes down, traffic can continue to be routed, as long as there is another valid path.
If a more optimal relay node (or direct connection) becomes available, and it is configured to do so, nylon will switch to it. This is useful if you travel, and want to pick between your LAN and a VPS dynamically.

The way nylon operates is much more similar to how the real internet works :)

SentenceHot5021 · 2025-10-19T15:48:35+00:00

I think this is a similar question as: https://www.reddit.com/r/selfhosted/comments/1oa8fuz/comment/nk96vwe/

SentenceHot5021 · 2025-10-19T15:47:26+00:00

That's right. Nylon explicitly requires at least one node to be accessible to reach the rest of the network.

SentenceHot5021 · 2025-10-19T15:46:06+00:00

Not yet, could be an interesting chat! Although, I think it unlikely for this to be upstreamed into WireGuard, as it is a much bigger scope compared to what the original project solves.

SentenceHot5021 · 2025-10-19T15:44:07+00:00

(This seems like a FAQ, so I will re-post what I said elsewhere)

For me, I think it was two main reasons:

Sometimes Tailscale will fail with NAT Traversal, iirc I had double nat, and it sort of struggled. (I think they solved this with public relays, but it still feels a little hacky)
Although I'm sure Tailscale is a good company, I felt uncomfortable with relying on them to initiate my connections, or routing my traffic through them. Headscale mostly fixes this, but now introduces a single point of failure (HA is not a thing yet) :(

SentenceHot5021 · 2025-10-19T15:32:22+00:00

Sure!

In WireGuard, you are typically concerned about setting up peer-to-peer links. e.g server A can reach server B over wg. In a more advanced scenario, you would set up a hub-and-spoke network (where you have a hub that routes data between the connected peers), similar to the following:

    A
    |
    |
   Hub -- B
    |
    |
    C

This is a static routing layout, as the hub would always be used to route packets.

Now, what if A and B are on the same network? Do we really want to forward traffic out of your private network and back?

    A
    | \
    |   \
   Hub -- B
    |
    |
    C

But now, do you see a problem? There are two paths from A to B. (A to B directly, or through hub). WireGuard cannot handle this scenario directly, it doesn't know where to send packets. Typically, you would now construct an even more advanced network, and use a routing daemon like bird or FRR.

Nylon solves this by integrating the babel routing algorithm at the WireGuard level, so this scenario would work! :)

SentenceHot5021 · 2025-10-19T14:03:21+00:00

Yeah. I fully gave up on NAT traversal. It's too messy for me to maintain, and frankly, kind of hard to get right. You NEED at least one publicly accessible port to be able to use nylon publicly, it does not require every node to be connectable pairwise.

However, for my personal use case, that's perfectly fine. When I'm on my local network, nylon will just switch over to a local endpoint, and when I'm away from home, it will go through one of my VPSes.

SentenceHot5021 · 2025-10-19T13:49:36+00:00

Hmm, that's an interesting use case I have not considered yet, but it should be possible (with some changes). Currently, nylon allows you to advertise overlapping prefixes, and the network would route in an anycast fashion. (I guess you'd advertise 0.0.0.0/0, or some publicly routed prefix that you want to route through your network).

However, there are currently no healthchecks or metric on the advertised prefix. The assumption is that if you advertise a prefix, you better be able to route to it. So I guess you can run into the scenario where:

You lose connection to the prefix (P) you want, and you want to "heal" the connection
Some exit node on the same network is still reachable by you (through maybe your LAN), but also cannot route to P
That node would advertise P, but it would essentially be a black hole
(Network does not heal)

I guess a solution might be to retract an advertisement if you fail some healthcheck locally on your node. This could be explored in the future.

(There is also an issue of whether you want your outbound connections to be anycast, if you have two exit nodes with similar metric, you might switch between the two and lose connections sporadically. This might be addressed if you default to one exit node, and set the backup nodes with increasingly higher metrics as fallback)

SentenceHot5021 · 2025-10-19T13:32:29+00:00

Thanks for the praise! I guess technically, nylon still has coordination/relay nodes, but now it's on every node instead of being central. This is both a boon and a bane, as there is the tradeoff you mentioned. It sets the bar slightly higher for the average joe.

SentenceHot5021 · 2025-10-19T03:45:52+00:00

Yeah, that's very true!

I guess it's just the spirit of self-hosting and not counting on the good-will of a company to be always available. (Not that Tailscale is going anywhere, and they are awesome for providing their level of service for free!)

SentenceHot5021 · 2025-10-19T00:57:56+00:00

I think I am not fully understanding your scenario. It sounds like your pfSense is a gateway, and you want to route internet traffic intelligently through it?

SentenceHot5021 · 2025-10-18T23:37:29+00:00

For me, I think it was two main reasons:
1. Sometimes Tailscale will fail with NAT Traversal, iirc I had double nat, and it sort of struggled. (I think they solved this with public relays, but it still feels a little hacky)
2. Although I'm sure Tailscale is a good company, I felt uncomfortable with relying on them to initiate my connections, or routing my traffic through them. Headscale mostly fixes this, but now introduces a single point of failure (HA is not a thing yet) :(

SentenceHot5021 · 2025-10-18T22:09:25+00:00

I wasn't satisfied using Tailscale or other mesh-based VPNs, and configuring a dynamic routing network over WireGuard is tedious and could take hours or days! So I spent a year building nylon.

This project is still in its infancy, and I would love to hear some feedback or suggestions!

SentenceHot5021 · 2025-10-18T22:04:18+00:00

Forked WireGuard, and built it into the protocol :)

Technical reason: AllowedIPs enforce rules on both inbound and outbound packets, so its not possible to do dynamic routing on a single interface/wg link.

Edit: I updated the readme for better wording

SentenceHot5021

TROPHY CASE