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:
- Add inbound
ACCEPTfor TCP 22 from your own address if it is static, or from anywhere if it is not. - Add inbound
ACCEPTfor TCP 80 and 443 if it serves web traffic. - Add inbound
ACCEPTfor ICMP, sopingand path MTU discovery still work. - 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"}'