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

[Stefan Berger]

  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?
> 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 ?

   Stefan
> Daniel