Firewall config 2026

1. fail2ban Cheat Sheet

Config: `/etc/fail2ban/jail.local` (jails) · `/etc/fail2ban/fail2ban.local` (daemon) Backend: **systemd journal** (not log files) · Ban action: **nftables** Jail: `sshd` · maxretry 4 · findtime 10m · bantime 1h Bans trigger on **auth failures**, not connection counts.

---

1. 1. Status & inspection

```bash

1. Daemon alive?

sudo systemctl status fail2ban sudo fail2ban-client ping # should answer "pong"

1. Which jails are running?

sudo fail2ban-client status

1. The sshd jail: current bans, totals, failure counts

sudo fail2ban-client status sshd

1. Watch fail2ban's own log live

sudo journalctl -u fail2ban -f

1. See the auth failures fail2ban is reading (same source it uses)

sudo journalctl -u ssh --since "1 hour ago" | grep -i fail ```

1. 1. Bans: check / remove / add

```bash

1. Is a specific IP banned? (listed under "Banned IP list")

sudo fail2ban-client status sshd

1. UNBAN an address (the "I locked myself out" fix — run from IPMI console)

sudo fail2ban-client set sshd unbanip <ip>

1. Unban everything in the jail

sudo fail2ban-client unban --all

1. Manually ban an address

sudo fail2ban-client set sshd banip <ip> ```

The actual block lives in nftables — verify with:

```bash sudo nft list ruleset | grep -A5 f2b ```

1. 1. TRAVEL SCENARIO: I banned myself

Symptoms: SSH connects then drops instantly, or times out, from one specific location — while the VPN or another network works fine.

1. Get in another way (UCI VPN, IPMI console, or another host). 2. `sudo fail2ban-client status sshd` → confirm your IP is listed. 3. `sudo fail2ban-client set sshd unbanip <your-ip>` 4. Fix whatever failed auth 4× in 10 min (wrong key? stale agent?

  password typos?). Otherwise you'll be banned again in minutes.

5. Worst case, do nothing: bantime is **1 hour**, then it clears itself.

Note: with the minimal `ignoreip`, your travel IPs are NOT exempt. Four bad auth attempts from the hotel wifi = 1-hour ban. Use keys, and check `ssh -v` output before retrying blindly.

1. 1. Config changes

```bash

1. Test config without applying

sudo fail2ban-client -t

1. Reload after editing jail.local (keeps existing bans by default)

sudo fail2ban-client reload

1. Full restart (re-reads everything; bans are restored from the
2. persistent sqlite DB at /var/lib/fail2ban/fail2ban.sqlite3)

sudo systemctl restart fail2ban ```

1. 1. Interaction with nftables

- Any `nft flush ruleset` / `systemctl reload nftables` **wipes the

 f2b ban sets**. fail2ban still *thinks* they're banned. Fix:
 `sudo systemctl restart fail2ban` after firewall reloads.

- Ban actions: `nftables-multiport` (per-jail ports),

 `nftables-allports` for allports bans.

1. 1. Current policy notes (jail.local)

- `ignoreip` — keep minimal: loopback + witchetty's /32 (backup source).

 Anything listed here can brute-force sshd forever without a ban.

- Consider `bantime.increment = true` in `[DEFAULT]` for escalating

 bans on repeat offenders.

- `allowipv6 = auto` lives in **fail2ban.local** `[Definition]`,

 not jail.local (daemon setting, silences the startup warning).

1. 1. Quick triage flowchart

``` Can't SSH in? ├─ Works from VPN but not current IP? │ ├─ IP not in $ssh_nets_v4 → nft issue (see nft sheet: temp rule) │ └─ IP in allowed range → probably banned → unbanip ├─ Works from nowhere? │ ├─ nftables ruleset empty/broken → nft sheet, IPMI console │ └─ sshd itself down → journalctl -u ssh -b └─ Connects but auth fails? → not a firewall problem; check keys/PAM ```