Firewall implementation and netfilter management are different settings
Tailscale on Linux exposes two axes that are easy to confuse. Firewall mode selects whether tailscaled manipulates rules through the iptables binary or the nftables Netlink API. Netfilter modes on, nodivert, and off define how far Tailscale creates and connects its rules. Changing netfilter mode to off after an iptables-not-found message mixes these separate decisions.
In iptables firewall mode, Tailscale requires a compatible iptables binary in PATH. The nftables implementation uses the Netlink API rather than the nft CLI. Absence of the nft command alone therefore does not prove that nftables mode is unavailable.
Capture the complete selection sequence, not one error line
| Log or state | Meaning | Next check |
|---|---|---|
| using iptables | The iptables implementation was selected | Verify the binary and compatible backend. |
| iptables not found | The selected implementation could not run its binary | Inspect PATH and package state. |
| falling back to nftables | A different implementation is being attempted | Read the final mode immediately after it. |
| using nftables | The Netlink implementation is active | Verify Tailscale rules and connectivity. |
| procd crash loop | Daemon initialization repeatedly failed | Preserve the complete first failure. |
Collect read-only evidence first. Full journals, status, and UCI configuration can contain authentication keys and device identifiers, so save them in a private temporary directory. A failed collection command is not valid evidence. Share only redacted error categories and the selected implementation; retain or remove originals under your own policy after diagnosis.
umask 077
DIAG_DIR=$(mktemp -d "${TMPDIR:-/tmp}/tailscale-diag.XXXXXXXX") || exit 1
tailscale version
command -v iptables
iptables --version
sudo journalctl -u tailscaled -b --no-pager >"$DIAG_DIR/tailscaled.log" 2>&1
tailscale status --json >"$DIAG_DIR/status.json" 2>&1OpenWrt uses its init system and logread instead of a systemd journal. Keep one restart interval together so a successful fallback is not mistaken for a terminal crash loop.
umask 077
DIAG_DIR=$(mktemp -d /tmp/tailscale-diag.XXXXXX) || exit 1
/etc/init.d/tailscale status
logread -e tailscale >"$DIAG_DIR/tailscaled.log" 2>&1
uci export tailscale >"$DIAG_DIR/tailscale.uci" 2>&1Branch on the final state after the error
- The iptables error is followed by using nftables and the node is online: do not classify the isolated warning as an outage. Test the Tailscale IP and the routing feature actually in use.
- The daemon exits after the iptables error: identify which firewall implementation the installed Tailscale and distribution package expect. Install the distribution’s compatible iptables package or select nftables using its supported package configuration.
- The binary exists but execution fails: inspect PATH, execute permission, iptables backend, and container capabilities. Presence of a binary does not prove permission to change rules.
- Custom rule order breaks connectivity: the issue may be netfilter mode and ordering rather than implementation selection.
nodivertcreates rules without activating them, so manual jumps or hooks are required.
Do not use off as a quick repair
With netfilter mode off, Tailscale does not create or manage firewall rules. The operator becomes responsible for tailscale0 traffic, the Tailscale UDP listener, and NAT required by subnet routing and exit nodes. Basic connectivity may appear to return while routing behavior or spoofing protection is missing.
nodivert is not automatic either. For iptables, the operator must add jumps to Tailscale chains; for nftables, the chains need registration at hooks. Keep the default on mode unless there is a specific requirement to control rule order with another firewall manager.
tailscale set --help
tailscale ping <PEER>Changing netfilter-mode is a mutation, not a query. Record the current on/nodivert/off value and private service-environment or UCI configuration, and keep a separate working management path before changing it. Read the installed OpenWrt package definition for option names; do not guess UCI keys.
When implementation testing is necessary
Tailscale exposes TS_DEBUG_FIREWALL_MODE to test iptables, nftables, or auto selection, but documents it as a temporary mechanism that should not be treated as permanently supported. On Linux, back up /etc/default/tailscaled and test one implementation at a time. An OpenWrt package can expose a UCI option instead, so do not copy the Linux file path onto OpenWrt.
OpenWrt packages issue 27740 records an iptables error on the 24.10.3 and Tailscale 1.80.3-1 combination. One reported environment does not prove a root cause for every OpenWrt installation. Compare the current package version and the complete fallback sequence first.
Verification and rollback
After repair, test more than the daemon online state. Exercise peer connectivity and the subnet-route or exit-node feature used by the system. Preserve rule listings to confirm that Tailscale chains exist and are connected to an active path. Reload the host firewall manager and verify that the result persists.
If the daemon fails in the new mode, restore only the changed service-environment or UCI items and the recorded previous netfilter mode. Forcing on is not rollback if the previous value was nodivert or off. Package installation or removal is a separate change requiring firmware and feed compatibility checks. Applying and restoring settings on a real OpenWrt device was not reproduced here.
Related guides
Official references
- Tailscale firewall mode – iptables binary, nftables Netlink, and temporary implementation selection
- Tailscale netfilter modes – rule-management responsibility in on, nodivert, and off
- tailscaled configuration file – netfilterMode configuration scope
- OpenWrt packages issue 27740 – a public OpenWrt case distinguishing an iptables error from nftables fallback
Earlier verification notes preserved from this article
Verification level: official documentation checked
Tailscale firewall implementation and netfilter management were separated using official documentation. The public OpenWrt issue is treated only as one case and not generalized into a defect affecting every package version.