The Firewall Manager lets you allow or block specific IP addresses — or whole CIDR ranges — on your server’s own game ports, without touching a config file or learning iptables. Rules apply at the docker network layer, which means blocked packets are dropped before they ever reach your game server. This guide walks through exactly what the Firewall Manager does on a server you host with Loafhosts: where to find it, the quick-action presets, the Allow-my-IP chip, the plain-English preview that tells you what a rule will do before you save it, how pausing and removing rules works, and what the panel will and won’t let you block. Everything below describes the real behavior of the tool — no invented buttons or steps.
Where to Find It
Open your server in the panel, go to the Network area, and open the Firewall Manager. The page header reads “Firewall Manager” and carries a small status chip summarizing your current setup — for example “3 ports open · 2 block rules · 1 allow rule”. Directly beneath the header is a one-sentence posture strip that tells you, in plain language, whether any block rules are active and that blocked packets are dropped before they reach your game.
A firewall rule is always an IP-address-and-port pair targeted at one of your server’s own allocations. Each rule is either an allow or a block, and the manager keeps the full set saved in the panel and pushes it to the node every time you make a change. Managing rules requires the network/allocation permission on the server, so account owners and subusers granted that permission can add, pause, and remove rules.
Note: Rules apply at the docker network layer — blocked packets are dropped before they reach your game server.
Note: Every rule targets one of your server’s own allocated ports — you can’t write a rule against a port you don’t own.
Note: The header chip and the posture strip both update live as you add, pause, or remove rules.
Quick Actions: The Presets
Above the rule form is a Quick actions panel with four preset tiles. A preset doesn’t create a rule on its own — clicking one simply prefills the New Rule form so you can review it before saving. The four presets are:
- Block an IP — drop all traffic from one address or range on every port.
- Allow my IP — whitelist your current address, as a companion to a block rule.
- Block from one port — drop one address on a single chosen port only.
- Block my IP — lock your own address out, useful for confirming a rule actually takes effect.
The two presets that involve “my IP” only appear active when the panel can resolve your current public address. The Allow my IP and Block my IP tiles show your detected address as a subtitle; if the panel can’t determine a usable address, those tiles are dimmed and their subtitle reads that your IP is unavailable.
Tip: Use Allow my IP alongside a wider block rule so a range block never accidentally locks you out.
Tip: A preset only fills in the form — nothing is saved until you press Add Rule.
Tip: Block my IP is a safe way to prove a rule reached the node: add it, watch yourself get dropped, then remove it.
Building a Rule in the New Rule Form
The New Rule form has five fields and an Add Rule button. Type is Block or Allow. Source IP / CIDR accepts a single address like 1.2.3.4 or a range in CIDR notation like 1.2.3.0/24 (which covers 1.2.3.0 through 1.2.3.255). When the panel knows your own address, an “Allow my IP” chip sits next to this field — clicking it drops your address into the field and switches the rule type to Allow. Protocol is Both, TCP, or UDP, defaulting to Both; choosing TCP or UDP only narrows the rule. Label is an optional free-text note up to 120 characters, like “blocked attacker” or “allow whitelist”. Target Port is a dropdown listing your server’s allocations, with the primary allocation marked.
As you fill in the form, a plain-English preview sentence under it tells you exactly what the rule will do — for example, “This will block all traffic from 1.2.3.4 to port 2456 (primary).” The preview reflects the type, protocol, source address, and chosen port as you type, so there are no surprises when you save.
Tip: A single address and a /32 range mean the same thing — the panel stores a lone host without the redundant /32.
Note: The label is purely for your own reference; it’s truncated to 120 characters if you go over.
Note: The Target Port list only contains ports actually allocated to this server.
What the Panel Will Never Let You Block
The Firewall Manager has a hard safeguard: it will not let you block addresses that the panel and its infrastructure depend on, because doing so could cut the panel off from your server. A “What’s protected” disclosure at the bottom of the page spells this out — the panel will never block its own host or any node FQDN, Wings/daemon control traffic, your server’s loopback and internal docker networks, or any IP an admin has flagged as monitoring or backup infrastructure.
Those checks run server-side before a rule is ever saved, so a bad entry is rejected with a clear message rather than silently applied. The panel rejects private, loopback, link-local, multicast, and other reserved ranges (it’ll tell you the range is reserved for the panel and infrastructure). It rejects a CIDR mask outside the /8-to-/32 window, and it rejects any rule — even a wide range or a catch-all — that would swallow a Loafhosts infrastructure address. Only IPv4 source addresses are supported. And if you try to add the same IP and port twice, the panel tells you that rule already exists rather than creating a duplicate.
Note: You can’t block infrastructure even with a wide CIDR — a range that would contain a protected address is rejected outright.
Note: Source addresses must be IPv4; the docker-bridge firewall doesn’t handle IPv6.
Tip: If a rule is rejected, read the message — it names the exact range or address that caused the rejection.
Pausing, Removing, and the Active Rules List
Saved rules appear in the Active Rules list, each shown with a colored Block or Allow badge, a plain-English summary (“Blocking TCP 1.2.3.4 on port 2456”), the raw address, the target port and its allocation, and two controls: a pause/resume switch and a Remove button. A paused rule is dimmed and labeled “Paused”. When you have no rules at all, the list reads “No rules yet — your server accepts traffic on all allocated ports.”
The pause/resume switch is the safest way to take a rule out of play temporarily. Pausing a rule removes it from the set pushed to the node, and because pausing a block rule only ever opens access back up, toggling a rule can never strand your server. Remove deletes the rule outright after a confirmation prompt. Both pausing and removing immediately re-push the remaining enabled rules to the node.
Tip: Pause instead of remove when you want to lift a block briefly — flip the switch back to restore it exactly as it was.
Note: Only enabled rules are pushed to the node; a paused rule is simply absent from what the node enforces.
Note: Removing a rule asks you to confirm first, since it can’t be undone.
Live Status, Drift, and Re-sync
When your node is reachable, a live status strip shows whether your saved rules are actually applied on the node. A green “Live on node” strip confirms your active rules match what’s saved. If the live set has drifted — for instance after a node restart, which can wipe live iptables rules — an amber “Drift detected” strip appears, names how many saved rules aren’t active, and offers a Re-sync button to re-apply them. Re-syncing simply re-pushes your saved ruleset to the node.
On nodes that report packet counters, each rule row also shows a hit chip: a “dropped” count once packets have matched, “no matches yet” if none have, or a presence indicator on daemons that don’t report counters. If the node is unreachable, the panel doesn’t fake a state — the live strip and hit chips simply don’t appear, and your saved rules are still in place. Saving a rule is also resilient: if the node can’t be reached at the moment you add a rule, the rule is still saved and the panel tells you it’ll apply on the next sync, with a Retry sync option.
Note: Node restarts can wipe live iptables rules — that’s what the drift strip and Re-sync button are for.
Tip: A rising “dropped” count on a block rule is the clearest sign it’s working — that’s traffic your game server never had to handle.
Note: If the panel can’t reach the node, your rule is still saved and applied on the next sync — nothing is lost.