WireGuard has been the “hot new thing” when it comes to VPNs, but it’s not always the best suited for every workload. Nebula is a mesh network originally created by Slack, but now owned by a separate company.TechSNAP 419 - Nebulous NetworkingLinux Unplugged 329 - Flat Network TruthersWhat’s a mesh…
An additional feature of nebula is
unsafe_routes. Unsafe routes allow nodes which don’t have Nebula installed to be accessible to other Nebula nodes. Traffic for those nodes is sent via an intermediary node which has access to the devices on its own network. This means you can use a node as a form of gateway to bride to another network, all through Nebula.
As an example, I have a Nebula network of
10.32.32.0/24. One of the nodes,
10.32.32.3, is connected to a private network
10.33.33.0/24 I’d like to connect to. My use case for this being I’d like to be able to access all VMs inside my Proxmox server, but without needing to install Nebula on every single one.
Make sure you trust this network, these routes are “unsafe” for a reason. With this configured, it’s possible (with an extra step) for any device on the
10.23.33.0/24 network to communicate with any device on the Nebula network without authentication. In nebula terms it keeps the firewall group as the intermediary server, but still.
#Adding unsafe routes
The first step is to create some keys for the intermediary server. With nebula, for a device to function as an intermediary gateway, the subnet it’s bridging has to be baked into the keys.
$ nebula-cert sign -name intermediary -ip "10.32.32.3/24" -subnets "10.33.33.0/24"
Then, install that key as normal to your nebula server.
Next, add the configuration for the unsafe routes to your configuration. This entry doesn’t need to be added to all nodes necessarily, just ones you want to communicate with the new subnet. Adding it to the intermediary server will throw errors, so don’t do that.
tun: ... unsafe_routes: - route: 10.33.33.0/24 via: 10.32.32.3
At this point, you can restart nebula on any modified devices, and connections will start going through, mostly. Whilst you’ll see an advertised route for
10.33.33.0/24 on your machine, only the intermediary will be pingable (using its private IP
10.33.33.3). Traffic is able to flow just fine from our client via nebula, through the intermediary and to its destination, but it won’t come back. This is because the destination servers don’t know how to route traffic back to
10.32.32.0/24, so we need to tell them.
For the rest, we need some
iptables. I pride myself that iptables plays no part in my infrastructure, or at least I did until this. It’s now only 1 rule, so i’ll survive. We need to enable NAT so the intermediary device forwards traffic correctly to the rest of the devices on the private network.
$ iptables -t nat -A POSTROUTING -s 10.32.32.0/24 -o ens18 -j MASQUERADE
ens18 here is the interface for the
Once this is done, traffic should flow to devices just fine.
Now devices without Nebula installed can be reached through Nebula, great! But what if I want the inverse? What if I want my VMs to communicate with nodes on the Nebula network? Simple:
$ ip route add 10.32.32.0/24 via 10.33.33.3
This tells those clients to route traffic for the nebula subnet via the intermediary server, which thanks to the NAT rule we just added, will work.
And now, I can access all my proxmox VMs easily, and they can access my other servers with ease, all over an encrypted mesh network.
Share this page
People say there’s no 100% reliable way to wipe a storage drive, and they’re right. By the nature of how mechanical drives work, there’s no real way to say for sure whether the data is ever really gone. With drives, the only way to be sure the content is gone…
Running steam on linux is great, besides the triple-a game support obviously. But running it on an iGPU has recently been causing me problems, mainly under Arch.The solution I have no idea why it works, or why it works, but speaking to some people online, this is the best solution:…
View all →