[ovs-dev] [PATCH v6 2/2] conntrack: handle SNAT with all-zero IP address

[Gaëtan Rivet]

On Wed, Apr 28, 2021, at 23:56, Paolo Valerio wrote:
> this patch introduces for the userspace datapath the handling
> of rules like the following:
> 
> ct(commit,nat(src=0.0.0.0),...)
> 
> Kernel datapath already handle this case that is particularly
> handy in scenarios like the following:
> 
> Given A: 10.1.1.1, B: 192.168.2.100, C: 10.1.1.2
> 
> A opens a connection toward B on port 80 selecting as source port 10000.
> B's IP gets dnat'ed to C's IP (10.1.1.1:10000 -> 192.168.2.100:80).
> 
> This will result in:
> 
> tcp,orig=(src=10.1.1.1,dst=192.168.2.100,sport=10000,dport=80),reply=(src=10.1.1.2,dst=10.1.1.1,sport=80,dport=10000),protoinfo=(state=ESTABLISHED)
> 
> A now tries to establish another connection with C using source port
> 10000, this time using C's IP address (10.1.1.1:10000 -> 10.1.1.2:80).
> 
> This second connection, if processed by conntrack with no SNAT/DNAT
> involved, collides with the reverse tuple of the first connection,
> so the entry for this valid connection doesn't get created.
> 
> With this commit, and adding a SNAT rule with 0.0.0.0 for
> 10.1.1.1:10000 -> 10.1.1.2:80 will allow to create the conn entry:
> 
> tcp,orig=(src=10.1.1.1,dst=10.1.1.2,sport=10000,dport=80),reply=(src=10.1.1.2,dst=10.1.1.1,sport=80,dport=10001),protoinfo=(state=ESTABLISHED)
> tcp,orig=(src=10.1.1.1,dst=192.168.2.100,sport=10000,dport=80),reply=(src=10.1.1.2,dst=10.1.1.1,sport=80,dport=10000),protoinfo=(state=ESTABLISHED)
> 
> The issue exists even in the opposite case (with A trying to connect
> to C using B's IP after establishing a direct connection from A to C).
> 
> This commit refactors the relevant function in a way that both of the
> previously mentioned cases are handled as well.
> 
> Suggested-by: Eelco Chaudron <echaudro at redhat.com>
> Signed-off-by: Paolo Valerio <pvalerio at redhat.com>

Thanks for addressing the comments,
Acked-by: Gaetan Rivet <grive at u256.net>

-- 
Gaetan Rivet