[openstack-dev] [Neutron] Killing connection after security group rule deletion

Elena Ezhova eezhova at mirantis.com
Thu Oct 23 10:22:46 UTC 2014


Hi!

I am working on a bug "ping still working once connected even after related
security group rule is deleted" (
https://bugs.launchpad.net/neutron/+bug/1335375). The gist of the problem
is the following: when we delete a security group rule the corresponding
rule in iptables is also deleted, but the connection, that was allowed by
that rule, is not being destroyed.
The reason for such behavior is that in iptables we have the following
structure of a chain that filters input packets for an interface of an
istance:

Chain neutron-openvswi-i830fa99f-3 (1 references)
 pkts bytes target     prot opt in     out     source
destination
    0     0 DROP       all  --  *      *       0.0.0.0/0
0.0.0.0/0            state INVALID /* Drop packets that are not associated
with a state. */
    0     0 RETURN     all  --  *      *       0.0.0.0/0
0.0.0.0/0            state RELATED,ESTABLISHED /* Direct packets associated
with a known session to the RETURN chain. */
    0     0 RETURN     udp  --  *      *       10.0.0.3
0.0.0.0/0            udp spt:67 dpt:68
    0     0 RETURN     all  --  *      *       0.0.0.0/0
0.0.0.0/0            match-set IPv43a0d3610-8b38-43f2-8 src
    0     0 RETURN     tcp  --  *      *       0.0.0.0/0
0.0.0.0/0            tcp dpt:22      <---- rule that allows ssh on port 22

    1    84 RETURN     icmp --  *      *       0.0.0.0/0
0.0.0.0/0
    0     0 neutron-openvswi-sg-fallback  all  --  *      *       0.0.0.0/0
           0.0.0.0/0            /* Send unmatched traffic to the fallback
chain. */

So, if we delete rule that allows tcp on port 22, then all connections that
are already established won't be closed, because all packets would satisfy
the rule:
0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0
         state RELATED,ESTABLISHED /* Direct packets associated with a
known session to the RETURN chain. */

I seek advice on the way how to deal with the problem. There are a couple
of ideas how to do it (more or less realistic):

   - Kill the connection using conntrack

          The problem here is that it is sometimes impossible to tell which
connection should be killed. For example there may be two instances running
in different namespaces that have the same ip addresses. As a compute
doesn't know anything about namespaces, it cannot distinguish between the
two seemingly identical connections:
         $ sudo conntrack -L  | grep "10.0.0.5"
         tcp      6 431954 ESTABLISHED src=10.0.0.3 dst=10.0.0.5
sport=60723 dport=22 src=10.0.0.5 dst=10.0.0.3 sport=22 dport=60723
[ASSURED] mark=0 use=1
         tcp      6 431976 ESTABLISHED src=10.0.0.3 dst=10.0.0.5
sport=60729 dport=22 src=10.0.0.5 dst=10.0.0.3 sport=22 dport=60729
[ASSURED] mark=0 use=1

I wonder whether there is any way to search for a connection by destination
MAC?

   - Delete iptables rule that directs packets associated with a known
   session to the RETURN chain

           It will force all packets to go through the full chain each time
and this will definitely make the connection close. But this will strongly
affect the performance. Probably there may be created a timeout after which
this rule will be restored, but it is uncertain how long should it be.

Please share your thoughts on how it would be better to handle it.

Thanks in advance,
Elena
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141023/083574fd/attachment.html>


More information about the OpenStack-dev mailing list