6 ms·

For those if us who do want to run our own NAT64 box, is there a decent Linux option these days? Last time I looked, your options were variations on "this isn't

For those if us who do want to run our own NAT64 box, is there a decent Linux option these days? Last time I looked, your options were variations on "this isn't packaged so just compile this source tarball and feed it this non-obvious config"... or OpenBSD which just treats it as a first-class option in pf(?) exactly like nat44. (And yes I'm tempted, but adding an OpenBSD router is a sharper learning curve...)

Arnavion 2y ago
I haven't tried NAT64 on a Linux router, so I can't say authoritatively. I did a similar experiment as the submitted article back in 2020, though that was on a pfSense (FreeBSD) router, not Linux. I used tayga for NAT64 there, which was last released in 2010, but it probably still works on modern Linux. At the very least it's still packaged in Debian. Someone has made a NAT64 implementation using eBPF, though with quite some caveats: https://github.com/xdp-project/bpf-examples/tree/master/nat64-bpf https://github.com/xdp-project/bpf-examples/tree/master/nat6...
- qhwudbebd 2y ago
  The nat64/clat situation on Linux is not brilliant at the moment. There are userspace implementations like Tayga and Tundra. These incur kernel-userspace-kernel transition for each packet so are pretty inefficient and struggle unnecessarily on low-end hardware. Then there are out-of-tree modules of varying quality, none of those I've looked at being amazingly inspiring code-wise. As out-of-tree modules, they'd need to be rebuilt whenever you rebuild your kernel, but would inconveniently not be built as part of that kernel unless you patch them in. I'd not seen the eBPF implementation before. That's quite a nice idea. Quite tempted to have a hack at that to fix the minor issues the author identifies. (What's the story with building eBPF programs nowadays? Are there all kinds of crazy dependencies, or is the situation better than it used to be?)
- yjftsjthsd-h 2y ago
  So tayga was the tool that I came the closest to using last time I looked at this, but rereading http://www.litech.org/tayga/ http://www.litech.org/tayga/ I still don't really follow the configuration (yes I know it's a skill issue but nat44 wasn't this hard), the tun device is... I guess it should be fine, but I don't like needing it, and the whole thing looks very manual (I'd bet that doesn't persist after a reboot) though I guess I should see if someone's packaged up a nice systemd unit that makes it all work. The eBPF one is very interesting and does seem to work the way I expect NAT to work (no extra interfaces, just rewriting packets as they come and go), but is 1. unfinished by its own description, and 2. again a 3rd-party code drop that I'd have to package and ship myself if I wanted to use it. And I can do that, but I really don't like my routers to need fiddling.
  - Arnavion 2y ago
    You can refer to https://www.arnavion.dev/blog/2020-04-18-i-switched-my-home-network-to-ipv6/#level-4-turn-off-ipv4-aka-how-to-run-tayga-on-pfsense https://www.arnavion.dev/blog/2020-04-18-i-switched-my-home-... which is about my pfSense attempt. It has the six-line tayga config and hopefully enough surrounding explanation to make it clear, and then instead of the rc script I had to write you can just make a systemd service or whatever you use. Debian's package already comes with an init.d script (not a systemd unit, but presumably it works with systemctl via sysv-generator).
Youden 2y ago
It's pretty straightforward. On the router (assuming a recent Debian-based distro): mkdir /etc/jool echo '{"instance":"nat64-minimal","framework":"netfilter","global":{"pool6":"64:ff9b::/96"}}' > /etc/jool/jool.conf apt install jool-dkms jool-tools On a box behind the NAT: curl --resolve one.one.one.one:443:64:ff9b::1.1.1.1 https://one.one.one.one If you want DNS64, 1.1.1.1 and 8.8.8.8 offer 2606:4700:4700::64 and 2001:4860:4860::6464 respectively or you can configure unbound pretty easily.
- detuur 2y ago
  > one.one.one.one:443:64:ff9b::1.1.1.1 Is this a typo or a weird curl-specific address format I've never heard of?
  - forbiddenlake 2y ago
    It's the argument to --resolve, not the desired URL. --resolve <[+]host:port:addr[,addr]...> Provide a custom address for a specific host and port pair. Using this, you can make the curl requests(s) use a specified address and prevent the otherwise normally resolved address to be used. Consider it a sort of /etc/hosts alternative provided on the command line.
    - detuur 2y ago
      I looked right past `--resolve`, so yes that now makes sense.
- yjftsjthsd-h 2y ago
  # apt search jool Sorting... Done Full Text Search... Done jool-dkms/stable 4.1.9-1 all kernel-based SIIT and NAT64 (IP/ICMP translation) jool-tools/stable 4.1.9-1 amd64 userspace utilities for the Jool kernel modules I suppose it is packaged, but dkms is still very much in the "why is does my router need a compiler installed" vibe.
accrual 2y ago
> And yes I'm tempted, but adding an OpenBSD router is a sharper learning curve... If you decide to try OpenBSD I hope you will enjoy it! I personally find it easier to understand and configure than Linux, but I could be biased.

Arnavion 2y ago

I haven't tried NAT64 on a Linux router, so I can't say authoritatively. I did a similar experiment as the submitted article back in 2020, though that was on a pfSense (FreeBSD) router, not Linux. I used tayga for NAT64 there, which was last released in 2010, but it probably still works on modern Linux. At the very least it's still packaged in Debian. Someone has made a NAT64 implementation using eBPF, though with quite some caveats: https://github.com/xdp-project/bpf-examples/tree/master/nat64-bpf https://github.com/xdp-project/bpf-examples/tree/master/nat6...

qhwudbebd 2y ago
The nat64/clat situation on Linux is not brilliant at the moment. There are userspace implementations like Tayga and Tundra. These incur kernel-userspace-kernel transition for each packet so are pretty inefficient and struggle unnecessarily on low-end hardware. Then there are out-of-tree modules of varying quality, none of those I've looked at being amazingly inspiring code-wise. As out-of-tree modules, they'd need to be rebuilt whenever you rebuild your kernel, but would inconveniently not be built as part of that kernel unless you patch them in. I'd not seen the eBPF implementation before. That's quite a nice idea. Quite tempted to have a hack at that to fix the minor issues the author identifies. (What's the story with building eBPF programs nowadays? Are there all kinds of crazy dependencies, or is the situation better than it used to be?)
yjftsjthsd-h 2y ago
So tayga was the tool that I came the closest to using last time I looked at this, but rereading http://www.litech.org/tayga/ http://www.litech.org/tayga/ I still don't really follow the configuration (yes I know it's a skill issue but nat44 wasn't this hard), the tun device is... I guess it should be fine, but I don't like needing it, and the whole thing looks very manual (I'd bet that doesn't persist after a reboot) though I guess I should see if someone's packaged up a nice systemd unit that makes it all work. The eBPF one is very interesting and does seem to work the way I expect NAT to work (no extra interfaces, just rewriting packets as they come and go), but is 1. unfinished by its own description, and 2. again a 3rd-party code drop that I'd have to package and ship myself if I wanted to use it. And I can do that, but I really don't like my routers to need fiddling.
- Arnavion 2y ago
  You can refer to https://www.arnavion.dev/blog/2020-04-18-i-switched-my-home-network-to-ipv6/#level-4-turn-off-ipv4-aka-how-to-run-tayga-on-pfsense https://www.arnavion.dev/blog/2020-04-18-i-switched-my-home-... which is about my pfSense attempt. It has the six-line tayga config and hopefully enough surrounding explanation to make it clear, and then instead of the rc script I had to write you can just make a systemd service or whatever you use. Debian's package already comes with an init.d script (not a systemd unit, but presumably it works with systemctl via sysv-generator).

Youden 2y ago

It's pretty straightforward. On the router (assuming a recent Debian-based distro): mkdir /etc/jool echo '{"instance":"nat64-minimal","framework":"netfilter","global":{"pool6":"64:ff9b::/96"}}' > /etc/jool/jool.conf apt install jool-dkms jool-tools On a box behind the NAT: curl --resolve one.one.one.one:443:64:ff9b::1.1.1.1 https://one.one.one.one If you want DNS64, 1.1.1.1 and 8.8.8.8 offer 2606:4700:4700::64 and 2001:4860:4860::6464 respectively or you can configure unbound pretty easily.

detuur 2y ago
> one.one.one.one:443:64:ff9b::1.1.1.1 Is this a typo or a weird curl-specific address format I've never heard of?
- forbiddenlake 2y ago
  It's the argument to --resolve, not the desired URL. --resolve <[+]host:port:addr[,addr]...> Provide a custom address for a specific host and port pair. Using this, you can make the curl requests(s) use a specified address and prevent the otherwise normally resolved address to be used. Consider it a sort of /etc/hosts alternative provided on the command line.
  - detuur 2y ago
    I looked right past `--resolve`, so yes that now makes sense.
yjftsjthsd-h 2y ago
# apt search jool Sorting... Done Full Text Search... Done jool-dkms/stable 4.1.9-1 all kernel-based SIIT and NAT64 (IP/ICMP translation) jool-tools/stable 4.1.9-1 amd64 userspace utilities for the Jool kernel modules I suppose it is packaged, but dkms is still very much in the "why is does my router need a compiler installed" vibe.

accrual 2y ago

> And yes I'm tempted, but adding an OpenBSD router is a sharper learning curve... If you decide to try OpenBSD I hope you will enjoy it! I personally find it easier to understand and configure than Linux, but I could be biased.