| Message ID | 20191108210714.12426-1-aconole@redhat.com |
|---|---|
| State | Awaiting Upstream |
| Headers | show |
| Series | [ovs-dev,net,1/2] openvswitch: support asymmetric conntrack | expand |
On Fri, Nov 8, 2019 at 1:07 PM Aaron Conole <aconole@redhat.com> wrote: > > 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> The patch looks ok. But I am not able apply it. can you fix the encoding.
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? Inverting the tuple to find the conntrack doesn't work anymore with double NAT. Am I wrong? Regards, Nicolas
Pravin Shelar <pshelar@ovn.org> writes: > On Fri, Nov 8, 2019 at 1:07 PM Aaron Conole <aconole@redhat.com> wrote: >> >> 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> > > The patch looks ok. But I am not able apply it. can you fix the encoding. Hrrm. I didn't make any special changes (just used git send-email). I will look at spinning a second patch.
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
Aaron Conole <aconole@redhat.com> writes: > Pravin Shelar <pshelar@ovn.org> writes: > >> On Fri, Nov 8, 2019 at 1:07 PM Aaron Conole <aconole@redhat.com> wrote: >>> >>> 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> >> >> The patch looks ok. But I am not able apply it. can you fix the encoding. > > Hrrm. I didn't make any special changes (just used git send-email). I > will look at spinning a second patch. Pravin, I tried the following: 10:36:59 aconole@dhcp-25 {(312434617cb1...)} ~/git/linux$ curl http://patchwork.ozlabs.org/patch/1192219/mbox/ > test.patch % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 4827 100 4827 0 0 8824 0 --:--:-- --:--:-- --:--:-- 8808 10:37:21 aconole@dhcp-25 {(312434617cb1...)} ~/git/linux$ git am test.patch Applying: openvswitch: support asymmetric conntrack 10:37:24 aconole@dhcp-25 {(f759cc2b7323...)} ~/git/linux$ Can you check your mailer settings? The patchwork mbox worked fine, and I was able to apply from my own mbox as well. -Aaron
Downloading from patchwork is working for me. Its strange other patches in my mailbox does not has this issue. Thanks. On Mon, Nov 25, 2019 at 7:39 AM Aaron Conole <aconole@redhat.com> wrote: > > Aaron Conole <aconole@redhat.com> writes: > > > Pravin Shelar <pshelar@ovn.org> writes: > > > >> On Fri, Nov 8, 2019 at 1:07 PM Aaron Conole <aconole@redhat.com> wrote: > >>> > >>> 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> > >> > >> The patch looks ok. But I am not able apply it. can you fix the encoding. > > > > Hrrm. I didn't make any special changes (just used git send-email). I > > will look at spinning a second patch. > > Pravin, > > I tried the following: > > 10:36:59 aconole@dhcp-25 {(312434617cb1...)} ~/git/linux$ curl http://patchwork.ozlabs.org/patch/1192219/mbox/ > test.patch > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 100 4827 100 4827 0 0 8824 0 --:--:-- --:--:-- --:--:-- 8808 > 10:37:21 aconole@dhcp-25 {(312434617cb1...)} ~/git/linux$ git am test.patch > Applying: openvswitch: support asymmetric conntrack > 10:37:24 aconole@dhcp-25 {(f759cc2b7323...)} ~/git/linux$ > > > Can you check your mailer settings? The patchwork mbox worked fine, and > I was able to apply from my own mbox as well. > > -Aaron >
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
diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c index 05249eb45082..283e8f9a5fd2 100644 --- a/net/openvswitch/conntrack.c +++ b/net/openvswitch/conntrack.c @@ -903,6 +903,17 @@ static int ovs_ct_nat(struct net *net, struct sw_flow_key *key, } err = ovs_ct_nat_execute(skb, ct, ctinfo, &info->range, maniptype); + if (err == NF_ACCEPT && + ct->status & IPS_SRC_NAT && ct->status & IPS_DST_NAT) { + if (maniptype == NF_NAT_MANIP_SRC) + maniptype = NF_NAT_MANIP_DST; + else + maniptype = NF_NAT_MANIP_SRC; + + err = ovs_ct_nat_execute(skb, ct, ctinfo, &info->range, + maniptype); + } + /* Mark NAT done if successful and update the flow key. */ if (err == NF_ACCEPT) ovs_nat_update_key(key, skb, maniptype);
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> --- net/openvswitch/conntrack.c | 11 +++++++++++ 1 file changed, 11 insertions(+)