Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
I want to use a dual stack machine on Internet to NAT64 traffic to IPv4 services:
Suppose the box has IP address
I followed https://www.jool.mx/en/single-interface.html but still got no luck:
I think your problem is simply that you're trying to execute your ping in the
See the Basic Netfilter/iptables chains diagram. Jool is hooked to
To test Jool properly, you have to issue the ping from any node in
For the record: I don't know if Jool does the right thing if you add rules to anything other than
Several years ago, I once tried to hook Jool to
If you really want your translator machine to translate its own traffic, you can use network namespaces.
@ydahhrk I tried ping from another machine, it did work! Thank you very much!
One annoying thing is
I think there are two possible solutions for this:
If this value does what I think it does, it should be possible to abort the Jool iptables rule even when the packet matched. (This would return the packet to the kernel, which would handle the ping normally.)
Create Jool iptables matches. Something like
Option B would have the added benefit of reducing redundant configuration (as you would no longer need to specify multiple ip(v4)tables rules, and you would no longer need to repeat addresses and ports (
Edit: On the other hand, Option A might perform somewhat faster due to locking constraints.
Do you prefer one of these options?
I prefer option A:
About option A, I have two questions:
Not that I'm trying to defend option B, but I suspect you're misunderstanding the BIB. Here's some food for thought:
(BTW: I'm assuming that by "router" you mean "translator." Please correct me if I'm wrong.)
I don't understand this either. The way I see it, the packet flow would be
The way I see it, this behaves the same whether it's option A or B.
Why? Is this is this known to be harmful?
Even if iptables Jool returns everything to the kernel, the admin will still be expected to separate pool4 and the ephemeral range. If the two ranges overlap, then connection collision will happen, regardless of whether we choose option A or B.
My initial tendency would be to return IPv6 packets whose destination addresses do not match pool6, and IPv4 packets whose destination addresses do not match pool4.
And this made me realize that Option B is wrong:
It would have to be "
What is a "passthrough option"?
iptables rules must be associated with an instance (
BIB is a source NAT table to record IPv6 source address(the client that initiated IPv6->IPv4 connection) and dynamic IPv4 source address(the translator that initiated IPv4->IPv4 connection), correct me if I'm wrong :-)
Here I omit the port in the BIB table because we mainly discuss ICMP.
Yes, you are right, sorry I changed the word,
The packet flow is same with what I understood, thanks for your detailed explanation, I realized I forgot that option A also didn't work in some scenario, let me summarize:
Actually in this analysis the original client-IPv6 doesn't have to be router-IPv6,
Don't misunderstand me, Jool is the most feature-rich and well-documented SIT/NAT64 open source implementation I investigated, you are very appreciated for this wonderful work!
I prefer explicit '-d IP' instead of '-m jool' to avoid entering Jool, that's just for potentially better performance and less bug, frankly speaking, Jool iptables extension isn't used as widely as iptables standard extensions although I'm fully respect your code quality, there are too many details in Linux network stack, so less code path usually means less bug.
Agree, overlapping is too risky, I had the fluke mind that collision wouldn't happen often.
I mean a Jool option to control whether to drop packet or return packet to kernel if no BIB entry found for a reply packet. This option can be global or per instance.
But as I analyzed in above comment, it's hard to make local ICMPv4 work, so maybe it's not worth handling it, just have some way to bypass it, for example, assign multiple IPv4 address to translator box and don't include default IPv4 address in pool4.
Ok, I agree with everything.
Indeed; since TCP and UDP identify connections via ports, it is possible to separate the ephemeral range from pool4. ICMP identify connections via
However, ICMP collision is far less likely than TCP/UDP collision, because pings are not as ubiquitous as TCP/UDP sockets.
I'll try to implement Option A. BRB.
Ok, so I implemented a prototype of this in the
Because Netfilter Jool already returned packets to the kernel in certain circumstances, all I did was unify the Netfilter and iptables "return packet to the kernel" code blocks. Hopefully, they will not need to behave differently.
The documentation doesn't specify exactly when a "packet return" is performed (as opposed to a "packet drop"), so I will detail the current behavior now.
SIIT Jool also returns the packet to the kernel when at least one of these conditions are met:
Stateful NAT64 Jool also returns the packet to the kernel when at least one of these conditions are met:
Any concerns with these changes?
I glanced at the document above and the patch, they look fine to me, sane to keep behavior consistent between netfilter and iptables.
I also built the prototype branch and verified the behaviour, it worked like a charm,
Great work! Thank you very much for pointing out my wrong test and further making local traffic work, amazing!