Scott: /* TRAVEL SCENARIO: my current IP can't SSH in */

2026-07-02T22:56:25Z

TRAVEL SCENARIO: my current IP can't SSH in

← Older revision		Revision as of 22:56, 2 July 2026
Line 49:		Line 49:
	Options, in order of preference:		Options, in order of preference:

	# '''~~UCI~~ VPN''' — connect, then SSH from the VPN address (~~10.0.0.0/8 and~~ campus ranges are in <code>$ssh_nets_v4</code>).		# '''VPN''' — connect, then SSH from the VPN address (campus ranges are in <code>$ssh_nets_v4</code>).
	# '''IPMI console''' — log in via BMC, then fix from the console.		# '''IPMI console''' — log in via BMC, then fix from the console.
	# '''Temporary runtime rule''' from the console (does NOT survive reload/reboot):		# '''Temporary runtime rule''' from the console (does NOT survive reload/reboot):

Scott: Created page with "= nftables Cheat Sheet = Config: `/etc/nftables.conf` · table `inet filter` · chains `input` / `forward` / `output` Input policy is '''drop'''; SSH allowed only from `$ssh_nets_v4`. Out-of-band rescue: IPMI/BMC console (H5Viewer or Serial-over-LAN). == Everyday commands == # Syntax-check the config WITHOUT applying (always do this first) sudo nft -c -f /etc/nftables.con..."

2026-07-02T22:49:24Z

Created page with "= nftables Cheat Sheet = Config: <code>/etc/nftables.conf</code> · table <code>inet filter</code> · chains <code>input</code> / <code>forward</code> / <code>output</code> Input policy is '''drop'''; SSH allowed only from <code>$ssh_nets_v4</code>. Out-of-band rescue: IPMI/BMC console (H5Viewer or Serial-over-LAN). == Everyday commands == <syntaxhighlight lang="bash"> # Syntax-check the config WITHOUT applying (always do this first) sudo nft -c -f /etc/nftables.con..."

New page

= nftables Cheat Sheet =

Config: <code>/etc/nftables.conf</code> · table <code>inet filter</code> · chains <code>input</code> / <code>forward</code> / <code>output</code>

Input policy is '''drop'''; SSH allowed only from <code>$ssh_nets_v4</code>.

Out-of-band rescue: IPMI/BMC console (H5Viewer or Serial-over-LAN).

== Everyday commands ==

<syntaxhighlight lang="bash">
# Syntax-check the config WITHOUT applying (always do this first)
sudo nft -c -f /etc/nftables.conf

# Check + reload in one line (reload only runs if check passes)
sudo nft -c -f /etc/nftables.conf && sudo systemctl reload nftables

# Show the live ruleset
sudo nft list ruleset

# Show live ruleset WITH handles (needed for deleting single rules)
sudo nft -a list ruleset

# Just the input chain
sudo nft list chain inet filter input

# Service status / enabled at boot?
systemctl status nftables
systemctl is-enabled nftables
</syntaxhighlight>

== Am I being firewalled? (diagnosis) ==

<syntaxhighlight lang="bash">
# Watch the drop log live (rules log with prefix "nft drop: ")
sudo journalctl -kf | grep 'nft drop'

# Recent drops
sudo journalctl -k --since "1 hour ago" | grep 'nft drop'

# Counters: add a counter to a rule temporarily, or check conntrack
sudo conntrack -L | grep <ip> # is there an established session?
</syntaxhighlight>

Remember: broadcast/multicast is dropped '''silently''' (no log). Everything else that's dropped is logged at max 5/minute — absence of log lines does not mean absence of drops during a flood.

== TRAVEL SCENARIO: my current IP can't SSH in ==

Options, in order of preference:

# '''UCI VPN''' — connect, then SSH from the VPN address (10.0.0.0/8 and campus ranges are in <code>$ssh_nets_v4</code>).
# '''IPMI console''' — log in via BMC, then fix from the console.
# '''Temporary runtime rule''' from the console (does NOT survive reload/reboot):

<syntaxhighlight lang="bash">
# Allow one address into SSH, inserted before the drop logic takes effect
sudo nft insert rule inet filter input ip saddr <MY.IP.ADDR.HERE>/32 tcp dport 22 ct state new accept

# Verify
sudo nft list chain inet filter input

# Remove it later: find its handle, then delete
sudo nft -a list chain inet filter input
sudo nft delete rule inet filter input handle <N>
</syntaxhighlight>

For a permanent change, edit <code>$ssh_nets_v4</code> in <code>/etc/nftables.conf</code>, check, reload (see above). Runtime rules are lost on the next <code>reload</code> because the config starts with <code>flush ruleset</code>.

== Emergency: firewall is broken / I need it out of the way ==

<syntaxhighlight lang="bash">
# From the IPMI console ONLY — this leaves the box wide open:
sudo nft flush ruleset

# Restore known-good config
sudo nft -c -f /etc/nftables.conf && sudo nft -f /etc/nftables.conf
</syntaxhighlight>

== Reload interactions ==

* <code>flush ruleset</code> (any reload) '''wipes fail2ban's ban sets''' too. Restore them: <code>sudo systemctl restart fail2ban</code>
* Established connections (incl. your live SSH session) survive reloads — they match <code>ct state established</code>, not the <code>new</code> rules.

== After-reboot sanity check ==

<syntaxhighlight lang="bash">
systemctl is-active nftables && sudo nft list ruleset | head -20
</syntaxhighlight>

Empty ruleset after boot = config failed to parse = sshd exposed to everything. Check <code>journalctl -u nftables -b</code> for the parse error.

== Config gotchas (this file specifically) ==

* Comment block and <code>define ssh_nets_v4</code> must be kept in sync — every CIDR needs a documented reason.
* ICMPv6 rules are load-bearing: IPv6 breaks without NDP/PMTU. Don't trim.
* <code>output</code> policy is accept (egress open) — intentional, matches old script.
* SSH rate-limiting is fail2ban's job, not nft's. Don't add limit rules to the SSH accept line; they'll fight with ThinLinc multi-connections.

[[Category:Sysadmin]]
[[Category:Cheat sheets]]

Nftables - Revision history

Scott: /* TRAVEL SCENARIO: my current IP can't SSH in */