Firewall rules
Firewall rules decide which traffic a host accepts from other hosts on a Managed Nebula network. Every host runs Nebula’s built-in stateful firewall, which checks each packet that arrives over the overlay before it reaches the operating system. Anything a rule doesn’t allow is dropped.
How rules work
Section titled “How rules work”Rules only describe inbound traffic. The firewall is stateful, so replies to connections a host opens itself are let back in without a rule.
You attach rules to a role, where they apply to every host with that role, or to a tag, where they apply to every host carrying it. Each rule has a protocol (any, TCP, UDP, or ICMP), an optional port range, and the hosts allowed to connect, identified by role, by tags, or both. A rule that names no role and no tags allows any host on the network.
A new role allows only ICMP, so ping works for troubleshooting. Everything else is denied until you add a rule for it.
For example, these three rules let every user device reach the web servers over HTTPS, let only admins SSH into them, and let only the web servers reach the database:
| Rule on | Protocol | Ports | Allowed from |
|---|---|---|---|
webserver role | TCP | 443 | user-device role |
webserver role | TCP | 22 | hosts tagged user-type:admin |
database role | TCP | 5432 | webserver role |
Rules based on identity
Section titled “Rules based on identity”Rules match hosts by role and tag rather than IP address. A host’s role and tags are written into its certificate and proven during the handshake, so spoofing an address or moving to another network doesn’t get a host past a rule. The same rules apply whether a host is in a data center, at home, or on a phone hotspot, which is how Managed Nebula applies zero trust networking.
You manage rules in one place, in the admin panel or the API, and changes reach the affected hosts automatically. There are no iptables rules or security groups to keep in sync for overlay traffic.
Nebula’s firewall only filters traffic arriving over the overlay. Traffic to a host’s underlay address, like its LAN or public IP, is still up to the host’s own firewall. Routes to subnets that can’t run DNClient have their own firewall rules, which can also limit access to specific addresses in the subnet (see Extend network access beyond overlay hosts).
For a walkthrough, see Creating firewalls using roles and tags.