cc63efa9682eeaeb3a9fb835348fc7cd4c1a9f20
Confirmed on the operator's NAS. The earlier advice (insert an ACCEPT rule ahead of DSM's chain) does not hold: DSM reloads its firewall periodically, flushing and rebuilding the chains. You can watch FORWARD_FIREWALL's DROP counter reset to zero and the inserted rule vanish with it, having matched no packets. That is also why the symptom looked intermittent — 60/40 success on repeated connections, with RELATED,ESTABLISHED keeping existing flows alive. The fix is one level down: net.bridge.bridge-nf-call-iptables=0 takes same-bridge traffic out of iptables entirely, so DSM's reloading cannot affect it. Persisted with a Boot-up Triggered Task. Section 8 now also answers "is that safe", accurately: the flag affects only packets bridged within one network. Traffic between different Docker networks is routed, so DOCKER-ISOLATION still applies; inbound traffic to published ports is still routed and still firewalled; INPUT, which protects the NAS itself, is untouched. The one real caveat is that it is host-wide, so VMs sharing a bridge lose same-bridge filtering too. The migrate failure message points at the sysctl now. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Nux3LCu4zP9nih4BRhPyHw
Description
No description provided
11 MiB
Languages
Python
57.3%
TypeScript
31.7%
JavaScript
8.1%
Shell
1.5%
HTML
0.8%
Other
0.5%