<div dir="ltr"><div>There is a bug in security groups here: <a href="https://bugs.launchpad.net/neutron/+bug/1359523">https://bugs.launchpad.net/neutron/+bug/1359523</a></div><div><br></div><div>In the example scenario, it's caused by conntrack zones not being isolated. But it also applies to the following scenario that can't be solved by zones:</div><div><br></div><div>create two networks with same <a href="http://10.0.0.0/24">10.0.0.0/24</a></div><div>create port1 in SG1 on net1 with IP 10.0.0.1<br></div><div>create port2 in SG1 on net2 with IP 10.0.0.2</div><div>create port3 in SG2 on net1 with IP 10.0.0.2</div><div>create port4 in SG2 on net2 with IP 10.0.0.1</div><div><br></div><div>port1 can communicate with port3 because of the allow rule for port2's IP</div><div>port2 can communicate with port4 because of the allow rule for port1's IP</div><div><br></div><div>The solution will require the security groups processing code to understand that a member of a security group is not actually reachable by another member and skip the allow rule for that member.</div><div><br></div><div>With the current state of things, it will take a tone of kludgy code to check for routers and router interfaces to see if two IPs can communicate without NAT. However, if we end up with the concept of address-scopes, it just becomes a simple address scope comparison.</div><div><br></div><div>Implement address scopes.</div><div><br></div><div><br></div><div>Cheers!</div>-- <br><div class="gmail_signature"><div>Kevin Benton</div></div>
</div>