Open Stack

Hi!

  This is an interesting topic, I don't know if there's any way to
target connection tracker rules by MAC, but that'd be the ideal solution.

  I also understand the RETURN for RELATED,ESTABLISHED is there for
performance reasons, and removing it would lead to longer table evaluation,
and degraded packet throughput.

  Temporarily removing this entry doesn't seem like a good solution
to me as we can't really know how long do we need to remove this rule to
induce the connection to close at both ends (it will only close if any
new activity happens, and timeout is exhausted afterwards).


  Also, I'm not sure if removing all the conntrack rules that match the
certain filter would be OK enough, as it may only lead to full reevaluation
of rules for the next packet of the cleared connections (may be I'm missing 
some corner detail, which could be).


Best regards,
Miguel Ángel.



----- Original Message ----- 

> 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev