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.
If that's the case, then you've got to think of SLAAC as operating exactly like IPv4 address autoconfiguration (sometimes called "IPv4LL")... except that you usually get globally-routable IP addresses out of it.
If you want the management niceties that you often get when using DHCP, then you have to use DHCP.
Some very loud purists might say "SLAAC is the only way to use IPv6!". I completely ignore the convenience of LAN-side prefix delegation and say two things:
1) "Good luck with telling your IPv6 clients about things like your preferred NTP server."
2) "For ages, Router Advertisements have had entirely independent 'autoconfigure your addresses', 'use stateful configuration for your "other" configuration' [0], and 'use stateful configuration for your addresses' bits. It's legal to have any number of them enabled. This is a deliberate choice by the folks defining IPv6."
In general, the folks who scream about how IPv6 NAT and DHCPv6 should not exist and should never be used should be ignored... at least about that topic.
[0] Things like NTP and DNS that other good stuff that DHCP can be used to tell hosts about.
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?
https://learn.microsoft.com/en-us/windows/wsl/networking#mir...
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
The IPv6 for the overlay is neat. I won't use it probably (as my number of hosts is <100) but I would prefer better support for dualstack underlay.
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...
> They probably mean that when using SLAAC...
If that's the case, then you've got to think of SLAAC as operating exactly like IPv4 address autoconfiguration (sometimes called "IPv4LL")... except that you usually get globally-routable IP addresses out of it.
If you want the management niceties that you often get when using DHCP, then you have to use DHCP.
Some very loud purists might say "SLAAC is the only way to use IPv6!". I completely ignore the convenience of LAN-side prefix delegation and say two things:
1) "Good luck with telling your IPv6 clients about things like your preferred NTP server."
2) "For ages, Router Advertisements have had entirely independent 'autoconfigure your addresses', 'use stateful configuration for your "other" configuration' [0], and 'use stateful configuration for your addresses' bits. It's legal to have any number of them enabled. This is a deliberate choice by the folks defining IPv6."
In general, the folks who scream about how IPv6 NAT and DHCPv6 should not exist and should never be used should be ignored... at least about that topic.
[0] Things like NTP and DNS that other good stuff that DHCP can be used to tell hosts about.