A melhor maneira de tornar sua mudança permanente é usar sysctl em vez de escrever para / proc diretamente, já que esta é a maneira padrão de configurar os parâmetros do kernel em tempo de execução, para que eles sejam configurados corretamente na próxima inicialização:
# cat >> /etc/sysctl.d/99-bridge-nf-dont-pass.conf <<EOF
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-filter-vlan-tagged = 0
EOF
# service procps start
Quanto à resposta à pergunta na sua atualização ...
bridge-netfilter (ou bridge-nf) é uma ponte muito simples para IPv4 / IPv6 / Pacotes ARP (mesmo em 802.1Q VLAN ou PPPoE headers) que fornecem a funcionalidade para um firewall transparente com estado, mas funcionalidades mais avançadas como IP NAT transparente são fornecidas ao passar esses pacotes para arptables / iptables para processamento adicional - no entanto se os recursos mais avançados de arptables / iptables não forem necessários, a passagem de pacotes para esses programas ainda é ativada por padrão no módulo do kernel e deve ser desativada explicitamente usando sysctl.
Para que eles estão aqui? Estas opções de configuração do kernel estão aqui para passar (1) ou não passar (0) pacotes para arptables / iptables como descrito no bridge-nf FAQ :
As of kernel version 2.6.1, there are three sysctl entries for bridge-nf behavioral control (they can be found under /proc/sys/net/bridge/):
bridge-nf-call-arptables - pass (1) or don't pass (0) bridged ARP traffic to arptables' FORWARD chain.
bridge-nf-call-iptables - pass (1) or don't pass (0) bridged IPv4 traffic to iptables' chains.
bridge-nf-call-ip6tables - pass (1) or don't pass (0) bridged IPv6 traffic to ip6tables' chains.
bridge-nf-filter-vlan-tagged - pass (1) or don't pass (0) bridged vlan-tagged ARP/IP traffic to arptables/iptables.
É seguro desativar todos os bridge-nf - *? Sim, não é apenas seguro fazê-lo, mas há um recomendação para que as distribuições o desliguem por padrão para ajudar as pessoas a evitar confusão para o tipo de problema que encontrou:
In practice, this can lead to serious confusion where someone creates a bridge and finds that some traffic isn't being forwarded across the bridge. Because it's so unexpected that IP firewall rules apply to frames on a bridge, it can take quite some time to figure out what's going on.
e para aumentar a segurança :
I still think the risk with bridging is higher, especially in the presence of virtualisation. Consider the scenario where you have two VMs on the one host, each with a dedicated bridge with the intention that neither should know anything about the other's traffic.
With conntrack running as part of bridging, the traffic can now cross over which is a serious security hole.
ATUALIZAÇÃO: maio de 2015
Se você estiver executando um kernel mais antigo que 3.18, então você pode estar sujeito ao antigo comportamento de filtragem de ponte ativado por padrão; se você for mais novo que 3.18, então você ainda pode ser mordido por isso se tiver carregado o módulo de ponte e não tiver desativado a filtragem de ponte. Veja:
After all these years of asking for the default of bridge filtering to be "disabled" and the change being refused by the kernel maintainers, now the filtering has been moved into a separate module that isn't loaded (by default) when the bridge module is loaded, effectively making the default "disabled". Yay!
I think this is in the kernel as of 3.17 (It definitely is in kernel 3.18.7-200.fc21, and appears to be in git prior to the tag "v3.17-rc4")