Security Group allowing traffic to VM doesn't seem to be reset after disassociation

When using Security Group to allow the network access to VM, SG rules don't seem to be reset after disassociation.

Steps to reproduce:

1. Boot an instance with floating IP and default security group (no trafic allowed)
   
2. Ping instance, no response received.
3. Create security group with rule allowing ICMP from <your_ip>/32
4. Associate security group with VM
5. Ping instance, response is received
6. Dissociate security group from VM
7. Ping instance, response is still received.
   

This is expected behaviour.

The iptables rules created by Neutron enable connection tracking (for performance reasons) so that every package that is related to an already established connection can pass the firewall without any additional checking.

The downside of that is that when you delete a rule, connection that is already established won't be affected and packets still pass through.

To verify that the connection tracking is the cause of the problem, start another ping command to the same floating IP and those packets should be blocked.

There is an exception. When ping is originated from Windows machine, the response is still received. The different behaviour on Windows can be explained because Windows' implementation of "ping" is always using the same value for the "id" parameter for the "echo request" of ICMP packets while ping on Linux chooses a different value for "id" every time ping is called.

The connection tracking implementation of the Linux kernel has a special handling for ICMP echo requests and replies (as ICMP is not a real connection oriented protocol). Basically it considers all ICMP echo/reply packets that share the same id as being originated by the same connection (once at least one successful request/reply round trip happened).

For more details see e.g.: http://www.iptables.info/en/connection-state.html#ICMPCONNECTIONS

So as all ICMP Echo Request send from a Windows machine share the same "id" it considers them to be part of the same connection. Only after the connection entry in the internal table of the kernel is expired (which happens 30 seconds after the last successful packet for a connection was sent) newly started ping commands stops working.

Note: This is really specific to ICMP packets (specifically ping echo request/reply). For TCP connections originating from Windows the behavior should be the same as on Linux.