<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 2, 2016 at 1:46 PM, Clark Boylan <span dir="ltr"><<a href="mailto:cboylan@sapwetik.org" target="_blank">cboylan@sapwetik.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Wed, Mar 2, 2016, at 09:38 AM, Sean M. Collins wrote:<br>
> Kevin Benton wrote:<br>
> > * Neutron cannot be trusted to do what it says it's doing with the security<br>
> > groups API so users want to orchestrate firewalls directly on their<br>
> > instances.<br>
><br>
> This one really rubs me the wrong way. Can we please get a better<br>
> description of the bug - instead of someone just saying that Neutron<br>
> doesn't work, therefore we don't want any filtering or security for our<br>
> instances using an API?<br>
<br>
</span>Sure. There are two ways this manifests. The first is that there have<br>
been bugs in security groups where traffic is passed despite being told<br>
not to pass that traffic. This has been treated as a bug in the past and<br>
corrected which is great so this particular instance of the issue is<br>
less worrysome. The second is that I will explicitly tell neutron to<br>
pass traffic but for whatever reason that traffic ends up being blocked<br>
anyways. One concrete example of this is the infra team has had to stop<br>
using GRE because at least two of our clouds do not pass GRE traffic<br>
despite having explicit "pass all ipv4 and all ipv6 between all possible<br>
addresses rules".<br>
<br>
Security groups need to do what I have told them to do and when they<br>
don't it is almost impossible as a cloud user to debug them.<br></blockquote><div><br></div><div><br></div><div><div class="gmail_default" style="font-size:small">​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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">​<a href="http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.general/47705">http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.general/47705</a></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.<br></div></div><div><br></div><div><div class="gmail_default" style="font-size:small">​ Sri​</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><font color="#888888"><br>
Clark<br>
</font></span><div class=""><div class="h5"><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>