On Wed, Mar 2, 2016 at 1:46 PM, Clark Boylan <cboy...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev