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

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 ?