I’m currently looking for a solution to restrict a virtual network for each customer with OpenvSwitch.
I explain myself, we have multiples users (customers) for OpenNebula, and we need to restrict each others by virtual networks but in the same network (Separated by VLANs).
For example: I have a mutualised IP bloc x.x.x.x/24 and I want to cut it with some IP range for each clients separated by VLAN, I don’t want that a client try to usurped an IP from another client.
How can I do to make OpenNebula automatically created the IP Hijacking flow to restrict is virtual network with is MAC (taking account he want to use sub-interface, 1 MAC adresses with multiples IP adresses) ?
If it’s not possible, which solution could you advise me to restrict multiple virtual networks (VNET) in a same network (PVlans, NAT) ?
OpenvSwitch only adds MAC spoofing rules, you may want to take a look to
the VXLAN or 802.1Q drivers, they come with IP spoofing rules and full
support for security groups.
IP hijacking
These rules prevent any traffic to come out of the port for IPv4 IP’s not configured for a VM
in_port=,arp,dl_src=priority=45000,actions=drop
in_port=,arp,dl_src=,nw_src=,priority=46000,actions=normal
I learned about the Security Group include in the new version of OpenNebula but that didn’t prevents a user to change is IP in the case describe above.
I encounter a problem where a customer should configure is VM like he want with his range of IP allowed by OpenNebula but where he mustn’t usurped IP adresses from another range in a same network.
The big problem is currently that OpenNebula doesn’t include the possibility to define subs-interfaces, and the possibility to contextualize them. Maybe this is a point that will be included in a next release of OpenNebula ?
Sorry, I was thinking about IP Spoofing and not the rules for ARP cache
poisoning…
IP Spoofing as provided by the VXLAN and 802.1Q drivers, filters all
packets not coming from the IP assigned within OpenNebula.
However, this not cover a range of IP’s just the IP assgined to the VM.
Working this in the drivers could be somehow difficult, as it may require
changes in the data associated to a NIC. So my recommendation is:
1.- Assign your user a range of IPs, this can be done through a reservation
or manually creating the VNET.
2.- Let the user pick the IP when firing the VM.
The user must be consistent with the IP chosen in 2 when configuring the
VM.
As a bonus, the IP shown in Sunstone and CLI are consistent with your
system…
This is what I was thinkings, OpenNebula make a networking logical statement about deployment cycle but currently doesn’t include the sub-interface support.
In fact, I will need to find another way to make the possibility to give an IP range to a customer and then restrict is network with NAT or PVlans rules using OpenNebula Virtual Router appliance or Vyatta appliance…