How to use Nebula: install, certificates and run it

What Nebula does and who it suits

Nebula uses certificates and encryption to authenticate each machine, and lets you write firewall rules based on named groups. The README says it runs on Linux, OSX, Windows, iOS and Android, and can connect a few computers or tens of thousands.

It suits teams connecting servers across several clouds or data centers, and people who want a private network between their own machines without a fixed address plan. It is not a plug-and-play VPN: the setup involves creating a certificate authority, signing certificates and editing configuration files.

• Good fit: group-based firewall rules similar to cloud security groups
• Good fit: hosts in multiple cloud providers, data centers and endpoints
• Not a fit: a consumer 'hide my browsing' VPN, since Nebula is framed as a network overlay for connecting hosts

Install Nebula on your platform

The simplest route is a distribution package. The README lists packages for Arch Linux, Fedora, Debian, Alpine, macOS Homebrew and Docker. You can also download binaries from the releases page. Building from source requires Go.

• Arch Linux: sudo pacman -S nebula
• Fedora: sudo dnf install nebula
• Debian: sudo apt install nebula
• Alpine: sudo apk add nebula
• macOS: brew install nebula
• Docker: docker pull nebulaoss/nebula

Create a certificate authority

Nebula uses certificates to assert a node's IP address, name and group membership. The certificate authority is the root of trust for your network. Running the command below creates ca.key and ca.cert in the current directory.

The ca.key file is the most sensitive file you will create, because it signs the certificates for every node. Store it somewhere safe, preferably with strong encryption. By default a CA has a 1-year lifetime, so the README points to a guide on rotating it.

Sign certificates for each host

Each node needs its own key and certificate signed by your CA. The README example uses a 192.168.100.x/24 range and shows how to assign groups, which you can later use in firewall rules. You can name nodes any way you like, including FQDN.

Host certificates expire one second before the CA by default. Use the -duration flag to set a shorter lifetime.

• lighthouse1 at 192.168.100.1/24
• laptop at 192.168.100.2/24 with groups laptop, home, ssh
• server1 at 192.168.100.9/24 with group servers
• host3 at 192.168.100.10/24

Set up the lighthouse and config files

A lighthouse is a discovery node with a routable IP address that lets nodes find each other. The README says it is the only node whose IP should not change, and that it needs very few resources, so a small cloud host works. Make sure Nebula UDP traffic (default port udp/4242) can reach it over the internet.

Download the example configuration file, config.yml. On the lighthouse set am_lighthouse: true. On other hosts, define the lighthouse in the static_host_map section and add it to the lighthouse hosts section.

• Set am_lighthouse: true on the lighthouse node
• Define the lighthouse in static_host_map on each host
• Add the lighthouse to the hosts section on each host
• Open udp/4242 or your chosen port

Copy files to each host and start Nebula

For each host, copy the nebula binary, config.yml, ca.crt, the host's .crt file and its .key file. Never copy ca.key to individual nodes.

Start Nebula on each host by pointing it at the config file.

• Copy: nebula binary, config.yml, ca.crt, {host}.crt, {host}.key
• Do not copy ca.key to any node

Build Nebula from source (optional)

If you want to build it yourself, install Go, clone the repository and change into the nebula directory. The README lists make all for every platform and make bin-windows for a specific one. See the Makefile for more targets.

For compliance needs, the README covers a P256 curve option when creating a CA and FIPS 140-3 build targets. The default curve is Curve25519, which the README recommends for most users.