Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1099810

Summary: Security Group allows traffic between VMs on separate tenants when it should block
Product: Red Hat OpenStack Reporter: Toni Freger <tfreger>
Component: openstack-packstackAssignee: RHOS Maint <rhos-maint>
Status: CLOSED DUPLICATE QA Contact: Ami Jeain <ajeain>
Severity: high Docs Contact:
Priority: high    
Version: 4.0CC: aortega, chrisw, derekh, mmagr, nyechiel, oblaut, tfreger, yeylon
Target Milestone: ---Keywords: ZStream
Target Release: 4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-07-24 16:51:39 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
iptbles before the reboot
none
iptables after the reboot none

Description Toni Freger 2014-05-21 08:58:33 UTC 
Description of problem:
Security Group allows traffic between VMs on separate tenants when it should block

Version-Release number of selected component (if applicable):
RHEL6.5 RHOS-4

How reproducible:
100%

Steps to Reproduce:
1.Install All In One via packstack (VLAN or GRE)
2.Create 2 tenants 
3.Create 2 VMs, attach each VM to different tenant and different internal network.
4.Create a Router via admin tenant and set each interface to different internal network.
5.Security Group - default rules.
6.Ping from 1 VM to another.

Actual results:
Traffic is allowed, and the ping passes.

Expected results:
According to the default rules of the Security Group feature, the traffic should be blocked.

Workaround:
Reboot the machine and Security Group will block all traffic.

Additional info:

*Before the reboot the kernel is 2.6.32-431.el6.x86_64
 After the reboot is updated for 2.6.32-431.11.2.el6.x86_64

*This scenario doesn't happen on RHEL7 RHOS5.
Comment 1 Nir Yechiel 2014-05-21 09:05:23 UTC 
Toni,

IIRC, Ofer mentioned that there are differences in the behaviour between Foreman and packstack deployments. Is this relevant to packstack only?

Thanks,
Nir
Comment 3 Ofer Blaut 2014-05-21 09:59:59 UTC 
Seems like when using the Vanilla RHEL 6.5 installation netns is working but we get kernel update from RHOS Repo.


netns and iptables will be configured but the security group will not enforce until reboot is issued to the hosts ( as suggested by packstack output )

The reboot was required before RHEL 6.5 got netns and kernel support .

This should not happen on RHEL 6.5 .

Foreman doesn't suggest reboot to user as well, while i tried to reboot foreman hosts and it didn't help
Comment 4 Toni Freger 2014-05-21 10:12:53 UTC 
Created attachment 897893 [details]
iptbles before the reboot
Comment 5 Toni Freger 2014-05-21 10:13:45 UTC 
Created attachment 897894 [details]
iptables after the reboot
Comment 7 Toni Freger 2014-07-16 07:10:46 UTC 
Tested on OpenStack-5.0-RHEL-6 Puddle: 2014-07-14.2
All-In-One + Compute node, ML2+GRE 

python-neutron-2014.1.1-2.el6ost.noarch
openstack-neutron-ml2-2014.1.1-2.el6ost.noarch
openstack-neutron-2014.1.1-2.el6ost.noarch
openstack-neutron-openvswitch-2014.1.1-2.el6ost.noarch
openstack-neutron-metering-agent-2014.1.1-2.el6ost.noarch
python-neutronclient-2.3.4-2.el6ost.noarch

sysctl -a  | grep net.bridge.bridge-nf
net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-ip6tables = 0

After I set manually all bridge variables to 1 the security groups starts working as expected.
Comment 8 Martin Magr 2014-07-21 16:39:43 UTC 
Currently both in RHELOSP-4 and RHELOSP-5 net.bridge.bridge-nf-call* is set on compute nodes only. Does it mean we have to set it on network nodes?
Comment 9 Nir Yechiel 2014-07-23 14:13:16 UTC 
Martin, 

The net.bridge.bridge-nf-call-iptables should be set to 1 across the environment for security groups to function properly. Do you know who/what set this to 0 and why? 

Based on inputs I got from Ofer, this affects all installations of OSP 4 and OSP 5.
Comment 10 Nir Yechiel 2014-07-24 16:51:39 UTC 
Marking this as a duplicate of 1104619.

*** This bug has been marked as a duplicate of bug 1104619 ***