My Favorites

Close

Please to see your favorites.

  • Bookmark
  • Email Document
  • Printer Friendly
  • Favorite
  • Rating:

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.

Environment

SUSE OpenStack Cloud 4
SUSE OpenStack Cloud 5

Situation

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.

Resolution

This is expected behaviour.

Cause

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.

Additional Information

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.

Disclaimer

This Support Knowledgebase provides a valuable tool for NetIQ/Novell/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-15
  • Modified Date:17-FEB-17
    • NovellSUSE OpenStack Cloud
< Back to Support Search

SUSE Support Forums

Get your questions answered by experienced Sys Ops or interact with other SUSE community experts.

Join Our Community

Support Resources

Learn how to get the most from the technical support you receive with your SUSE Subscription, Premium Support, Academic Program, or Partner Program.


SUSE Customer Support Quick Reference Guide SUSE Technical Support Handbook Update Advisories
Support FAQ

Open an Incident

Open an incident with SUSE Technical Support, manage your subscriptions, download patches, or manage user access.

Go to Customer Center