Messages in this thread | | | From | Aaron Conole <> | Subject | Re: [PATCH net 1/2] openvswitch: support asymmetric conntrack | Date | Mon, 18 Nov 2019 16:19:29 -0500 |
| |
Nicolas Dichtel <nicolas.dichtel@6wind.com> writes:
> Le 08/11/2019 à 22:07, Aaron Conole a écrit : >> The openvswitch module shares a common conntrack and NAT infrastructure >> exposed via netfilter. It's possible that a packet needs both SNAT and >> DNAT manipulation, due to e.g. tuple collision. Netfilter can support >> this because it runs through the NAT table twice - once on ingress and >> again after egress. The openvswitch module doesn't have such capability. >> >> Like netfilter hook infrastructure, we should run through NAT twice to >> keep the symmetry. >> >> Fixes: 05752523e565 ("openvswitch: Interface with NAT.") >> Signed-off-by: Aaron Conole <aconole@redhat.com> > In this case, ovs_ct_find_existing() won't be able to find the > conntrack, right?
vswitchd normally won't allow both actions to get programmed. Even the kernel module won't allow it, so this really will only happen when the connection gets established via the nf_hook path, and then needs to be processed via openvswitch. In those cases, the tuple lookup should be correct, because the nf_nat table should contain the correct tuple data, and the skbuff should have the correct tuples in the packet data to begin with.
> Inverting the tuple to find the conntrack doesn't work anymore with double NAT. > Am I wrong?
I think since the packet was double-NAT on the way out (via nf_hook path), then the incoming reply will have the correct NAT tuples and the lookup will happen just fine. Just that during processing, both transformations aren't applied.
Makes sense?
> Regards, > Nicolas
| |