Security Group allowing traffic to VM doesn't seem to be reset after disassociation
This document (7016641) is provided subject to the disclaimer at the end of this document.
SUSE OpenStack Cloud 5
When using Security Group to allow the network access to VM, SG rules don't seem to be reset after disassociation.
Steps to reproduce:
- Boot an instance with floating IP and default security group (no trafic allowed)
- Ping instance, no response received.
- Create security group with rule allowing ICMP from <your_ip>/32
- Associate security group with VM
- Ping instance, response is received
- Dissociate security group from VM
- 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.
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.
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
For more details see e.g.: http://www.iptables.info/en/connection-state.html#ICMPCONNECTIONS
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.
This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.
- Document ID:7016641
- Creation Date: 30-Jun-2015
- Modified Date:03-Mar-2020
- SUSE Open Stack Cloud
For questions or concerns with the SUSE Knowledgebase please contact: firstname.lastname@example.org