Nicolas Dichtel <[email protected]> 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 <[email protected]> > 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 _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
