Hi Daniel, On Wed, May 06, 2015 at 08:00:42PM +0200, Daniel Borkmann wrote: > On 05/06/2015 04:27 PM, Pablo Neira Ayuso wrote: [...] > >But what is the use case for -j CT --flextuple reply ? By when you see > >the reply packet the tuple was already created. > > Given this change is completely NAT agnostic, we can keep it as a > generic addition to the conntracker. Given that the mark is very > flexible, I think it could also be used for load balancing as a > different usage. The original and reply tuples of the conntrack are set by the first packet going in the original direction, at that time they are both inserted in the hashes, in this scenario it will use the default mark (0). So if you set the --flextuple reply, conntrack will include the mark as part of the hashtuple in the first reply packet, but that packet will not match the conntrack object that was created by the first original packet and it will result a new conntrack assuming that the reply is the original direction. This looks broken to me. > >Another question is if it makes sense to have part of the flows using > >your flextuple idea while some others not, ie. > > > > -s x.y.z.w/24 -j CT --flextuple original > > > >so shouldn't this be a global switch that includes the skb->mark > >only for packets coming in the original direction? > > I first thought about a global sysctl switch, but eventually found > this config possibility from iptables side much cleaner resp. better > integrated. I think if the environment is correctly configured for > that, such a partial flextuple scenario works, too. This is consuming two ct status bits, these are exposed to userspace, and we have a limited number of bits there. The one in the original direction might be justified for the SNAT case in the specific scenario that you show. I don't see yet how this can make sense in a hybrid scenario. We may end up with a packet that can potentially create and match two different flow objects if this is misconfigured. > >I also wonder how you're going to deal with port redirections. This > >only seem to be working SNAT/masquerade to me if the NAT happens from > >VRF side. > > In our case, we'd like to use the flextuple when we're explicitly > configuring iptables with SNAT. For DNAT, one could reuse it in a > different, somewhat reversed example we previously had and together > with mark based routing and match on the reply side. OK, so different VRFs with overlapping networks that are redirected to the port of another destination. That might makes sense. Still the hybrid scenario and the --flextuple reply need some thinking. Thanks. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
