🔄 Why Earlier Attempts to Persist the iptables Rule for Port 18080 on DietPi Failed

🧩 Current Setup Summary

• System: DietPi (Debian-based, minimal)

• Firewall: iptables with a ts-input chain (Tailscale or custom)

• Monero Daemon: monerod running with --p2p-bind-ip=0.0.0.0

• Problem: No incoming P2P connections

⚠️ Core Issue: The ts-input Chain Isn’t Available Early Enough

• The custom iptables chain ts-input (used by Tailscale or similar) is created late in the boot process or dynamically after many system services start.

• Any firewall rule referencing ts-input applied before this chain exists will fail silently or produce errors like:

  iptables: No chain/target/match by that name.

• This timing issue is the root cause why most standard methods to persist rules don’t work on this setup.

📝 Review of Earlier Approaches and Why They Failed

1. 🧰 Using iptables-persistent

• Saves rules to /etc/iptables/rules.v4 and restores them on boot automatically.

• Fails because the ts-input chain doesn’t exist yet when the restore process runs.

• Result: The rule referencing ts-input is ignored or dropped and does not persist after reboot.

2. ⚙️ Basic systemd Service Applying the Rule on Boot

• A one-shot systemd service running after network-online.target tried to insert the rule.

• Since ts-input chain creation happens after or asynchronously to the network target, the service runs too early.

• Rule insertion fails with “No chain/target/match by that name,” and no retry is attempted.

• No rule is applied.

3. ⏰ Cron Job with @reboot Directive

• Cron jobs run early after reboot, often before ts-input chain exists.

• A sleep delay helps but is unreliable due to race conditions in chain creation timing.

• Lack of checks and retries means the rule often doesn’t get applied.

• Logs for troubleshooting may be missing or incomplete.

🔧 Why Our Final Workaround Works

• The custom script polls repeatedly (up to 60 seconds), waiting for the ts-input chain to appear before applying any rule.

• It cleans up duplicate rules to keep firewall rules tidy on repeated runs.

• The systemd service depends on both network and Tailscale daemons to start, improving timing.

• Logs output are captured for troubleshooting and verification.

• Together, these ensure the rule is only applied once the chain exists, solving the timing/race condition problem.

📌 Summary