Firewall¶
Eight.ly OS manages firewalling at two levels: a host firewall that protects the box itself, and a per-VM firewall that controls traffic to and from individual virtual machines. Both are enforced — rules you save here are actually applied to the kernel, not just stored.
Host firewall¶
Where to find it: Infrastructure > Node > Firewall tab, or Infrastructure > Datacenter > Firewall (same firewall, reached two ways).
The host firewall is built on nftables, not UFW. Eight.ly keeps everything it manages in its own table so it never touches rules that Docker, libvirt, or LXC add to the system.
Built-in lock-out prevention¶
Two things make it hard to fence yourself out of your own box:
- SSH (port 22) and the dashboard (port 8080) are always allowed, ahead of every rule you add and ahead of the default policy. A rule that would block one of these is rejected outright rather than silently doing nothing.
- A "deny" policy is never applied as the chain's default. The chain itself always accepts; a deny policy is added as the last rule in the chain instead. If the ruleset ever failed to load or loaded only partway, the box fails open — reachable — rather than sealed shut with no way back in.
- Turning the firewall on, or saving a policy change that could reduce what reaches you, goes through a confirm screen with a countdown: the change is applied immediately, and if you don't click Confirm within the window it automatically reverts. This catches a policy that would have locked out the page you're looking at.
Default state¶
A box that has never had its firewall configured accepts everything, on every chain (input, output, forward) — the firewall is off by default. You turn it on and add rules or a default policy from the Options sub-tab.
Managing rules¶
From the Options sub-tab:
- Firewall Enabled — turns the managed firewall on or off
- Input / Output / Forward policy — ACCEPT, DROP, or REJECT for traffic nothing else matched
- Log rate limit — how often denied packets are logged (e.g.
5/second) - Individual allow/deny rules by port, protocol, and source
Security Groups, Aliases, and IP Sets¶
These live under Infrastructure > Datacenter > Firewall alongside Options, as their own sub-tabs, and they apply to the host firewall above — there's no way to attach a security group, alias, or IP set to an individual VM's firewall.
| Sub-tab | What it does |
|---|---|
| Security Groups | Reusable named sets of rules |
| Aliases | Named IP addresses or ranges, e.g. office for a CIDR block |
| IP Sets | Groups of IPs/CIDRs for bulk matching in a rule |
| Log | Recent denied-traffic log entries |
Aliases and IP sets resolve into real nftables sets when you save — they're not just labels the UI remembers.
Per-VM firewall¶
Where to find it: Infrastructure > VM > Firewall tab
Each VM gets its own dedicated iptables chain, hooked into the host's FORWARD chain and matched on that VM's network interface — so a rule here affects only that VM, not the host or any other guest.
Features¶
| Feature | Description |
|---|---|
| Rules | Add/delete rules by direction (in/out), action (accept/drop), protocol, port, and source |
| Enable/disable | Toggle the VM's firewall chain without deleting the rules in it |
| Options | Per-VM default policy (in/out), plus DHCP, NDP, MAC filter, and IP filter toggles |
Security Groups, Aliases, and IP Sets are a host-level feature (see above) and don't apply here — a VM's rules are simple, self-contained, and don't reference the Datacenter objects.
When to use which¶
- Host firewall — what reaches the box itself: the dashboard, SSH, any port a Docker app publishes directly to the host.
- Per-VM firewall — what reaches a specific virtual machine, independent of what the host allows.
Neither replaces the other. A VM's own firewall rules still apply even if the host firewall is off, and vice versa.
See the Security Model guide for the rest of Eight.ly's access-control picture.