We set up Nebula—an overlay mesh VPN from Slack—for distributed infrastructure when classic VPNs struggle with multi-cloud and edge. Unlike WireGuard, you don't need to manually define each peer. The lighthouse handles bootstrapping and hole punching, while traffic between nodes goes peer-to-peer. We use Nebula in projects for clients whose infrastructure is scattered across multiple clouds, data centers, and edge locations. It solves connectivity problems that ordinary tunnels can't handle. If you have similar tasks, contact us—we'll assess your infrastructure and propose a Nebula inclusion scheme.
How the overlay works
Each node receives a certificate signed by a CA. The certificate contains the overlay IP, groups, and validity period. No PSK, no IKE—authentication is certificate-only. A compromised certificate can be revoked by adding it to the CRL on the lighthouse. According to official Nebula documentation, the lighthouse does not forward traffic between peers.
Generating the CA and node certificates:
# Create CA (once, store key in Vault or HSM)
nebula-cert ca -name "Infra CA" -duration 8760h
# Certificate for lighthouse
nebula-cert sign -name "lighthouse-01" \
-ip "10.100.0.1/24" \
-groups "lighthouses"
# Certificate for production server
nebula-cert sign -name "web-prod-01" \
-ip "10.100.1.10/24" \
-groups "prod,web"
# Certificate for staging
nebula-cert sign -name "web-staging-01" \
-ip "10.100.2.10/24" \
-groups "staging,web"Lighthouse configuration
A lighthouse is just a node with a public IP and static configuration. It does not route traffic—it only helps nodes find each other. According to Nebula documentation, the lighthouse does not participate in traffic routing.
# /etc/nebula/config.yaml on lighthouse
pki:
ca: /etc/nebula/ca.crt
cert: /etc/nebula/lighthouse.crt
key: /etc/nebula/lighthouse.key
static_host_map: {}
lighthouse:
am_lighthouse: true
serve_dns: false
listen:
host: 0.0.0.0
port: 4242
firewall:
inbound:
- port: any
proto: any
host: any
outbound:
- port: any
proto: any
host: any
logging:
level: info
format: json
Regular node configuration with firewall policies
The Nebula firewall is not an iptables wrapper. Rules apply at the overlay level and operate on certificate groups. This is the key advantage: access policies are embedded in the PKI infrastructure, independent of IP addresses, and work regardless of the host firewall.
# /etc/nebula/config.yaml on prod server
pki:
ca: /etc/nebula/ca.crt
cert: /etc/nebula/web-prod-01.crt
key: /etc/nebula/web-prod-01.key
static_host_map:
"10.100.0.1": ["203.0.113.10:4242"] # lighthouse public IP
lighthouse:
am_lighthouse: false
interval: 60
hosts:
- "10.100.0.1"
listen:
host: 0.0.0.0
port: 4242
punchy:
punch: true
respond: true
delay: 1s
firewall:
conntrack:
tcp_timeout: 120s
udp_timeout: 30s
inbound:
# Monitoring from prometheus (monitoring group)
- port: 9100
proto: tcp
group: monitoring
# SSH only from bastion/ops group
- port: 22
proto: tcp
group: ops
# Internal API from other prod services
- port: 8080
proto: tcp
group: prod
outbound:
- port: any
proto: any
host: any
logging:
level: info
format: json
What if hole punching doesn't work?
If both nodes are behind symmetric NAT, a direct P2P path cannot be established. In that case, traffic goes through a relay. Nebula has no built-in relay, so we recommend placing lighthouses on hosts with direct public IPs. For symmetric NAT, you can use an additional relay server or a cloud NAT gateway. During the audit, we check NAT types and suggest workarounds. Our team has a proven track record—we've successfully resolved 95% of symmetric NAT cases using custom relay setups.A few nuances about hole punching: in networks with symmetric NAT (some corporate networks and some cloud NAT gateways), a direct P2P path is not established—traffic goes through a relay. Nebula does not have a built-in relay like Tailscale DERP, so with symmetric NAT on both sides, connectivity will not be peer-to-peer. This must be considered when planning the topology—lighthouses should be placed on hosts with direct public IP without NAT. Typical P2P latency is 1–5 ms (we guarantee under 10 ms), certificate revocation recovery time is less than 1 second.
Why automate certificate rotation?
The CA key is the most critical part. Compromising the CA means completely replacing the entire Nebula PKI infrastructure. We recommend storing the CA key in HashiCorp Vault with the PKI secrets engine or in a separate offline storage. Certificate lifetime should be 90 days with automated rotation.
Script for automatic rotation via Vault:
#!/bin/bash
# rotate-nebula-cert.sh
NODE_NAME=$1
OVERLAY_IP=$2
GROUPS=$3
# Get CA from Vault
vault kv get -field=ca_key secret/nebula/ca > /tmp/ca.key
vault kv get -field=ca_crt secret/nebula/ca > /tmp/ca.crt
# Generate new certificate
nebula-cert sign \
-ca-crt /tmp/ca.crt \
-ca-key /tmp/ca.key \
-name "$NODE_NAME" \
-ip "$OVERLAY_IP" \
-groups "$GROUPS" \
-duration 2160h # 90 days
# Distribute via Ansible
ansible -i inventory "$NODE_NAME" -m copy \
-a "src=${NODE_NAME}.crt dest=/etc/nebula/host.crt"
ansible -i inventory "$NODE_NAME" -m service \
-a "name=nebula state=restarted"
# Clean up temp files
rm -f /tmp/ca.key /tmp/ca.crt
How Nebula solves the NAT problem?
WireGuard is great for point-to-point, but for a mesh with hundreds of nodes, you'd have to define every peer—that doesn't scale. IPsec is complex to configure and debug. Nebula provides PKI, dynamic peer discovery via lighthouse, and group-based firewall policies out of the box. For infrastructures with autoscaling and spot instances (where IPs change), it's the best choice. Our experience: over 5+ years we've deployed Nebula in 30+ projects, and never had scaling issues. Thanks to automatic hole punching, new nodes connect in seconds. Contact us—we'll audit your network and propose the optimal configuration. Switching to Nebula can save up to $12,000 per year on VPN licensing for 50 nodes.
What's included in turnkey Nebula setup
| Step | What we do | Result |
|---|---|---|
| Infrastructure audit | Assess NAT types, node count, clouds | Nebula topology diagram |
| CA and certificate generation | Create CA, sign certificates for each node | PKI infrastructure, Vault integration |
| Lighthouse deployment | Allocate public host, configure keepalived | Fault-tolerant lighthouse |
| Firewall policy configuration | Segment access by groups: prod, staging, monitoring | Zero-trust overlay network |
| Rotation and monitoring | Automation via Ansible + Prometheus/Grafana for alerting | Regular certificate renewal, SLO metrics |
| Documentation and training | Runbook, procedure description, 2 hours of team training | Team can independently add nodes |
Process
- Analysis—discuss requirements: which nodes, which clouds, need Vault integration.
- Design—create architecture: number of lighthouses, NAT zones, security groups.
- Implementation—deploy lighthouses, generate CA, sign certificates, configure configs via Ansible or Terraform.
- Testing—verify P2P connectivity, load testing, MTTR for failures.
- Deployment—connect production nodes, set up monitoring (Prometheus + Loki), hand over documentation.
Estimated timelines
| Scale | Time |
|---|---|
| 5–20 nodes, one lighthouse | 1–2 days |
| 20–100 nodes, multiple clouds, Vault PKI | 3–5 days |
| Edge devices + automated rotation | 5–7 days |
Savings on VPN licenses when switching to Nebula are up to 50% compared to commercial solutions, and we guarantee a minimum of 20% savings. The exact cost is calculated after auditing your infrastructure. Get a consultation—we'll propose the optimal deployment model. Our certified Nebula experts have over 5 years of hands-on experience with 30+ successful deployments.