If you exec conntrack inside the namespace with ip netns exec does it still show both connections?
Vish On Oct 23, 2014, at 3:22 AM, Elena Ezhova <eezh...@mirantis.com> wrote: > 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 > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
