Hi Pablo,
On 05/07/2015 08:10 PM, Pablo Neira Ayuso wrote:
On Thu, May 07, 2015 at 02:01:11PM +0200, Daniel Borkmann wrote:
...
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.
Okay, agreed. I will respin the set with --flextuple ORIGINAL direction
allowed where we'd for now only consume a single status bit. If later
on there's a need to extend this for REPLY (or even hybrid), we still
have the option to extend it.
I would like to know if it makes sense to add this later on. Would you
elaborate a useful DNAT scenario where this can be useful?
What comes to mind in case of hybrid usage for firewalling would be that
flextuple in both directions would act similarly as zones, for example,
you could map things like tunnel id into u32 space and include that into
the match'er w/o many additional rules or memory overhead.
For the reply-only, case I was thinking about a case where you'd have
multiple containers behind the DNAT all with same ip/port each where a
server listens on and you'd select one of the containers e.g. via
xt_statistic module as a mark and do mark-based routing behind the DNAT,
but that itself still has the source in front of the DNAT unique, so it
wouldn't need a mark inclusion in the reply case. So for reply-only, I
currently don't find an intuitive use case.
Best,
Daniel
--
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
