Messages in this thread | | | Subject | Re: [PATCH net 1/2] openvswitch: support asymmetric conntrack | From | Nicolas Dichtel <> | Date | Thu, 28 Nov 2019 09:22:18 +0100 |
| |
Le 18/11/2019 à 22:19, Aaron Conole a écrit : > 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. Ok, I didn't look deeply, thank you for the explanation.
Regards, Nicolas
| |