Locally originating packages

[agowa]

Hi, because jool hooks into the PREROUTING table it doesn't handle locally originating packages.
Just adding a rule to the OUTPUT table doesn't make it work either.
Would it be possible to get this feature? I don't think it's fair to say that "464XLAT" is fully supported without honoring local traffic.

The issue behind this request is:

• Setting up network namespaces dynamically (if the upstream prefix changes) is complicated and not something I'd like to recommend to anyone.
• Setting up jool in a separate namespace requires NAT44 and NAT66 which further complicates the setup.
• When the jool box itself gets it's DNS from the DNS64 other applications will try to connect to the NAT64-Prefix first and hang until they ran into a timeout. Some apps then don't try other IPs at all.
• Putting jool into a network namespace doesn't work if the upstream network changes (like when jool is the router of a testlab on a notebook), when the upstream does not have prefix delegation or only assigns a single IPv6 via DHCPv6.
• It makes debugging more complicated and unintuitive. Many may incorrectly assume jool is malfunctioning when a ping 64:ff9b::1.1.1.1 from the jool router fails.

Also related to:

• https://nicmx.github.io/Jool/en/faq.html#why-is-my-ping-not-working
• https://mail-lists.nic.mx/pipermail/jool-list/2022-June/000476.html

[ydahhrk]

Sorry for the silence.

Yes, a lot of people has complained about this. AFAIK, the problem is not trivial to fix and it's consequence of Jool's awkward hookup to the kernel.

I'm currently writing a message to the nftables people so we can discuss this. Please be patient. Because I have to do this on my free time, I'm forced to research at a slow pace.

[ydahhrk]

Yes, a lot of people has complained about this. AFAIK, the problem is not trivial to fix and it's consequence of Jool's awkward hookup to the kernel.

IIRC, the problem is that Jool switches the packet's pipeline (from the IPv4 stack to the IPv6 stack or vice versa) by routing and then calling dst_output(), which sends the packet to the proper L3 layer's POSTROUTING code.

When I coded this, I was unable to find a public kernel function that would allow me to do the same for LOCAL_IN. This is the reason why I can't get any packet to the current namespace.

I'm not sure if LOCAL_OUT had a similar problem. It's been ~10 years.