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

[Daniel P. Berrange]

On Thu, Sep 23, 2010 at 10:31:38AM -0400, Stefan Berger wrote:
>  On 09/23/2010 09:09 AM, Daniel P. Berrange wrote:
> >On Thu, Sep 23, 2010 at 08:45:41AM -0400, Stefan Berger wrote:
> >>  On 09/23/2010 07:33 AM, Daniel P. Berrange wrote:
> >>>On Thu, Sep 23, 2010 at 11:36:11AM +0100, 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.
> >>>>What parts of the nwfilter functionality gets affected by this ?
> >>>>
> >>>>IIUC, the higher level protocols, TCP, UDP, SCTP, ICMP,
> >>>>IGMP, ESP, AH, UDPLITE&   'ALL'  get implemented via iptables ?
> >>>>Alot of the matches you can define using these higher level
> >>>>protocols, can also be defined using the generic IPv4/IPv6 rules.
> >>>>For example everything you can do with TCP protocol can be done
> >>>>with the IPv4/IPv6 protocol, with exception of ip address ranges.
> >>>>
> >>>>
> >>>>Could we either
> >>>>
> >>>>  1. Document that if you want to make use of the higher level
> >>>>     protocols, that you need to enable bridge-nf-call-iptables
> >>>>     and explain the tradeoffs in that setting.[1][2]
> >>>>
> >>>>  2. Provide an alternative impl of 90% of the higher level
> >>>>     protocols, using ebtables instead of iptables. And make
> >>>>     choice of iptables vs ebtables a config param for libvirtd.
> >>>>     eg, for most people an ebtables based impl will be sufficient
> >>>>     but if they need the full funtionality,then switch to the
> >>>>     iptables impl&   enable bridge-nf-call-iptables=1
> >>>Actally I guess 2. is rather pointless given that you can already just
> >>>use the IPv4/6 generic rules to do 90% of that stuff. I think this just
> >>>comes down to a documentation issue, explaining the pros&cons of each
> >>>possible bridge-nf-call-* setting.
> >>Yes, it should work and would be a matter of writing the rules
> >>differently so that they get enforced on ebtables layer rather than
> >>iptables.
> >>
> >>I still think that if the user writes filtering rules that end up
> >>creating iptables rules that in that case the bridge-nf-call-* should
> >>automatically be enabled by libvirt so that the filtering works as
> >>expected -- assuming the user would end up doing the same anyway (after
> >>looking for the reason why it does not work as expected).
> >The problem is that changing bridge-nf-call-* may make libvirt's
> >functionality behave 'as expected', but since this is a system
> >wide setting, it will change the behaviour of other non-libvirt
> >apps in ways that may not be expected.  For example, it may cause
> >packet loss with UDP, because it means that TUNSETSNDBUF will no
> >longer throttle guest UDP packets from QEMU.
> http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=0df0ff6de7
> 
> This is the patch and posting on the qemu mailing list. It's interesting 
> to see how things are tied together... I wonder whether ebtables rules 
> are also going to orphan the packets due to it also using 
> (bridge-)netfilter?

That's a good question....

> >In this case the admin may well prefer to rewrite their nwfilter rule
> >to use the 'ipv4' match, rather than have libvirt silently change the
> >bridge-nf-call-* settings.
> >
> >Perhaps we should log a warning if a rule is activated for a guest,
> >that we know will have no effect, due to bridge-nf-call-* settings.
> >
> I guess we can do that. Should we log it into libvirt log or into the 
> system log ?

libvirtd configures anything at WARN/ERROR level to go to syslog by
default, so just logging to libvirt is sufficient

Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|