[Jool-list] not NAT64ing packets

Tue Jan 7 15:50:54 CST 2020

Uh, that's weird. I'm not receiving your responses. (I'm querying the
list archives to see them.) Did you do something to the recipients
list?

In any case, here are the answers to your questions:

> Does the jool kernel module have any option/ability to print debugging
> messages about what it's doing?

It's a compilation flag. [0]
I imagine it's unavailable in OpenWRT.

[0] https://github.com/NICMx/Jool/wiki/Jool's-Compilation-Options#-ddebug

> But just to be clear, with 3.5.6, nothing more than modprobing the
> module with a pool6 is necessary to have it start NATting between the
> pool6 addresses and their IPv4 equivillents, correct?

Right. Though note that Jool 3.5 is particularly prone to suboptimal
and/or nonstandard behavior if you omit the sysctl and ethtool
commands. (Which can be found in the documentation.)

> Is any other option needed/useful when NATting between an IPv6 LAN and
> a single IPv4 WAN address?  So not 1:1 IPv6:IPv4 addresses, but rather
> multiple IPv6 addresses port mapped through a single IPv4 address, just
> like regular NAT44 with a single LAN address.

Well, if you want, you can expand Jool's available IPv4 transport
addresses pool by way of --pool4.

See en/pool4.html and en/usr-flags-pool4.html in the documentation.

Port forwarding is BIB. See en/bib.html and en/usr-flags-bib.html.

On Tue, Jan 7, 2020 at 2:56 PM Alberto Leiva <ydahhrk at gmail.com> wrote:
>
> It seems the reason why it's not working is because Jool is lacking a pool6.
> You cannot send arguments (such as pool6) when you enable Jool via
> modprobe. This is an OpenWRT quirk.
>
> Per the OpenWRT documentation ([0]), you have to use insmod:
>
>         # insmod jool pool6=64:ff9b::/96
>
> (You will first have to remove your current module via rmmod though.)
>
> Or you can just ditch those obsolete module arguments and add pool6
> via the client instead:
>
>         # jool --pool6 --add 64:ff9b::/96
>
> [0] https://jool.mx/en/openwrt.html
>
> On Tue, Jan 7, 2020 at 12:57 PM Alberto Leiva <ydahhrk at gmail.com> wrote:
> >
> > Also:
> >
> > > The router has since rebooted and
> > > the module didn't get automatically reloaded, so I will have to
> > > investigate why/how to do that, but that's not relevant here.
> >
> > Just to clarify: Version 3.5.6 did not include any boot-init scripts
> > as far as I know.
> >
> > Unless you added this functionality yourself, not starting
> > automatically on boot is expected behavior.
> >
> > On Tue, Jan 7, 2020 at 12:45 PM Alberto Leiva <ydahhrk at gmail.com> wrote:
> > >
> > > Works for me. Though admittedly I'm testing 3.5.6 on Ubuntu since my
> > > OpenWRT VM died some time ago.
> > >
> > > Will try to create a new OpenWRT VM. In the meantime, a couple of
> > > typical troubleshooting questions off the top of my head:
> > >
> > > - Does your translator have a route towards 1.1.1.1? (Can you ping
> > > both 2001:123:ab:123:16da:e9ff:fe48:f99e and 1.1.1.1 from the
> > > translator when Jool isn't modprobed?)
> > > - Is Jool printing something in dmesg?
> > >
> > > On Tue, Jan 7, 2020 at 10:23 AM Brian J. Murrell <brian at interlinx.bc.ca> wrote:
> > > >
> > > > I'm using 3.5.6.0 on OpenWrt 18.06.4.  Yes, I know it's old and
> > > > stricken but it was working for me for a while and 19.07.x is right
> > > > around the corner.  Hopefully.  :-)  The router has since rebooted and
> > > > the module didn't get automatically reloaded, so I will have to
> > > > investigate why/how to do that, but that's not relevant here.
> > > >
> > > > In any case after the reboot I inserted the module manually:
> > > >
> > > > # modprobe jool pool6=64:ff9b::/96
> > > > # lsmod | grep jool
> > > > crypto_hash             8288  2 jool,md5
> > > > jool                  101424  0
> > > > nf_defrag_ipv4           800  4 jool,xt_socket,xt_TPROXY,nf_conntrack_ipv4
> > > > nf_defrag_ipv6          4304  4 jool,xt_socket,xt_TPROXY,nf_conntrack_ipv6
> > > >
> > > > So it seems to be loaded OK.  It just doesn't seem to be NAT64ing
> > > > packets:
> > > >
> > > > # ping 64:ff9b::1.1.1.1
> > > > PING 64:ff9b::1.1.1.1(64:ff9b::101:101) 56 data bytes
> > > > [nothing]
> > > >
> > > > Those packets are making it to the router:
> > > >
> > > > # tcpdump -i br-lan -s 0 -n net 64:ff9b::/96
> > > > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> > > > listening on br-lan, link-type EN10MB (Ethernet), capture size 262144 bytes
> > > > 11:18:40.500058 IP6 2001:123:ab:123:16da:e9ff:fe48:f99e > 64:ff9b::101:101: ICMP6, echo request, seq 53, length 64
> > > > 11:18:41.524101 IP6 2001:123:ab:123:16da:e9ff:fe48:f99e > 64:ff9b::101:101: ICMP6, echo request, seq 54, length 64
> > > > 11:18:42.548170 IP6 2001:123:ab:123:16da:e9ff:fe48:f99e > 64:ff9b::101:101: ICMP6, echo request, seq 55, length 64
> > > > 11:18:43.572236 IP6 2001:123:ab:123:16da:e9ff:fe48:f99e > 64:ff9b::101:101: ICMP6, echo request, seq 56, length 64
> > > >
> > > > but the corresponding ipv4 packets are not being sent on the WAN
> > > > interface:
> > > >
> > > > # tcpdump -i eth0.2 -n -s 0 host 1.1.1.1
> > > > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> > > > listening on eth0.2, link-type EN10MB (Ethernet), capture size 262144 bytes
> > > > ^C
> > > > 0 packets captured
> > > > 9 packets received by filter
> > > > 0 packets dropped by kernel
> > > >
> > > > Is there something I am missing/forgetting other than to just "modprobe
> > > > jool pool6=64:ff9b::/96"?
> > > >
> > > > Cheers,
> > > > b.
> > > >
> > > > _______________________________________________
> > > > Jool-list mailing list
> > > > Jool-list at nic.mx
> > > > https://mail-lists.nic.mx/listas/listinfo/jool-list