[ovs-dev] [PATCH v2] conntrack: handle SNAT with NULL IP address

[Paolo Valerio]

Ben Pfaff <blp at ovn.org> writes:

> On Wed, Mar 31, 2021 at 07:18:03PM +0200, 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 NULL SNAT rule 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>
>
> I didn't really review this, but I'm uncomfortable with calling 0.0.0.0
> "NULL".  To me, in a C context especially, the term NULL in all caps is
> a null pointer.  I'd use 0.0.0.0 or the all-zero IP address or some
> other networking term instead of NULL.

ACK. That would be more accurate. Thanks.