[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH] nwfilter: enable bridge netfilter calls via proc filesystem

 On 09/23/2010 05:31 AM, Daniel P. Berrange wrote:
On Wed, Sep 22, 2010 at 03:35:54PM -0400, Stefan Berger wrote:
  On 09/22/2010 02:49 PM, Daniel P. Berrange wrote:
On Wed, Sep 22, 2010 at 02:19:31PM -0400, Stefan Berger wrote:
  On a recent installation of FC13, the filtering of IP/IPv6 using
iptables/ip6tables traffic did not work since the proc filesystem
entries /proc/sys/net/bridge/bridge-nf-call-iptables and
/proc/sys/net/bridge/bridge-nf-call-ip6tables contained a zero each and
no traffic went into the FORWARD chain. The patch below makes sure that
if iptables or ip6tables are being used by the nwfilter driver that a
'1' is written into the relevant proc filesystem entry so that the
traffic goes into the FORWARD chain.
NACK to this. We need to figure out how to make this filtering
work with them set to 0. The change to set them to 0 by default
is explicitly done for the benefit of virtualization, otherwise
guest traffic gets blocked by regular host firewall rules which
is not desirable. eg run system-config-firewall and block ssh
port on the host, and you've blocked it on all the guests too :-(

The ssh port blocking for the host is a rule that goes into the INPUT
table. That is independent of what libvirt does with the FORWARD table
and this host rule would not influence the guest rules and vice versa.
Traffic destined to bridged guests will NOT go through the INPUT table,
only traffic from guests towards their own host will go through it.
It depends on the version of RHEL/Fedora. Previous system-config-firewall
would put the same rules on INPUT *and* FORWARD chain. The newer s-c-f
puts a generic 'REJECT' rule on the FORWARD table. Either way, if you have
bridge-nf-call-iptables=1, then all bridged guest traffic is significantly
Setting bridge-nf-call-iptables=1 puts the system into working state so that per-VM rules for the guest are correctly evaluated. The only difference is that some systems write a "1" into the proc filesystem entry automatically and on others this has to be done by the user. In the latter case I'd rather have it done by libvirt's nwfilter driver automatically when needed. Had I known that these proc filesystem entries exist, I may have set them a long time ago... The nwfilter driver also tries to set its own FORWARD table entries at the very beginning (first 3 entries) so that any subsequent reject doesn't apply.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]