Ebtables filtering too strict

Community Support
1

Hello,

I want to use OpenNebula for VMs which are connected using 802.1q VLANs to other parts of my (non-ONe) infrastructure. The VLANs are sent to the physical hosts as tagged, and each VLAN has a dedicated bridge interface on each physical host, created outside OpenNebula (using /etc/sysconfig/network-scripts/ifcfg-{vlanXY,brXY} on CentOS). Each VLAN has its own OpenNebula virtual network, defined as follows:

BRIDGE="br500"
DESCRIPTION="..."
DNS="..."
FILTER_IP_SPOOFING="YES"
FILTER_MAC_SPOOFING="YES"
GATEWAY="..."
GATEWAY6="..."
NETWORK_ADDRESS="..."
NETWORK_MASK="255.255.255.0"
PHYDEV=
SECURITY_GROUPS="0"
VLAN="NO"
VLAN_ID=

The problem is that when the guest VM is instantiated, two ebtables rules are created:

# ebtables -L FORWARD
Bridge chain: FORWARD, entries: 2, policy: ACCEPT
-s ! 2:f1:2b:c0:0:0/ff:ff:ff:ff:ff:0 -o vnet0 -j DROP 
-s ! 2:f1:2b:c0:0:d -i vnet0 -j DROP

The first rule is, in my opinion, superfluous. It also prevents the hosts from outside the OpenNebula infrastructure to communicate with the guests inside OpenNebula.

  • How can I modify the default ebtables rules?
  • Is ebtables-based networking the right choice for my use-case?
  • The FILTER_IP_SPOOFING="YES" option apparently works for IPv4 only - some filtering rules get added to iptables, but not to ip6tables (even though the virtual network in question is IPv4/IPv6, and both IPv4 and IPv6 leases are defined).
  • The ebtables documentation at http://docs.opennebula.org/4.12/administration/networking/ebtables.html says that “Only the virtual networks with the attribute VLAN set to YES will be isolated.” - what does it mean? I use VLAN=no and the ebtables rules are being created.

Thanks!

2

OK, I have learned that ebtables filtering can be changed by editing /var/lib/one/remotes/vnm/ebtables/Ebtables.rb (I have commented out the call to ebtables(in_rule)), increasing the serial number in /var/lib/one/remotes/VERSION, and running onehost sync.

But I still think the first one of the two rules in ebtables is incorrect and should not be used by default. Also, my other questions from the original post remain.

Thanks!

3

This problem has been fixed in 5.2 by adding a new VNet parameter FILTER_MAC_SPOOFING, which is default to yes. I have deleted this parameter in my VNet configuration, but this does not affect already instantiated VMs. How can I manually patch the templates of running VMs? I can see

NIC = [
   ...
     FILTER_MAC_SPOOFING = "YES",

Ih the VM -> Template tab in Sunstone.

Thanks!

-Yenya

4

Hi Jan,

how did you solve that in the end?

Many thanks in advance

Bernhard

5

Hi,

@jfontan just answered my question via IRC.

Just in case someone has a similar problem. I would like to share the solution with you:
The problem (in my case was) that I had the filter clean-traffic activated in /etc/one/vmm_exec/vmm_exec_kvm.conf:
Before: NIC = [ filter = "clean-traffic", model="virtio" ]
After: NIC = [ model="virtio" ]

This clean-traffic rule is also active even if FILTER_IP_SPOOFING or FILTER_MAC_SPOOFING is set to NO for that specific VNET.
So, if you find something like the following code block this in your virsh dumpxml output, or see ebtables rules with names like I-one-ID-0-rarp or I-one-251-0-ipv4-ip, just have a look into the config.

<filterref filter='clean-traffic'>
<parameter name='IP' value='IP address of the NIC'/>
</filterref>

Bernhard