Now there is already a bug: for 
this problem, meanwhile the security group also has same problem, I have report 
a bug:

在 2014-09-16 01:46:11,"Martinx - ジェームズ" <> 写道:

Hey stackers,

Let me ask something about this... Why not use Linux Conntrack Table at each 
Tenant Namespace (L3 Router) to detect which connections were
made/established over a Floating IP ?

Like this, on the Neutron L3 Router:

apt-get install conntrack

ip netns exec qrouter-09b72faa-a5ef-4a52-80b5-1dcbea23b1b6 conntrack -L | grep 

tcp      6 431998 ESTABLISHED src= dst= sport=36476 
dport=8333 src= dst= sport=8333 dport=36476 [ASSURED] 
mark=0 use=1

Floating IP:
Instance IP:


Or, as a workaround, 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...     ;-)


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:

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...     =)

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.


On 15 September 2014 20:49, Nathan Kinder <> wrote:
Hash: SHA1

Disassociating floating IPs does not terminate NAT connections with
Neutron L3 agent
- ---

### Summary ###
Every virtual instance is automatically assigned a private IP address.
You may optionally assign public IP addresses to instances. OpenStack
uses the term "floating IP" to refer to an IP address (typically
public) that can be dynamically added to a running virtual instance.
The Neutron L3 agent uses Network Address Translation (NAT) to assign
floating IPs to virtual instances. Floating IPs can be dynamically
released from a running virtual instance but any active connections are
not terminated with this release as expected when using the Neutron L3

### Affected Services / Software ###
Neutron, Icehouse, Havana, Grizzly, Folsom

### Discussion ###
When creating a virtual instance, a floating IP address is not
allocated by default. After a virtual instance is created, a user can
explicitly associate a floating IP address to that instance. Users can
create connections to the virtual instance using this floating IP
address. Also, this floating IP address can be disassociated from any
running instance without shutting that instance down.

If a user initiates a connection using the floating IP address, this
connection remains alive and accessible even after the floating IP
address is released from that instance. This potentially violates
restrictive policies which are only being applied to new connections.
These policies are ignored for pre-existing connections and the virtual
instance remains accessible from the public network.

This issue is only known to affect Neutron when using the L3 agent.
Nova networking is not affected.

### Recommended Actions ###
There is unfortunately no easy way to detect which connections were
made over a floating IP address from a virtual instance, as the NAT is
performed at the Neutron router. The only safe way of terminating all
connections made over a floating IP address is to terminate the virtual
instance itself.

The following recommendations should be followed when using the Neutron
L3 agent:

- - Only attach a floating IP address to a virtual instance when that
instance should be accessible from networks outside the cloud.
- - Terminate or stop the instance along with disassociating the floating
IP address to ensure that all connections are closed.

The Neutron development team plans to address this issue in a future
version of Neutron.

### Contacts / References ###
This OSSN :
Original LaunchPad Bug :
OpenStack Security ML :
OpenStack Security Group :
Version: GnuPG v1


OpenStack-dev mailing list

OpenStack-dev mailing list

Reply via email to