<div dir="ltr">Hello Marco,<div><br></div><div>more comments inline.</div><div><br></div><div>Salvatore<br><div class="gmail_extra"><br><div class="gmail_quote">On 7 July 2015 at 22:09, Marco Mariani <span dir="ltr"><<a href="mailto:marco.mariani@alterway.fr" target="_blank">marco.mariani@alterway.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class=""><div class="gmail_quote">2015-07-07 20:52 GMT+02:00 Salvatore Orlando <span dir="ltr"><<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>></span>:</div></span><div class="gmail_quote"><span class=""><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"><div dir="ltr">If I understand correctly your use case security groups can be probably used to satisfy your goal with Neutron.<div><br></div><div>Groups of isolated VMs in the same network can be assigned to different security groups. Traffic among different groups will be dropped unless unable by a specific security group rule.</div></div></blockquote><div><br></div></span><div>Not in my experience, if VMs are in the same tenant network they can ping and connect to each other regardless of security rules. With nova-network that depends on the setting of <span style="font-size:12.8000001907349px">allow_same_net_traffic={True, False}.</span></div><div><br></div><div>By the way, I'm using Juno (with Fuel 6.1)</div></div></div></div></blockquote><div><br></div><div>Even if VMs are in the same logical network, it should be possible to do isolation associating them with different security groups, in your case N security groups.</div><div>For instance if VM1 and VM2 are associated respectively with security group SG1 and SG2, and this security group only have the default rules plus one for enabling connectivity with VM0, VM1 should not reach VM2. If this happens something is not quite right.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div><br></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"><div dir="ltr"><div>Still I am not sure if this is your goal</div></div></blockquote><div><br></div></span><div>Yes, indeed. I have VM1 to N that should be able to reach Internet and a designated "master" VM0, but not each other. Instances 1 through N are created with Heat templates.</div></div></div></div></blockquote><div><br></div><div>Now I probably understand. It is a scenario similar to PVLAN.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div><br></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"><div dir="ltr"><div>as you wrote that you want to forbid traffic between VMs and floating IPs, you might be trying to achieve something different.<br></div></div></blockquote><div><br></div></span><div>That would be easier to fix, I can set up netfilter in the exposed machines and in the OpenStack nodes. But between VMs, there are no Allow / Deny rules. And neither would FWaaS help me, since it operates at the perimeter.</div></div></div></div></blockquote><div><br></div><div>Correct, FWaaS enforces rules at the edge and won't help you.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><span style="color:rgb(0,0,0);font-family:Verdana,Geneva,sans-serif;font-size:13.3333330154419px"><br></span></div><div><span style="color:rgb(0,0,0);font-family:Verdana,Geneva,sans-serif;font-size:13.3333330154419px">I suppose Role-basec Access Control (</span><font color="#000000" face="Verdana, Geneva, sans-serif"><span style="font-size:13.3333330154419px"><a href="https://github.com/openstack/neutron-specs/blob/master/specs/liberty/rbac-networks.rst" target="_blank">https://github.com/openstack/neutron-specs/blob/master/specs/liberty/rbac-networks.rst</a>) could help me, but if so, that's a solution that does not directly map to how I see my problem.</span></font></div></div></div></div></blockquote><div><br></div><div>RBAC won't helo you I think. It provides a way to declare which tenants can use a given network, but it is a management layer abstraction - it has no goal of policing the traffic on the logical network where it is applied.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><span style="color:rgb(0,0,0);font-family:Verdana,Geneva,sans-serif;font-size:13.3333330154419px"><br></span></div><div>Thanks for the reply!</div><div><br></div></div></div></div>
</blockquote></div><br></div></div></div>