Writing Nebula Firewall Rules
Updated: Mar 26
In my previous post on Nebula I covered how to set up a small network of systems with just the ability to ping each other and did not cover anything about Nebula firewall rules. In this post I will be covering how to use groups in the firewall rules of the Nebula config to control access to the systems.
First, recreate the certificates with groups specified and distribute them to their respective systems.
./nebula-cert sign -name "lighthouse1" -ip "192.168.100.1/24" -groups "lighthouses"
./nebula-cert sign -name "host1" -ip "192.168.100.10/24" -groups "site1"
./nebula-cert sign -name "host2" -ip "192.168.100.11/24" -groups "site2"
After ensuring that the nodes can communicate with each other with their new certificates, we need to make some changes to the firewall of the host, not the Nebula firewall. Nebula operates over a single port, the one that is specified in the config. Since I am leaving that as the default 4242, that is the only port I need to be able to access from a non-nebula IP address.
As you can see I am allowing port 4242 to my lighthouse from anywhere, but only allowing SSH if it comes from within the Nebula address range. An SSH request over Nebula will come into the system as port 4242 and then be checked against the firewall again after passing through Nebula. I put these firewall rules on both of the nodes as well. This host firewall setup will only allow access to the system over Nebula.
The three groups created are “site1”, “site2” and “lighthouses.” We can use the name of these groups, or even the name of the hosts in the rules. First I am going to change the lighthouse so that only the group “site1” can access it via ssh. Remember to restart Nebula after making changes in the config. Note: If you put multiple groups in a single rule, the requester must be part of all of those groups.
When trying to ssh from host1 to the lighthouse I get a login prompt, but when trying to ssh from host2 it doesn't connect.
I can allow access from host 2 by specifying the name we gave it in the Nebula certificate within the config as shown below. This gives both nodes access, host1 by its group membership, and host2 by its name.
On the nodes we will allow ICMP traffic from any Nebula host, but only allow ssh from the “lighthouses” group. On host1 I am going to allow ssh from the "site2" group as well.
We can see that the lighthouse can ssh to both nodes, host2 can ssh to host1, but host1 cant ssh to host2 but can ping it.
That is about all for the firewall rules. They are meant to function in a similar way to security groups from cloud providers but they are vendor agnostic. They are pretty simple to understand, and allow a lot of granularity.