Description of problem: Security groups rules are not enforced. The problem seems same as in https://bugzilla.redhat.com/show_bug.cgi?id=1291621 Version-Release number of selected component (if applicable): 9.0-RHEL-7-director/2016-06-08.1 How reproducible: 100% Steps to Reproduce: 1.install OSPD OSP9 2. boot VM 3.ssh to VM (for exact reproduction assign FIP to the VM and ssh to FIP) 4. check /etc/sysctl.conf on compute node Actual results: Security rules are not enforced Expected results: ssh should not be allowed Additional info: In compute nodes, the /etc/sysctl.conf values are not set: net.bridge.bridge-nf-call-arptables=1 net.bridge.bridge-nf-call-ip6tables=1 net.bridge.bridge-nf-call-iptables=1
Bug 1291621 was fixed in openstack-neutron, moving this bug there.
In OSP 9, the neutron-server uses an option called firewall_driver to tell OVS agents which driver to use. The server uses that value to tag a port with the vif driver to use: Either direct plug, or hybrid plug. Hybrid plug means that Nova will plug the VM's tap device to a linux bridge, which is then connected to the OVS bridge (br-int). Hybrid plugging is required when using Neutron and iptables based firewall driver (The default) in order for security groups to work. We've determined that the issue is that the firewall_driver option is not being configured on controller nodes, resulting in the neutron-server always returning 'direct plug', meaning that the per-VIF linux bridge is not being created, and security groups don't work. The solution is to make sure the firewall_driver option is defined on controller nodes.
Hi Assaf, Will it be supported in upgrade from ospd8 to 9 ?
(In reply to Ofer Blaut from comment #4) > Hi Assaf, > > Will it be supported in upgrade from ospd8 to 9 ? Yes, that should not be a problem. The firewall_driver config option should be defined in both versions.
Armando backported Kevin's fix for this to mitaka stable https://review.openstack.org/#/c/313173/. It's currently in the 8.1.1 tag. Would we rather release our fix through an updated neutron RPM or by heat template configuration?
(In reply to Brent Eagles from comment #6) > Armando backported Kevin's fix for this to mitaka stable > https://review.openstack.org/#/c/313173/. It's currently in the 8.1.1 tag. > Would we rather release our fix through an updated neutron RPM or by heat > template configuration? That patch should cover it, in which case that would be easier than a TripleO change, and would also take care of anyone installing via any other method. @Jakub, are we missing anything here or would that patch suffice?
(In reply to Assaf Muller from comment #7) > (In reply to Brent Eagles from comment #6) > > Armando backported Kevin's fix for this to mitaka stable > > https://review.openstack.org/#/c/313173/. It's currently in the 8.1.1 tag. > > Would we rather release our fix through an updated neutron RPM or by heat > > template configuration? > > That patch should cover it, in which case that would be easier than a > TripleO change, and would also take care of anyone installing via any other > method. > > @Jakub, are we missing anything here or would that patch suffice? The patch suffices, we saw compute nodes have firewall driver set. PS: So after all, I see it was my goof :)
*** Bug 1346804 has been marked as a duplicate of this bug. ***
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2016-1597.html