<div dir="ltr">Hey stackers,<div class="gmail_extra"><br></div><div class="gmail_extra">Let me ask something about this... Why not use Linux Conntrack Table at each Tenant Namespace (L3 Router) to detect which connections were</div><div class="gmail_extra">made/established over a Floating IP ?</div><div class="gmail_extra"><br></div><div class="gmail_extra">Like this, on the Neutron L3 Router:</div><div class="gmail_extra"><br></div><div class="gmail_extra">--</div><div class="gmail_extra"><font face="courier new, monospace">apt-get install conntrack</font></div><div class="gmail_extra"><font face="courier new, monospace"><br></font></div><div class="gmail_extra"><font face="courier new, monospace">ip netns exec qrouter-09b72faa-a5ef-4a52-80b5-1dcbea23b1b6 conntrack -L | grep ESTABLISHED<br></font></div><div class="gmail_extra"><font face="courier new, monospace"><br></font></div><div class="gmail_extra"><div class="gmail_extra"><font face="courier new, monospace">tcp 6 431998 ESTABLISHED src=192.168.3.5 dst=193.16.15.250 sport=36476 dport=8333 src=193.16.15.250 dst=187.1.93.67 sport=8333 dport=36476 [ASSURED] mark=0 use=1</font></div></div><div class="gmail_extra">--</div><div class="gmail_extra"><br></div><div class="gmail_extra">Floating IP: 187.1.93.67</div><div class="gmail_extra">Instance IP: 192.168.3.5</div><div class="gmail_extra"><br></div><div class="gmail_extra"><a href="http://conntrack-tools.netfilter.org/manual.html#conntrack">http://conntrack-tools.netfilter.org/manual.html#conntrack</a><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">----</div><div class="gmail_extra"><br></div><div class="gmail_extra">Or, <u>as a workaround</u>, right after removing the Floating IP, Neutron might insert a temporary firewall rule (for about 5~10 minutes?), to drop the connections of that previous "Floating IP + Instance IP couple"... It looks really ugly but, at least, it will make sure that nothing will pass right after removing a Floating IP... Effectively terminating (dropping) the NAT connections after disassociating a Floating IP... ;-)</div><div class="gmail_extra"><br></div><div class="gmail_extra">----</div><div class="gmail_extra"><br></div><div class="gmail_extra">Also, I think that NFTables can bring some light here... I truly believe that if OpenStack moves to a "NFTables_Driver", it will be much easier to: manage firewall rules, logging, counters, IDS/IPS, atomic replacements of rules, even NAT66... All under a single implementation... Maybe with some kind of "real-time connection monitoring"... I mean, with NFTables, it becomes easier to implement a firewall ruleset with a Intrusion Prevention System (IPS), take a look:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><a href="https://home.regit.org/2014/02/suricata-and-nftables/">https://home.regit.org/2014/02/suricata-and-nftables/</a><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">So, if NFTables can make Suricata's life easier, why not give Suricata's power to Netutron L3 Router? Starting with a new NFTables_Driver... =)</div><div class="gmail_extra"><br></div><div class="gmail_extra">I'm not an expert on NFTables but, from what I'm seeing, it perfectly fits in OpenStack, in fact, NFTables will make OpenStack better.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><a href="https://home.regit.org/2014/01/why-you-will-love-nftables/">https://home.regit.org/2014/01/why-you-will-love-nftables/</a><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Best!</div><div class="gmail_extra">Thiago</div><div class="gmail_extra"><br><div class="gmail_quote">On 15 September 2014 20:49, Nathan Kinder <span dir="ltr"><<a href="mailto:nkinder@redhat.com" target="_blank">nkinder@redhat.com</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">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
Disassociating floating IPs does not terminate NAT connections with<br>
Neutron L3 agent<br>
- ---<br>
<br>
### Summary ###<br>
Every virtual instance is automatically assigned a private IP address.<br>
You may optionally assign public IP addresses to instances. OpenStack<br>
uses the term "floating IP" to refer to an IP address (typically<br>
public) that can be dynamically added to a running virtual instance.<br>
The Neutron L3 agent uses Network Address Translation (NAT) to assign<br>
floating IPs to virtual instances. Floating IPs can be dynamically<br>
released from a running virtual instance but any active connections are<br>
not terminated with this release as expected when using the Neutron L3<br>
agent.<br>
<br>
### Affected Services / Software ###<br>
Neutron, Icehouse, Havana, Grizzly, Folsom<br>
<br>
### Discussion ###<br>
When creating a virtual instance, a floating IP address is not<br>
allocated by default. After a virtual instance is created, a user can<br>
explicitly associate a floating IP address to that instance. Users can<br>
create connections to the virtual instance using this floating IP<br>
address. Also, this floating IP address can be disassociated from any<br>
running instance without shutting that instance down.<br>
<br>
If a user initiates a connection using the floating IP address, this<br>
connection remains alive and accessible even after the floating IP<br>
address is released from that instance. This potentially violates<br>
restrictive policies which are only being applied to new connections.<br>
These policies are ignored for pre-existing connections and the virtual<br>
instance remains accessible from the public network.<br>
<br>
This issue is only known to affect Neutron when using the L3 agent.<br>
Nova networking is not affected.<br>
<br>
### Recommended Actions ###<br>
There is unfortunately no easy way to detect which connections were<br>
made over a floating IP address from a virtual instance, as the NAT is<br>
performed at the Neutron router. The only safe way of terminating all<br>
connections made over a floating IP address is to terminate the virtual<br>
instance itself.<br>
<br>
The following recommendations should be followed when using the Neutron<br>
L3 agent:<br>
<br>
- - Only attach a floating IP address to a virtual instance when that<br>
instance should be accessible from networks outside the cloud.<br>
- - Terminate or stop the instance along with disassociating the floating<br>
IP address to ensure that all connections are closed.<br>
<br>
The Neutron development team plans to address this issue in a future<br>
version of Neutron.<br>
<br>
### Contacts / References ###<br>
This OSSN : <a href="https://wiki.openstack.org/wiki/OSSN/OSSN-0020" target="_blank">https://wiki.openstack.org/wiki/OSSN/OSSN-0020</a><br>
Original LaunchPad Bug : <a href="https://bugs.launchpad.net/neutron/+bug/1334926" target="_blank">https://bugs.launchpad.net/neutron/+bug/1334926</a><br>
OpenStack Security ML : <a href="mailto:openstack-security@lists.openstack.org">openstack-security@lists.openstack.org</a><br>
OpenStack Security Group : <a href="https://launchpad.net/~openstack-ossg" target="_blank">https://launchpad.net/~openstack-ossg</a><br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1<br>
<br>
iQEcBAEBAgAGBQJUF3r6AAoJEJa+6E7Ri+EVo+AH/i4GhZsFD3OJWlasq+XxkqqO<br>
W7g/6YQuKgRndl63UjnWAfpvJCA8Bl1msryb2K0tTZpDByVpgupPAf6+/NMZXvCT<br>
37YF236Ig/a/iLNjAdHRNHzq8Bhxe7tIikm1ICUH+Hyhob7soBlAC52lEJz9cFwb<br>
Hazo2K0jjt4TEyxAae06KsIuOV/n+tO7ginYxxv2g8DkhKik5PMi4x8j//DYFz92<br>
+SwPvUKeWiZ3JmD1M84Yj4VgPxah6fKDtCYKdTdcv7pYJGlcac8DTXbJkoFVd6H/<br>
v+XbBGWjg7+M7WlZJmDlC2XfWLVKBsREs3BAN/hagE6aKAyImT/gfyT0WxLpVIU=<br>
=Gk3u<br>
-----END PGP SIGNATURE-----<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div>