Arma Reforger Whitelisting, Bans and Spotting Ban Evaders

Reforger's access control is thinner than most server admins expect, and the pieces do narrower jobs than their names suggest. This covers the two that are unambiguous — the join password and the visibility toggle — plus how bans behave and why they stop working.

Making a server private#

Two fields, doing genuinely different jobs.

{
    "game": {
        "password": "yourjoinpassword",
        "visible": true
    }
}

game.password is real access control. Without it, no join.

game.visible: false removes the server from the public browser. This is not access control — anyone who has the address can still connect directly. It makes a server undiscoverable, not private.

For most private communities a password on a visible server is the right setup: findable by people you have told, closed to everyone else.

If a password is not enough#

Wanting per-identity control, an application process, or reserved staff slots is reasonable, and there are options beyond a shared password — panel features and Workshop mods both exist in this space, and support varies by host and by build. Check your host's documentation and the official server config reference (linked below) for what yours supports rather than copying a config snippet from a forum.

Two things worth knowing whichever route you take:

1. Anything mod-based is subject to version drift. An access-control mod that breaks on update fails in one of two directions, and "fails open" on a server you thought was closed is the bad one. Lock the version — see mod collections and version locking.
2. Slot reservation is not access control. operating.slotReservationTimeout (5–300 seconds, default 60) controls how long a reserved slot is held, and pairs with joinQueue.maxSize on a busy server. Neither restricts who can join.

There is one identity-based mechanism that is unambiguous: game.admins accepts up to 20 IdentityIDs or Steam IDs, and those players can elevate without the admin password. That is staff access, not general access, but it is the right tool for the staff half of the problem — see admins and RCON.

Bans, and why they stop working#

Bans are managed with the #ban command, which takes create, remove and list, keyed on the playerId that #players reports. Either from in-game chat as an elevated admin, or over RCON — see admins and RCON for the setup.

That works exactly once per account. Reforger accounts are not expensive to replace, so anyone motivated enough to be worth banning is often motivated enough to come back. Identity bans handle the careless; they do not handle the committed.

Practical habits that make bans hold up better:

• Record why. A ban with no reason attached is a ban a different admin will reverse, or re-litigate with the player six months later.
• Capture evidence at the time. Names change. Sessions end. Logs roll over. The moment you decide to ban is the moment to capture what happened.
• Ban the identity you verified, not the display name. Names are freely changeable and are the wrong key for anything durable.
• Keep the list somewhere durable. A ban list that lives only on one server is lost when that server is rebuilt, and does not apply if you run more than one.

Recognising evasion#

You cannot prevent a new account. You can recognise one, and that is the part that actually reduces repeat problems.

The signals worth watching:

• A new account with established behaviour. Someone who joins for the first time and immediately knows your map, your rules and your staff by name is not new.
• Connection characteristics that match a banned account. A VPN connection appearing shortly after a ban, from an account created around the same time, is a pattern rather than a coincidence.
• Name history. Renaming to something close to a previously banned name is more common than it sounds.
• Session timing. A returning evader tends to reappear in the same slots they always played.

Individually, none of these is proof. Together they are usually enough to act on, and the reason to have them in front of you is that reconstructing them after the fact from raw logs rarely happens — it is too much work at the moment you need it.

When the problem is not a player#

Two adjacent problems get misread as griefing or evasion:

Cheating is BattlEye's job, not yours. Confirm game.gameProperties.battlEye is true — it is by default, but a config copied from a testing setup may have it off.

Attacks on the server are not moderation at all. If your server drops under load, disconnects everyone at once, or becomes unreachable during a session, that is a network problem rather than a player problem — and it is common on Reforger servers with an active community. Our Arma Reforger DDoS protection covers how we filter it.

Verify it worked#

1. Validate config.json in the config validator, then restart.
2. Confirm the password is actually enforced — try joining without it. Do not assume from the config.
3. Confirm your own members can still find and join the server. A visibility change that locks out your community is a real outcome.
4. If you use any identity-based access control, test that a non-approved account is refused. Testing that an allowed account gets in proves nothing about whether the restriction works.
5. Create a test ban with #ban create and confirm the banned identity cannot rejoin.
6. Confirm battlEye is true.

Trusted references#

• Arma Reforger: Server Config — the password, visibility and admin fields
• Arma Reforger: Server Management — the #ban and #kick reference
• Arma Reforger Workshop — where admin and access-control mods live