Skip to content
+1 (813) 212-3723 support@layeronecloud.com
Networking

Cloud firewall

A cloud firewall outside the guest. Default allow, with up to 40 rules per server.

2 min read Reviewed 24 Aug 2026

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.

Field Values
Direction in, out
Action 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 rules per server.

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 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.

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

Chat with us from the portal.

Ask the assistant from the Chat bar. During business hours you can ask for a person and a human joins live.