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:
- Select Add rule and choose SSH, from My IP if your address is static, or from Anywhere if it is not.
- Add HTTP and HTTPS if the server serves web traffic.
- Add Ping, so
pingand path MTU discovery still work. - 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"}'