Security Group not working 802.1Q Vlan

I am trying to configure Security group, my configurations are
Default Group :
All Outbound All Any
TCP Inbound 80,443 Any

Virtual Network :

BRIDGE="f1vlan40"
DNS="8.8.8.8"
FILTER_IP_SPOOFING="YES"
FILTER_MAC_SPOOFING="YES"
GATEWAY="10.15.xxx.1"
MTU="1500"
NETWORK_ADDRESS="10.15.xxx.0"
NETWORK_MASK="255.255.255.0"
PHYDEV="F1TRUNK"
SECURITY_GROUPS="0"
VLAN="YES"
VLAN_ID=“40”

Security group is not working…

Hi,

Could you send the output of onevm -x for the failing VM as well as the
output of iptables-save command in the host where the VM is running.
Also, are there any relevant messages in oned.log or vm.log for the VM?

Cheers

Hi Ruben,

on the host iptable is stopped state.

Output of iptables-save

[root@f1-cloud-01 ~]# iptables-save

Generated by iptables-save v1.4.21 on Fri Dec 11 09:15:56 2015

*filter
:INPUT ACCEPT [514758:601406833]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [525961:712301370]
:one-135-0-i - [0:0]
:one-135-0-o - [0:0]
:one-136-0-i - [0:0]
:one-136-0-o - [0:0]
:one-138-0-i - [0:0]
:one-138-0-o - [0:0]
:one-148-0-i - [0:0]
:one-148-0-o - [0:0]
:one-151-0-i - [0:0]
:one-151-0-o - [0:0]
:one-176-0-i - [0:0]
:one-176-0-o - [0:0]
:one-182-0-i - [0:0]
:one-182-0-o - [0:0]
:one-203-0-i - [0:0]
:one-203-0-o - [0:0]
:one-207-0-i - [0:0]
:one-207-0-o - [0:0]
:opennebula - [0:0]
-A FORWARD -m physdev --physdev-is-bridged -j opennebula
-A one-135-0-i -m state --state RELATED,ESTABLISHED -j ACCEPT
-A one-135-0-i -j RETURN
-A one-135-0-i -j DROP
-A one-135-0-o -m state --state RELATED,ESTABLISHED -j ACCEPT
-A one-135-0-o -j RETURN
-A one-135-0-o -j DROP
-A one-136-0-i -m state --state RELATED,ESTABLISHED -j ACCEPT
-A one-136-0-i -j RETURN
-A one-136-0-i -j DROP
-A one-136-0-o -m state --state RELATED,ESTABLISHED -j ACCEPT
-A one-136-0-o -j RETURN
-A one-136-0-o -j DROP
-A one-138-0-i -m state --state RELATED,ESTABLISHED -j ACCEPT
-A one-138-0-i -j RETURN
-A one-138-0-i -j DROP
-A one-138-0-o -m state --state RELATED,ESTABLISHED -j ACCEPT
-A one-138-0-o -j RETURN
-A one-138-0-o -j DROP
-A one-148-0-i -m state --state RELATED,ESTABLISHED -j ACCEPT
-A one-148-0-i -j RETURN
-A one-148-0-i -j DROP
-A one-148-0-o -m state --state RELATED,ESTABLISHED -j ACCEPT
-A one-148-0-o -j RETURN
-A one-148-0-o -j DROP
-A one-151-0-i -m state --state RELATED,ESTABLISHED -j ACCEPT
-A one-151-0-i -j RETURN
-A one-151-0-i -j DROP
-A one-151-0-o -m state --state RELATED,ESTABLISHED -j ACCEPT
-A one-151-0-o -j RETURN
-A one-151-0-o -j DROP
-A one-176-0-i -m state --state RELATED,ESTABLISHED -j ACCEPT
-A one-176-0-i -p tcp -m multiport --dports 80,443 -j RETURN
-A one-176-0-i -j DROP
-A one-176-0-o -m state --state RELATED,ESTABLISHED -j ACCEPT
-A one-176-0-o -j RETURN
-A one-176-0-o -j DROP
-A one-182-0-i -m state --state RELATED,ESTABLISHED -j ACCEPT
-A one-182-0-i -p tcp -m multiport --dports 80,443 -j RETURN
-A one-182-0-i -j DROP
-A one-182-0-o -m state --state RELATED,ESTABLISHED -j ACCEPT
-A one-182-0-o -j RETURN
-A one-182-0-o -j DROP
-A one-203-0-i -m state --state RELATED,ESTABLISHED -j ACCEPT
-A one-203-0-i -p tcp -m multiport --dports 80,443 -j RETURN
-A one-203-0-i -j DROP
-A one-203-0-o -m mac ! --mac-source 02:00:0A:0D:DE:29 -j DROP
-A one-203-0-o ! -s 10.13.222.41/32 -j DROP
-A one-203-0-o -m state --state RELATED,ESTABLISHED -j ACCEPT
-A one-203-0-o -j RETURN
-A one-203-0-o -j DROP
-A one-207-0-i -m state --state RELATED,ESTABLISHED -j ACCEPT
-A one-207-0-i -p tcp -m multiport --dports 80,443 -j RETURN
-A one-207-0-i -j DROP
-A one-207-0-o -m mac ! --mac-source 02:00:0A:0F:DF:67 -j DROP
-A one-207-0-o ! -s 10.15.223.103/32 -j DROP
-A one-207-0-o -m state --state RELATED,ESTABLISHED -j ACCEPT
-A one-207-0-o -j RETURN
-A one-207-0-o -j DROP
-A opennebula -m physdev --physdev-in vnet6 --physdev-is-bridged -j one-207-0-o
-A opennebula -m physdev --physdev-out vnet6 --physdev-is-bridged -j one-207-0-i
-A opennebula -m physdev --physdev-in vnet2 --physdev-is-bridged -j one-203-0-o
-A opennebula -m physdev --physdev-out vnet2 --physdev-is-bridged -j one-203-0-i
-A opennebula -m physdev --physdev-in vnet5 --physdev-is-bridged -j one-182-0-o
-A opennebula -m physdev --physdev-out vnet5 --physdev-is-bridged -j one-182-0-i
-A opennebula -m physdev --physdev-in vnet9 --physdev-is-bridged -j one-176-0-o
-A opennebula -m physdev --physdev-out vnet9 --physdev-is-bridged -j one-176-0-i
-A opennebula -m physdev --physdev-in vnet1 --physdev-is-bridged -j one-151-0-o
-A opennebula -m physdev --physdev-out vnet1 --physdev-is-bridged -j one-151-0-i
-A opennebula -m physdev --physdev-in vnet7 --physdev-is-bridged -j one-148-0-o
-A opennebula -m physdev --physdev-out vnet7 --physdev-is-bridged -j one-148-0-i
-A opennebula -m physdev --physdev-in vnet4 --physdev-is-bridged -j one-135-0-o
-A opennebula -m physdev --physdev-out vnet4 --physdev-is-bridged -j one-135-0-i
-A opennebula -m physdev --physdev-in vnet3 --physdev-is-bridged -j one-136-0-o
-A opennebula -m physdev --physdev-out vnet3 --physdev-is-bridged -j one-136-0-i
-A opennebula -m physdev --physdev-in vnet0 --physdev-is-bridged -j one-138-0-o
-A opennebula -m physdev --physdev-out vnet0 --physdev-is-bridged -j one-138-0-i
-A opennebula -j ACCEPT
COMMIT

I do not see any problems with the rules, for example VM 182 should only
allow input traffic
at ports 80,443 (TCP):

-A one-182-0-i -p tcp -m multiport --dports 80,443 -j RETURN

However there is activity in the FORWARD chain, no packets traversing it.
And this is probably the problem… it seems that no traffic is being
forward through the bridge in the hypervisors? Can you check?

do i have to start the iptables service on every node ?. it is stopped now

No, iptables services, AFAIK, is to restore and save rules… those are
generated on-the-fly by OpenNebula so there should not be needed…

Similar problem here on a fresh CentOS 7.2 KVM host. IP and MAC spoofing are not working on a 802.1Q network.

iptables rules seems OK but they are not working : http://pastebin.com/eBxNhzdL

I modified the guest IP to 10.1.1.225 and I can ping it from the outside.

UPDATE
My problem is very weird. I have two hosts installed the same way but the iptables rules only works on one of the two.
UPDATE
My bad, the problem is present on both hosts.

It might be the kernel configuration, make sure you have this enabled:

net.bridge.bridge-nf-call-arptables = 1 net.bridge.bridge-nf-call-ip6tables = 1 net.bridge.bridge-nf-call-iptables = 1
If it you receive an error message like:
sysctl: cannot stat /proc/sys/net/bridge/bridge-nf-call-arptables: No such file or directory
then you might need to run modprobe br_netfilter to load that module

Please confirm if this is the problem

1 Like

Good catch Jaime! All these options was disabled and the problem is linked with that.

With all options enabled, the IP spoofing filter and security group rules finally works on my 802.1Q network! I can’t ping the spoofed IP anymore from the outside but it is now impossible to communicate from inside a VM (with correct IP) to the outside. I can SSH to it from the outside but I can’t even ping my gateway from the newly created VM. The iptables rules seems OK. Should I have to reboot the server to make the kernel options works correctly?

This is the security group applied to the network :
All Outbound All Any
TCP Inbound 22 Any

iptables ouput :
Chain one-453-0-i (1 references)
target prot opt source destination
ACCEPT all – 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
RETURN tcp – 0.0.0.0/0 0.0.0.0/0 multiport dports 22
DROP all – 0.0.0.0/0 0.0.0.0/0

Chain one-453-0-o (1 references)
target prot opt source destination
DROP all – 0.0.0.0/0 0.0.0.0/0 MAC ! 02:00:CD:EC:0C:BE
DROP all – ![Authorized IP] 0.0.0.0/0
ACCEPT all – 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
RETURN all – 0.0.0.0/0 0.0.0.0/0
DROP all – 0.0.0.0/0 0.0.0.0/0

Thanks.

After several tests, I can confirm that adding the bridge filters below solve the IP/MAC filtering and security group problem (not working) with CentOS 7.2. The filters are disabled by defaut in /usr/lib/sysctl.d/00-system.conf. Also, the br_netfilter kernel module doesn’t exists in CentOS 7. The right module name is bridge and it is loaded automatically when the 802.1Q bridge interface is created by OpenNebula.

My problem with VM that can’t join the outisde was solved by rebooting the host (i don’t understand why).

Thanks again Jaime.

Thank you for the update Guillaume. I’ll document this now: http://dev.opennebula.org/issues/4290