Dynamic Routing on WireGuard for Everyone | Hacker News Reader

Dynamic Routing on WireGuard for Everyone

github.com

11 pointschenjq7 comments

That sounds intriguing! I'm looking forward to giving it a try. I've checked out the example configurations, and while there’s definitely a learning curve, it seems manageable. I use Babel over WireGuard myself and appreciate the ability to redistribute interfaces through inclusion and exclusion.

I’m curious if Nylon offers similar functionality. Can it redistribute a dummy /32 or a local /24 into the network? Also, how does it handle default route advertising? Would there be a risk of looping, similar to what happens with IPsec tunnels?

I also think this could really benefit from a Docker image to streamline setup.

Thanks for the enthusiasm! You can definitely advertise a /32 or /24 prefix on a given router, and configure the routing separately. (you just need to turn on `nonetconfigure`)

Currently, there is no special handling for the default route, meaning that if you were to advertise 0.0.0.0/0, there might be a loop. Personally, I never tried it, but I don't think it would work. Do you know of a workaround?

When I get some time, I will try to improve docs a little bit, maybe add a setup script, and docker image like you suggested :)

I believe WireGuard employs a strategy where it announces 0.0.0.0/1 and 128.0.0.0/1 instead of using a complete quad-zero. This allows your local default route to maintain a lower administrative distance. Interestingly, they implement it this way on Android, and it appears to work effectively for daily use.

I was just curious. It doesn't necessarily mean it has to be a supported use case.

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!

Whats the use case? Why not grab anything thats already working like FRR or bird or babeld? What benefits will Nylon have over those?

I run myself Overlay VPN network and im just using RIPv3 + BGPv4.

That's a fair point. 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.

I'm not sure about the specifics for your network, but if you want to set up a similar network using WireGuard as the tunnel, you'd have to set up each peering arrangement manually. (Similar to: https://blog.bella.network/internal-bgp-with-wireguard/) This means 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 bypasses 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 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).

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

Okey, fair point, more easy use for less network oriented people and maybe portability. Altough, I never want my Windows enpoint to do any complicated forwarding :)

I use tinc-vpn so I have automesh out of the box.

Reply on news.ycombinator.com