I adore Nebula and half wish I had chosen it instead of Tailscale+Headscale, the one thing about headscale that I really like is how easy it is for users to just grab the client and then login using their gmail account and they're on the network. The biggest downside I've found to tailscale is their "network shenanigans" with firewall rules and route tables on Linux. In my testing 3-5 years ago, Nebula worked great in my test environment.
I'm tempted to add Nebula support to WeEncrypt for automated handing out of the certs using a LetsEncrypt-style short lived certs. I could even imagine a fairly easy to build workstation client that would require end-users to login to get their refreshed certs once they expire, like we do with Tailscale+Headscale.
> I adore Nebula and half wish I had chosen it instead of Tailscale+Headscale...
Could I ask you to expand on that a little? Besides Tailscale's "network shenanigans" with firewalls and routing tables, what else do you find that Nebula does better than Tailscale? Why would you recommend Nebula instead of Tailscale to someone who hasn't used either one before; what's Nebula's big "win" over Tailscale? (Assuming that this person's usage would fit within Tailscale's free tier so price isn't a consideration, because obviously free is nicer than $$$/month if your usage is large enough to be outside free-tier limits).
So I understand how you could onboard hosts on a static network using reverse DNS, but I do not understand how you would unboard a portable laptop onto Nebula using reverse DNS
I'm confused. What do you mean by this? Does dnsmasq not put the names of DHCPv6 clients into its hostname database? If ISC DHCPd is commanded to update DNS, does it only update for DHCP clients and not DHCPv6 clients?
They probably mean that when using SLAAC - I guess the easiest way to get ipv6 connectivity - there is no equivalent to the way you can update DNS the way it would work with DHCPv4 or DHCPv6.
You pointed out one way - justuse DHCPv6, but that looses some of nice SLAAC properties.
A different way is to run mdns and let the devices announce their own hostnames.local.
Different tradeoffs, but in practice not too difficult to get to work.
I adore Nebula and half wish I had chosen it instead of Tailscale+Headscale, the one thing about headscale that I really like is how easy it is for users to just grab the client and then login using their gmail account and they're on the network. The biggest downside I've found to tailscale is their "network shenanigans" with firewall rules and route tables on Linux. In my testing 3-5 years ago, Nebula worked great in my test environment.
I'm tempted to add Nebula support to WeEncrypt for automated handing out of the certs using a LetsEncrypt-style short lived certs. I could even imagine a fairly easy to build workstation client that would require end-users to login to get their refreshed certs once they expire, like we do with Tailscale+Headscale.
That would dove-tail nicely with the existing TLS and SSH signed host keys support. https://github.com/linsomniac/weencrypt
> I adore Nebula and half wish I had chosen it instead of Tailscale+Headscale...
Could I ask you to expand on that a little? Besides Tailscale's "network shenanigans" with firewalls and routing tables, what else do you find that Nebula does better than Tailscale? Why would you recommend Nebula instead of Tailscale to someone who hasn't used either one before; what's Nebula's big "win" over Tailscale? (Assuming that this person's usage would fit within Tailscale's free tier so price isn't a consideration, because obviously free is nicer than $$$/month if your usage is large enough to be outside free-tier limits).
Not OP - my two issues with tailscale today:
- breaks wsl mirrored network to the point a reboot is needed (not sure how much of this is on windows, though)
- break dns randomly on an Debian system to the point I have a watchdog timer systemd unit to restart tailscaled
What is a wsl mirrored network?
So I understand how you could onboard hosts on a static network using reverse DNS, but I do not understand how you would unboard a portable laptop onto Nebula using reverse DNS
Agreed, a roaming laptop would need to have a secured ethernet/wifi connection. I'm using it for servers, about half of them we respin nightly.
I believe you can disable this and it isn’t really required for TS to work
Neat, I just finished getting acquainted with some IPv6 internals. Other than the long names and lack of DNS integration, it's really a great thing.
I've been meaning to mess with tailscale or similar, perhaps I'll take a look at this.
What do you mean by lack of DNS integration?
> Other than ... lack of DNS integration...
I'm confused. What do you mean by this? Does dnsmasq not put the names of DHCPv6 clients into its hostname database? If ISC DHCPd is commanded to update DNS, does it only update for DHCP clients and not DHCPv6 clients?
They probably mean that when using SLAAC - I guess the easiest way to get ipv6 connectivity - there is no equivalent to the way you can update DNS the way it would work with DHCPv4 or DHCPv6.
You pointed out one way - justuse DHCPv6, but that looses some of nice SLAAC properties.
A different way is to run mdns and let the devices announce their own hostnames.local.
Different tradeoffs, but in practice not too difficult to get to work.
I guess one could even do both...