Cloud firewall

Every server has a LayerOne cloud firewall outside the guest, edited from the Network tab on the server's page. It runs outside the guest, so it keeps working when the guest is misconfigured, compromised, or has its own firewall turned off.

It is not a replacement for a host firewall. Run both.

Defaults

Inbound and outbound both default to ACCEPT, matching what ships at provision. A new server is wide open at this layer.

Policies and rules

Set a default policy per direction, then add ordered rules that are evaluated before it.

DROP discards silently. REJECT answers, so the client fails fast instead of timing out. Use DROP for anything facing the internet.

Up to 40 individual rules per server, or 40 rules per Firewall Group.

Firewall Groups

Open Networking → Security → Firewall Groups, directly below Aegis. Create a named group, add its rules and policies, then assign devices from your account. You can assign up to 8 groups to the same device, and reuse each group on multiple devices. Changes apply to every assigned device.

Groups are evaluated in creation order, with rules inside each group evaluated in their listed order. The first matching rule wins. For unmatched traffic, the default for each direction is Deny if any assigned group uses Deny; otherwise it is Allow.

While a device has assigned groups, its Network tab displays the combined policy and rules and disables individual firewall management. The individual configuration stays saved. Removing the last group restores it and enables individual controls again. Remove all device assignments before deleting a group.

Each assigned device shows its latest sync result. If applying a change fails, the group remains saved and you can retry from the group's page. A saved change with an error has not been confirmed as applied.

The server firewall API returns the effective group policy with managed_by_groups: true and a groups list. Individual policy and rule writes return 409 while groups are assigned.

Locking yourself out

Switching the inbound policy to DROP without a rule allowing TCP 22 removes SSH. The portal makes you confirm, and the API requires confirm_ssh_lockout: true, because sometimes that is exactly what you meant.

A default-deny starting point

Do these in one edit, in this order:

1. Add inbound ACCEPT for TCP 22 from your own address if it is static, or from anywhere if it is not.
2. Add inbound ACCEPT for TCP 80 and 443 if it serves web traffic.
3. Add inbound ACCEPT for ICMP, so ping and path MTU discovery still work.
4. Set the inbound policy to DROP.

Leave outbound on ACCEPT unless you have a specific reason. Outbound DROP breaks package updates, NTP and DNS until you allow them explicitly.

Intended state versus applied state

What you save is stored as the intended policy and then applied to the network. If that sync fails, the intent is kept and the tab shows the error, so the next save or a reinstall's network step can catch up. A rule that shows an error has not taken effect yet.

From the API

# Read it
curl https://layeronecloud.com/api/v1/servers/4192/firewall \
  -H "Authorization: Bearer $LAYERONE_API_KEY"

# Allow SSH, then close everything else inbound
curl -X POST https://layeronecloud.com/api/v1/servers/4192/firewall/rules \
  -H "Authorization: Bearer $LAYERONE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"direction": "in", "action": "ACCEPT", "protocol": "tcp", "port": "22"}'

curl -X PUT https://layeronecloud.com/api/v1/servers/4192/firewall \
  -H "Authorization: Bearer $LAYERONE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"inbound_policy": "DROP", "outbound_policy": "ACCEPT"}'

Related

• Harden a new server
• Your first hour on a new server