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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
