1:19 p.m.
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.
Signed-off-by: Stefan Berger <stefanb(a)us.ibm.com>
---
src/nwfilter/nwfilter_ebiptables_driver.c | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
Index: libvirt-acl/src/nwfilter/nwfilter_ebiptables_driver.c
===================================================================
--- libvirt-acl.orig/src/nwfilter/nwfilter_ebiptables_driver.c
+++ libvirt-acl/src/nwfilter/nwfilter_ebiptables_driver.c
@@ -63,6 +63,11 @@
: ""
+#define PROC_BRIDGE_NF_CALL_IPTABLES \
+ "/proc/sys/net/bridge/bridge-nf-call-iptables"
+#define PROC_BRIDGE_NF_CALL_IP6TABLES\
+ "/proc/sys/net/bridge/bridge-nf-call-ip6tables"
+
static char *ebtables_cmd_path;
static char *iptables_cmd_path;
static char *ip6tables_cmd_path;
@@ -429,16 +434,20 @@ static int iptablesLinkIPTablesBaseChain
static int iptablesCreateBaseChains(const char *iptables_cmd,
- virBufferPtr buf)
+ virBufferPtr buf,
+ bool isIPv6)
{
virBufferVSprintf(buf,"%s -N " VIRT_IN_CHAIN CMD_SEPARATOR
"%s -N " VIRT_OUT_CHAIN CMD_SEPARATOR
"%s -N " VIRT_IN_POST_CHAIN CMD_SEPARATOR
- "%s -N " HOST_IN_CHAIN CMD_SEPARATOR,
+ "%s -N " HOST_IN_CHAIN CMD_SEPARATOR
+ "echo 1 > %s" CMD_SEPARATOR,
+ iptables_cmd,
iptables_cmd,
iptables_cmd,
iptables_cmd,
- iptables_cmd);
+ isIPv6 ? PROC_BRIDGE_NF_CALL_IP6TABLES
+ : PROC_BRIDGE_NF_CALL_IPTABLES);
iptablesLinkIPTablesBaseChain(iptables_cmd, buf,
VIRT_IN_CHAIN , "FORWARD", 1, 1);
iptablesLinkIPTablesBaseChain(iptables_cmd, buf,
@@ -3074,7 +3083,7 @@ ebiptablesApplyNewRules(virConnectPtr co
iptablesUnlinkTmpRootChains(iptables_cmd_path, &buf, ifname);
iptablesRemoveTmpRootChains(iptables_cmd_path, &buf, ifname);
- iptablesCreateBaseChains(iptables_cmd_path, &buf);
+ iptablesCreateBaseChains(iptables_cmd_path, &buf, false);
if (ebiptablesExecCLI(&buf, &cli_status) || cli_status != 0)
goto tear_down_tmpebchains;
@@ -3105,7 +3114,7 @@ ebiptablesApplyNewRules(virConnectPtr co
iptablesUnlinkTmpRootChains(ip6tables_cmd_path, &buf, ifname);
iptablesRemoveTmpRootChains(ip6tables_cmd_path, &buf, ifname);
- iptablesCreateBaseChains(ip6tables_cmd_path, &buf);
+ iptablesCreateBaseChains(ip6tables_cmd_path, &buf, true);
if (ebiptablesExecCLI(&buf, &cli_status) || cli_status != 0)
goto tear_down_tmpiptchains;
1:25 p.m.
On 09/22/2010 12:19 PM, 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.
Do we have to worry about a minimum kernel version where these /proc/sys
files are guaranteed to exist?
virBufferVSprintf(buf,"%s -N " VIRT_IN_CHAIN CMD_SEPARATOR
"%s -N " VIRT_OUT_CHAIN CMD_SEPARATOR
"%s -N " VIRT_IN_POST_CHAIN CMD_SEPARATOR
- "%s -N " HOST_IN_CHAIN CMD_SEPARATOR,
+ "%s -N " HOST_IN_CHAIN CMD_SEPARATOR
+ "echo 1 > %s" CMD_SEPARATOR,
Not introduced by this patch, but shouldn't you be checking individual
commands for appropriate exit status? And with this particular patch,
what happens when a successful exit status of 'echo 1 >file' masks an
earlier failure of the iptables_cmd?
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
2:51 p.m.
On 09/22/2010 02:25 PM, Eric Blake wrote:
On 09/22/2010 12:19 PM, 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.
Do we have to worry about a minimum kernel version where these
/proc/sys files are guaranteed to exist?
How would I find out? At least on the
machines I have looked, these proc
filesystem entries do exists -- just that they already contain the
expected '1'. I don't know what used to write the '1' into these
files,
but it doesn't do it anymore on the other 2 systems I installed,
possible due to packages that I have installed on other systems but not
on the new ones.
My assumption is that on systems where these files exist, writing a '1'
into them won't hurt. If they don't exist then the expected behavior is
activated by default.
> virBufferVSprintf(buf,"%s -N " VIRT_IN_CHAIN CMD_SEPARATOR
> "%s -N " VIRT_OUT_CHAIN CMD_SEPARATOR
> "%s -N " VIRT_IN_POST_CHAIN CMD_SEPARATOR
> - "%s -N " HOST_IN_CHAIN CMD_SEPARATOR,
> + "%s -N " HOST_IN_CHAIN CMD_SEPARATOR
> + "echo 1 > %s" CMD_SEPARATOR,
Not introduced by this patch, but shouldn't you be checking individual
commands for appropriate exit status? And with this particular patch,
what happens when a successful exit status of 'echo 1 >file' masks an
earlier failure of the iptables_cmd?
The particular sequence of above 4 commands (above the echo) is run
quite frequently and they may fail if for example the tables already
exist. If they did not succeed for some other reason, then subsequent
commands trying to establish a 'jump' into one of these tables will then
fail (see code following below the patch in the same function) and
report back. So error codes in this case can be masked.
Stefan
1:49 p.m.
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 :-(
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 :|
2:35 p.m.
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.
Regards,
Stefan
Daniel
4:31 a.m.
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
impacted.
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 :|
5:30 a.m.
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
impacted.
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.
Stefan
Daniel
5:36 a.m.
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
Daniel
[1] http://kerneltrap.org/mailarchive/linux-netdev/2009/6/30/6114563
[2] https://bugzilla.redhat.com/show_bug.cgi?id=512206
--
|: 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 :|
6:33 a.m.
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.
Daniel
[1] http://kerneltrap.org/mailarchive/linux-netdev/2009/6/30/6114563
[2] https://bugzilla.redhat.com/show_bug.cgi?id=512206
--
|: 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 :|
7:45 a.m.
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).
Stefan
8:09 a.m.
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.
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.
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 :|
9:31 a.m.
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
9:39 a.m.
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 :|
5175
days inactive
5176
days old
12 comments
3 participants
participants (3)
-
Daniel P. Berrange -
Eric Blake -
Stefan Berger