Skip to content
+1 (813) 212-3723 [email protected]

Cloud firewall

A cloud firewall outside the guest, with individual rules or reusable firewall groups.

4 min read

Every server has a LayerOne cloud firewall outside the guest, edited from the Firewall 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.

The Firewall tab

The top of the tab says what the firewall is doing (for example Filtering inbound traffic or Allowing all traffic), with the default policies, how many rules you have, and when the rules were last applied.

Below that are two tables, Inbound rules and Outbound rules, in the order they are checked. Each table ends with Everything else: the default policy for traffic no rule matches. Select Change on that row to switch it between Allow and Deny.

Select Add rule to add one. Pick a common type (SSH, HTTP, HTTPS, MySQL, PostgreSQL, RDP, DNS, Ping, All traffic) or Custom to fill in the protocol and port, then choose who it applies to: Anywhere, My IP (the address you are browsing from) or a custom address or CIDR. New rules go to the end of their table. To change a rule, delete it and add it again.

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.

Field Values
Direction Inbound or outbound (in, out)
Action Allow, Drop or Reject (ACCEPT, DROP, REJECT)
Protocol tcp, udp, icmp, or any
Port 443, or a range like 30000:30010
Source / destination An address or CIDR
Comment Up to 80 characters

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, then Firewall groups under Security. Select Create group, add its rules and policies, then assign servers from your account. Firewall groups are included at no cost. You can assign up to 8 groups to the same server, and reuse each group on several servers. Changes apply to every assigned server.

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 server has assigned groups, its Firewall tab shows the combined policy and rules, each labelled with the group it comes from, and hides the controls for the server's own rules. The individual configuration stays saved. Removing the last group restores it and enables individual controls again. Remove every server from a group before deleting it.

Each assigned server shows whether the rules are applied. If applying a change fails, the group remains saved and you can select Sync again on 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.

You are never truly locked out

The browser console is out of band and does not go through this firewall.

A default-deny starting point

Do these in order:

  1. Select Add rule and choose SSH, from My IP if your address is static, or from Anywhere if it is not.
  2. Add HTTP and HTTPS if the server serves web traffic.
  3. Add Ping, so ping and path MTU discovery still work.
  4. In Inbound rules, select Change on Everything else and choose Deny.

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

Do not drop all ICMP

Blocking ICMP entirely breaks path MTU discovery, which shows up later as large transfers hanging for no visible reason.

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"}'
Still stuck

Ask AI or open a ticket.

Ask AI in the portal answers from these docs. For anything it cannot settle, open a ticket and an engineer replies by email.