[Jool-list] NAT64 behind NAT44?

[Alberto Leiva]

> That's exactly right. I know it would be better to run NAT64 on the router
> itself, but I don't have that option right now.

I still haven't been able to get the packet to bounce correctly, but
I'm thinking that this little hack is the only thing that
significantly sets your experiment apart from most tests that we've
run in Jool's history.

Also, I'm guessing that the reason why the clients' routing consists
only of a default route is because of DHCP?

So I'm wondering whether Router *needs* to be this default route.

What happens if you configure OpenWrt to be the default gateway of the
clients? My reasoning is that this would effectively delete the
"same-network"-ness of the bouncing as far as translation is
concerned. (Jool ignores traffic that's not headed to the pool6
prefix, so traffic not meant to be translated would be routed
normally.)

(I mean this as a workaround, not as a solution. Even if this proves
good enough for you, I still want to spot the real problem and patch
it properly.)

> > On the other hand, I can offer releasing commit 89b3c109 as Jool 3.5.8
> > right away*.
>
> That would be great. Not sure if it would solve this specific problem, but
> ruling out the offloading issue might simplify troubleshooting.

Actually... never mind.

I got my facts wrong; the #267 patch was not (and cannot be) merged
into 89b3c109's branch.

Jool 3.5.8 would not solve this problem.
On Wed, Nov 21, 2018 at 4:09 AM Maurice Walker <mail at maurice-walker.com> wrote:
>
> Hello Alberto!
>
> > That's what you're trying to do, right? The intended outbound route is
> > Client -> Router -> OpenWrt -> Router -> Internet,
> > while the intended inbound route is
> > Internet -> Router -> OpenWrt -> Client
> > Is this correct?
>
> That's exactly right. I know it would be better to run NAT64 on the router
> itself, but I don't have that option right now.
>
> > I tried to replicate it yesterday using virtual machines, but was
> > having a lot of trouble simply getting the Client -> Router -> OpenWrt
> > segment to work. (Which means that my packets didn't even reach Jool.)
>
> That works fine for me. On the router, I created a route for the NAT64
> prefix via OpenWrt's LAN address. On OpenWrt I configured the router's
> LAN addresses as the default gateways (IPv6 + IPv4). Could have used
> link-local addresses, but chose GUAs for simplicity.
>
> > But I do want to let you know that *we might need to wait until next
> > week to see any progress*. I'm sorry.
>
> No worries, I'm really thankful that you're taking the time to look into this!
>
> > On the other hand, I can offer releasing commit 89b3c109 as Jool 3.5.8
> > right away*.
>
> That would be great. Not sure if it would solve this specific problem, but
> ruling out the offloading issue might simplify troubleshooting.
>
> > I don't really know how long would it take for the
> > OpenWrt folk to mirror it once that's done.
>
> That might be an issue. It seems it took months for them to switch from
> 3.5.6 to 3.5.7. But I could try to contact them to speed things up.
>
> > I know that you're not
> > very confident about yours being the same problem as issue #267, but
> > "TCP Retransmissions, Out-Of-Orders and Dup ACKs" are precisely the
> > kind of traffic we get when offloads are not working correctly, and
> > that has *everything* to do with issue #267. I cannot guarantee that
> > it will solve the problem, but it has a pretty good chance.
>
> That absolutely makes sense. Unfortunately the issues didn't go away
> when I was running OpenWrt on actual hardware (an old consumer router
> I had laying around). And #267 is specifically about virtual NICs, right?
>
> > Just to confirm: Are offloads disabled?
>
> They are, using ethtool as explained in the Jool documentation. Here is
> OpenWrt's /etc/rc.local:
>
> ethtool --offload eth0 gro off
> ethtool --offload eth0 lro off
> insmod jool disabled=1 pool6=2001:db8:1:64::/96
> jool --source-icmpv6-errors-better=on
> jool --enable
>
>
> Maurice