Skip to Content
Installation

Install Nebula

A private network between the company's computers no matter where they are, with the certificates explained and the key that must never be copied pointed out.

Last reviewed:

What Nebula is

A private network of your own between your computers, no matter where they are. The laptop at home, the computer at the office and a server at a web host each get an address in a network that only you can access, and they talk to each other as if they were in the same room.

It sounds like a VPN, and it is related. The difference is the direction. A regular VPN sends all traffic through a central server, which becomes both a bottleneck and a single point of failure. Nebula lets the machines talk directly to each other, and the central part is only needed so they can find each other the first time.

Practical for a company: you can reach a service you run at home from the office, without opening it to the entire internet. That is the difference between a door with a lock and no door at all.

Two concepts before you start

A lighthouse is the machine that keeps track of where the others are. It must have a fixed address that the others can reach and an open UDP port (4242 by default) where the Nebula process listens around the clock, so in practice a small VPS, not a regular web host. Shared web hosting does not let you run your own processes or open UDP ports. A VPS costs a few tens of SEK per month, and that is the only cost in this guide. No fixed address means no Nebula network, so count on that expense.

A certificate is the machine's ID. You create your own issuer, and every machine gets a document signed by it. If the machine has no document it does not get in, and that is the entire security of the network.

Windows and Linux Mint

There is no installation to run. Download the file for your platform from the project's download page and unpack it. Inside are two programs: nebula, which runs the network, and nebula-cert, which creates the credentials. The same two files on both systems, just different packages.

On Linux Mint the file ends up in the Downloads folder. Go there and unpack it, so that you are in the same folder as the programs:

cd "$(xdg-user-dir DOWNLOAD)"
tar -xzf nebula-linux-amd64.tar.gz

The archive contains the two programs without any subfolder, so they now sit in the folder you are in. That is why the commands further down start with ./, meaning here, in this folder.

On Windows you unpack the zip file by right-clicking and choosing Extract All. The programs are then run from PowerShell in that folder.

Create your certificate authority once, on the computer you trust the most:

./nebula-cert ca -name "foretaget"

You get two files. ca.crt goes to every machine. ca.key must never leave the computer where it was created. Then sign one machine at a time, and start with your lighthouse, because it should have the first address in the network:

./nebula-cert sign -name "lighthouse" -ip "192.168.100.1/24"
./nebula-cert sign -name "laptop" -ip "192.168.100.2/24"

Each machine gets its own address, and two machines cannot share one. If you skip the lighthouse line there is no .1 in the network, and then nothing answers when you ping that address further down.

Three things to do first

  1. Set up the lighthouse first, and only that. Get the example configuration from the project, set am_lighthouse to true and start with sudo ./nebula -config config.yaml on Linux, or PowerShell as administrator on Windows. Nebula creates a network interface, and that requires higher privileges than your regular account has. If it does not work, you do not need to troubleshoot five machines at the same time.
  2. Connect a second machine and ping the lighthouse on its Nebula address, that is ping 192.168.100.1. If you get a reply, the network is up, and everything after that is just more machines of the same kind.
  3. Write down which address each machine got, in the company's usual notes. The addresses do not show up anywhere automatically, and in three weeks nobody remembers whether the server was point four or point five.

The most common trap

Copying ca.key to the machines along with the other files. It is understandable, because all the other files should go there. But that key is what lets you create new valid certificates, and anyone who gets hold of it can add their own computer to your network without you noticing anything.

Three files go to the machines: ca.crt, the machine's own certificate and the machine's own key. Nothing more. ca.key stays where it was created, preferably in an encrypted folder, and the only time you touch it is when you sign a new machine.

The other half: certificates have an expiry date, one year by default. The network works perfectly right up until it does not, and the error message is not particularly clear. Write down the date at the same time as you write down the addresses.

Cart

Loading