Hi Pablo, On 05/04/2015 12:34 PM, Pablo Neira Ayuso wrote:
On Mon, May 04, 2015 at 12:23:41PM +0200, Daniel Borkmann wrote:This patch adds support for the possibility of doing NAT with conflicting IP address/ports tuples from multiple, isolated tenants, represented as network namespaces and netfilter zones. For such internal VRFs, traffic is directed to a single or shared pool of public IP address/port range for the external/public VRF. Or in other words, this allows for doing NAT *between* VRFs instead of *inside* VRFs without requiring each tenant to NAT twice or to use its own dedicated IP address to SNAT to, also with the side effect to not requiring to expose a unique marker per tenant in the data center to the public. Simplified example scheme: +--- VRF A ---+ +--- CT Zone 1 --------+ | 10.1.1.1/8 +--+ 10.1.1.1 ESTABLISHED | +-------------+ +--+-------------------+ | +--+--+ | L3 +-SNAT-[20.1.1.1:20000-40000]--eth0 +--+--+ | +-- VRF B ----+ +--- CT Zone 2 --------+ | 10.1.1.1/8 +--+ 10.1.1.1 ESTABLISHED | +-------------+ +----------------------+So, it's the skb->mark that survives between the containers. I'm not sure it makes sense to keep a zone 0 from the container that performs SNAT. Instead, we can probably restore the zone based on the skb->mark. The problem is that the existing zone is u16. In nftables, Patrick already mentioned about supporting casting so we can do something like: ct zone set (u16)meta mark So you can reserve a part of the skb->mark to map it to the zone. I'm not very convinced about this.
Thanks for the feedback! I'm not yet sure though, I understood the above suggestion to the described problem fully so far, i.e. how would replies on the SNAT find the correct zone again? Our issue simplified, basically boils down to: given are two zones, both use IP address <A>, both zones want to talk to IP address <B> in a third zone. To let those two with <A> talk to <B>, connections are being routed + SNATed from a non-unique to a unique address/port tuple [which the proposed approach solves], so they can talk to <B>. 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
