Comparing and contrasting Nebula and WireGuard

Nebula and WireGuard are both protocols that provide secure network tunnels, mutually authenticating and encrypting traffic between hosts to ensure that third parties can neither read nor modify the protected communications. Both are implemented as UDP-based Layer 3 tunnels. The protected underlying application traffic is captured, encrypted and forwarded on their respective target peers at Layer 3, the IP layer. They both use variants of the Noise protocol framework to mutually authenticate and encrypt their tunnels (WireGuard uses NoiseIK, while Nebula uses NoiseIX.) Even their tunnel UDP payloads bear a striking similarity!

Here’s Nebula’s payload:

|----------------------------------------------------------------------|
| Version (uint4) | Type (uint4) | Subtype (uint8) | Reserved (uint16) | 32
|----------------------------------------------------------------------|
| Remote Index (uint32)                                                | 64
|----------------------------------------------------------------------|
| Message Counter                                                      | 96
| (uint64)                                                             | 128
|----------------------------------------------------------------------|
| Encrypted Payload ...                                                |

And here’s WireGuard’s payload:

|----------------------------------------------------------------------|
| Msg Type (uint8) | Reserved (3 bytes)                                | 32
|----------------------------------------------------------------------|
| Receiver Index (uint32)                                              | 64
|----------------------------------------------------------------------|
| Message Counter                                                      | 96
| (uint64)                                                             | 128
|----------------------------------------------------------------------|
| Encrypted Payload ...                                                |

So…what are the differences between the two? Let’s skip to the end with a good ‘ol TL;DR, and then dive into the details.

WireGuard was designed to be a “secure network tunnel” aiming to “replace both IPSec for most use cases as well as popular user space…solutions like OpenVPN“. Intentionally scoped to the creation of point-to-point public-key based tunnels between hosts, Wireguard is a high quality open source project that is easily auditable. It’s a solid upgrade to existing protocols deployed in hub-and-spoke VPN deployments in which many clients connect to a central VPN server.

Nebula was designed with a different goal in mind: enabling many direct peer-to-peer tunnels between hosts in an overlay network, whether those hosts reside next to each other on the same LAN or on opposite sides of the internet. This different goal led Nebula to make different design decisions. Nebula uses certificate based authentication, which minimizes configuration changes to existing Nebula hosts when new hosts are added to the network. Certificate metadata also enables Nebula to include a built-in firewall, effectively bringing the concept of AWS Security Groups to the entire Nebula overlay network. Finally, Nebula also introduces a Lighthouse to coordinate activity between peers, enabling direct connections between hosts even when both reside behind NAT and network firewalls.

Wireguard establishes a mutually authenticated secure tunnel between two peers based on pre-shared public keys and pre-configured WireGuard IP addresses. For example, if I want to connect my laptop to a cloud server over a WireGuard tunnel, I need to first generate two keypairs - one keypair for my laptop, and another keypair for my cloud server. Next, I need to allocate each of these hosts a Wireguard IP address, and finally configure both of these systems with the public key and Wireguard IP address of the other system. There’s a fantastic walkthrough of this process on WireGuard’s website

Nebula also uses keypairs to authenticate hosts on the network. However, Nebula does not require peer public keys to be pre-shared on the network. Instead, Nebula shares this information just in time during the handshake process, by way of a signed certificate. The certificate contains the required peer public key, but also includes more information about the peer, such as its Nebula IP address, name, and group membership information. To enable the peer to trust the information contained in the certificate, the information is cryptographically signed by a Nebula Certificate Authority. (I say “Nebula Certificate Authority” because Nebula has its own, simplified certificate format. It does not use the larger, more complex X.509 certificate format.) When each peer receives the certificate in the handshake, they mutually validate the Nebula Certificate Authority’s signature in order to establish trust in all the information contained in the Nebula Certificate.

In contrast to WireGuard, Nebula hosts do not need to be pre-configured with every other host’s public key and IP address. Instead, every Nebula host is configured with a trusted Nebula Certificate Authority, along with their own host certificate also signed by a Nebula Certificate Authority.

This means that adding a new host to a Nebula network only requires modification to the new peer. Once the peer has a signed Nebula Certificate, existing hosts already on the Nebula network do not need to be reconfigured to successfully establish Nebula tunnels with that new host.

Just because two hosts should be able to talk to each other doesn’t mean that every application on a host should be available to its peer. For instance, perhaps a web server needs to be able to access a database port, but should not be able to access an SSH port on that same database host.

WireGuard doesn’t provide a baked-in firewall. Rather, since packets on a host to and from WireGuard IP addresses traverse tunnels established by the WireGuard mutual authentication flow, server admins can use the host firewall with IP-based rules to control network access with some assurance that the packets received from the WireGuard IP address are authentic - a big improvement over IP-based firewalls that do not include authentication. The Database admin can use iptables to build a firewall rule based on the WireGuard IP address of the web server, denying access to the SSH port while allowing access to the Database port. So, it’s possible to build firewall rules, but the admins must separately track the identity of those IP addresses. They may also require frequent updates as hosts churn on the network. For example, assuming the WebApp host’s IP address is 172.16.200.6 and the Admin’s host is 172.16.200.7, the database host administrator can make these firewall rules:

172.16.200.6 -> TCP port 3306
172.16.200.7 -> TCP port 22

Nebula’s answer for securing access at the port and protocol level is baked into the Nebula process itself. By directly integrating the firewall into the Nebula software, Nebula is able to use information from the certificate when making firewall decisions. The end result is firewall rules based on host groups, which do not require frequent updating as new hosts are added to the network - bringing all the benefits of a system like AWS Security Groups to your entire network, no matter its physical location.

Using the same example as above, the Nebula admin can set a firewall rule on the database host which permits any host that has a group named WebApp access to the database port, but only Nebula hosts in a group named Admin access to the SSH port. These access rules will be enforced on the database host itself, and don’t require updates when new WebApp servers are created or removed. As long as the web servers have a signed certificate that identifies them as part of the WebApp group, the database host’s Nebula firewall will permit access. You can read more about Nebula firewalls here https://www.defined.net/nebula/config/#firewall

firewall:
  inbound:
      # Allow tcp/443 from any host with WebApp group
      - port: 443
        proto: tcp
        groups:
          - WebApp

      # Allow tcp/443 from any host with WebApp group
      - port: 22
        proto: tcp
        groups:
          - Admin

WireGuard tunnels traffic by way of a UDP protocol. In order for traffic to traverse a WireGuard tunnel, UDP traffic will need to be routed between the two peers over a physical network. Typically, a session or tunnel between two hosts uses the 5-tuple of source IP, source port, destination IP, destination port, and protocol (TCP or UDP) to identify a unique flow. Since the WireGuard tunnel is strongly authenticated, WireGuard cleverly identifies a flow not based on the 5-tuple, but rather based on whether the encapsulated traffic is properly encrypted or not. This has a fantastic quality that a single host can roam on the internet, getting a new IP address and/or port without affecting the underlying WireGuard tunnel.

When a WireGuard host receives a WireGuard UDP packet, it uses a hint in the header of the packet to look up the negotiated symmetric key to decrypt that packet. If the decryption is successful, the host will update its peer information with the latest IP and port in the UDP packet. From then on, the host will use this updated IP and port when sending outbound traffic to the peer.

This will work great when one of the WireGuard peers is available on the public internet and one is behind a NAT and network firewall. What if both peers are behind NAT and firewalls, though?

Nebula’s network architecture includes a special host named a Lighthouse to help all other Nebula nodes connect to each other, no matter what physical network they reside in. When Nebula first starts up, it immediately makes connections to its configured Lighthouses. As part of that connection, the host will advertise all of its known interface IP addresses to the lighthouse. Nebula Lighthouses must be deployed so that all other Nebula hosts may establish an unsolicited connection to it - most generically, it should have an internet IP address and firewall rules that permit inbound Nebula UDP traffic. Deployed this way, the Nebula lighthouse will also discover the NATed IP address and port of the host - something the host itself doesn’t know. Since all peers are connected to the Lighthouse, the Lighthouse can help any two Nebula peers connect directly to each other, even if they are both behind NATs and network firewalls.

When a Nebula peer wants to establish a connection to some other peer on the overlay network, it first queries the Lighthouse to learn the most up-to-date real ports and IP addresses (internet IP addresses, NATed IP addresses, and self-reported LAN IP addresses) for the target Nebula peer. The Lighthouse will give the initiating peer a list of IP/port addresses that might work. It also forwards a message along to the target peer, letting it know who is trying to connect to it. Both peers then actively attempt to connect to each other. In typical firewall configurations and for many NAT devices, sending the packets outbound also permits inbound traffic to be routed to the peer. This enables two Nebula peers on separate networks, behind firewalls and NATs, to be able to connect directly to each other.

When two Nebula hosts are on the same LAN, however, they will also discover that connecting through their NAT IP addresses isn’t as efficient as directly connecting via their LAN IP addresses. They will explore all the IP addresses returned by the Nebula Lighthouse in order to find the most efficient route to each other, ensuring a secure tunnel with the minimum possible latency.

Even with this NAT traversal code, some NATs are very difficult to tunnel through. As a backstop for those cases, Nebula also supports relays. You can read more about Nebula relay support here (https://nebula.defined.net/docs/config/relay/)

WireGuard is a secure networking protocol and tool designed for simplicity and security (which go hand in hand.) Its design goals lend itself to classic VPN deployment models but with pre-configuration. Nebula’s focus on peer-to-peer connectivity at scale leads to different design choices, enabling connectivity between peers on any network without full Nebula overlay network reconfiguration, AWS-like security groups firewall configuration, and full network encryption on every host, whether they’re across the globe or next to each other on the same LAN. If you’re interested in trying it out, you can follow the quick-start guide here (https://nebula.defined.net/docs/guides/quick-start/ ), or you can let Defined Networking manage the Certificate Authority and host configuration for you by signing up here (https://admin.defined.net/signup) - it’s free for networks with 100 or fewer hosts.