We’re excited to share what’s new in DN, our overlay networking solution for organizations.

Over the past several months, we’ve received a bunch of great feedback from DN beta users. A mix these suggestions and onboarding observations has helped shape the features and improvements we’ve made to the administrator experience.

👋 For those of you that are new here, Defined Networking was founded by the creators of the Nebula Overlay Networking Project. Nebula enables scalable connectivity between any number of hosts with on-demand, encrypted tunnels.

Nebula, made easy.

Our goal with DN is to help organizations realize the connectivity and security benefits of overlay networking without the overhead typically involved with the self-hosted, open source approach.

Core Features

DN is an overlay networking solution built for organizations that need reliable, secure connectivity between thousands of hosts distributed across any number of networks.

Includes everything needed to manage a highly scalable overlay network:

  • Overlay network IP management
  • Groups-based host firewall
  • Host certificate signing service
  • Comprehensive audit logging
  • Administrative web application
  • Client software: Nebula + host lifecycle automation


What’s new in DN?

Automated host enrollment

The DN API brings automation to the process of adding, enrolling, and deleting overlay network hosts. Now, admins can fully automate host enrollment using tools like Ansible.

Steps for enrolling a new host via API

  1. Request an enrollment code from DN service with specified host name and role
  2. Copy the dnclient binary and enrollment code to host
  3. Run dnclient on host to generate keypair and request certificate signing

The DN service validates the enrollment code before minting a new host certificate, which is returned to the host along with the configuration details necessary for the host to join the overlay network.

That’s it. ✨

Example of using curl to create a host and getting an enrollment code.

Automatic certificate rotation

Nebula uses a public-key infrastructure (PKI) model for identifying, authenticating, and authorizing connectivity between overlay network hosts. Every host needs a certificate signed by at least one, trusted overlay network Certificate Authority.

Among other metadata, each certificate also has a validity period. When two hosts are handshaking, they will verify each other’s certificate:

  • Is this cert signed by a CA I trust?
  • Is the current timestamp within the cert’s validity period?
  • Does this cert exist on any of my blocklists?
  • What role is included in the cert (and do I have any firewall rules that apply)?

If all checks pass, mutually, between the hosts, they will continue the handshake process and establish an encrypted channel between one another.

Similar to other PKI systems, it is a best practice to “rotate” the certificates (and corresponding key pairs) on a regular basis. The Nebula open-source project provides the tools to generate and sign certificates, but it leaves the production process and implementation up to the user.

DN takes the best practices for running a large-scale, production overlay network and handles all the details on behalf of each customer.

Each DN customer gets their own CAs, which are fully managed as part of the DN solution. In a recent update, we added the support for rotating CAs automatically. The necessary host configuration updates will also get pushed out automatically.

This improvement is one of those behind-the-scenes capabilities that isn’t flashy, but is critical for running a production overlay network. We’ve put a lot of work into getting this implementation right, so you don’t have to think about it.

But… if you want to talk details, we are here for it. 💜


Support for multiple Lighthouses

Lighthouses are a special type of Nebula host that provide a “lookup” service to other hosts on the overlay network. Every network requires at least one lighthouse, typically with an Internet-routable IP address that allows inbound UDP traffic on a specific port.

When an overlay host wants to connect to another it sends a query to the lighthouse,

“I’d like to connect to 100.100.0.33, what routes should I try?”

The lighthouse will return a list of IPs & UDP ports it learned about when the requested host came online. Lighthouses also assist with NAT traversal between two hosts making a direct connection.

DN supported a single lighthouse from the very first beta. Now, each customer can run multiple lighthouses, which is especially useful for large and geographically distributed overlay networks.

Screenshot of UI demonstrating multiple lighthouses

Hosts are automatically updated when lighthouses change

Nebula has always supported multiple lighthouses, but in order for existing hosts to learn about a lighthouse that was added or deleted they would first need to get a new Nebula configuration. Then, each host would need to restart its Nebula process to load new lighthouses.

DN improves this process: Any time an admin adds or removes a lighthouse, the DN service running on each host will pull in the latest configuration information within 60 seconds.

As part of this release, we also added the ability to load a new lighthouse hostmap to core Nebula. (No more restart required!) All existing host tunnels will continue to run without interruption.

That’s it for this update. Thanks again for your interest!

Feel free to send an email with any comments or questions. 🪐

—The Defined Networking Team