I set up a bridge br0 "attached" to two interfaces:
eth0, my physical interface connected to the real LAN,vnet0, a KVM virtual interface (connected to a Windows VM).And I have this single firewall rule in the forward chain:
iptables -A FORWARD -j REJECT
Now, the only ping that is working is from the VM to the host.
The br0 interface owns the IP address of my host machine. eth0 and vnet0 do not "own" any IP, from the host point of view. The Windows VM has a static IP configuration.
If change my iptables rule to ACCEPT (or even use a more restrictive iptables -A FORWARD -o br0 -j ACCEPT), everything is working fine! (i.e. I can ping any LAN machine from the VM, and the other way round too).
All IP forwarding kernel options are disabled (like net.ipv4.ip_forward = 0).
So, how can the netfilter firewall block something that is not even enabled?
Furthermore, the VM - LAN traffic should only imply eth0 and vnet0. Yet it looks like allowing FORWARD traffic with -o br0 "works" (I did not check very carefully though).
The comment from Stéphane Chazelas provides the hint to the answer.
According to Bridge-nf Frequently Asked Questions bridge-nf enables iptables, ip6tables or arptables to see bridged traffic.
As of kernel version 2.6.1, there are five sysctl entries for bridge-nf behavioral control:
bridge-nf-call-arptables - pass bridged ARP traffic to arptables' FORWARD chain.bridge-nf-call-iptables - pass bridged IPv4 traffic to iptables' chains.bridge-nf-call-ip6tables - pass bridged IPv6 traffic to ip6tables' chains.bridge-nf-filter-vlan-tagged - pass bridged vlan-tagged ARP/IP traffic to arptables/iptables.net.bridge.bridge-nf-filter-pppoe-tagged - pass bridged pppoe-tagged IP/IPv6 traffic to {ip,ip6}tablesYou can disable netfilter firewall blocking with:
# sysctl -w net.bridge.bridge-nf-call-iptables=0
# sysctl -w net.bridge.bridge-nf-call-ip6tables=0
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments