Open Stack

On Wed, Mar 2, 2016 at 1:46 PM, Clark Boylan <cboylan at sapwetik.org> wrote:

> On Wed, Mar 2, 2016, at 09:38 AM, Sean M. Collins wrote:
> > Kevin Benton wrote:
> > > * Neutron cannot be trusted to do what it says it's doing with the
> security
> > > groups API so users want to orchestrate firewalls directly on their
> > > instances.
> >
> > This one really rubs me the wrong way. Can we please get a better
> > description of the bug - instead of someone just saying that Neutron
> > doesn't work, therefore we don't want any filtering or security for our
> > instances using an API?
>
> Sure. There are two ways this manifests. The first is that there have
> been bugs in security groups where traffic is passed despite being told
> not to pass that traffic. This has been treated as a bug in the past and
> corrected which is great so this particular instance of the issue is
> less worrysome. The second is that I will explicitly tell neutron to
> pass traffic but for whatever reason that traffic ends up being blocked
> anyways. One concrete example of this is the infra team has had to stop
> using GRE because at least two of our clouds do not pass GRE traffic
> despite having explicit "pass all ipv4 and all ipv6 between all possible
> addresses rules".
>
> Security groups need to do what I have told them to do and when they
> don't it is almost impossible as a cloud user to debug them.
>


​This doesn't sound like a neutron issue but an issue with how the
conntrack module for GRE changed in the kernel in 3.18.

​
http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.general/47705

IMO, operators don't like a default policy with everything allowed. It is
better to have everything locked down unless the flow was requested.​ As
other have said elsewhere in this thread, you already have the ability to
not use the firewall driver in neutron.

​ Sri​



>
> Clark
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160303/d7cf955a/attachment.html>