NAT64 Support

[LazerGrieves]

Hello,

I've just discovered fck-nat and I am thrilled that something like this exists because those AWS Managed NAT Gateways are pricey (especially with a Multi-AZ implementation).

However, I am wondering if there are any plans to implement support for NAT64 in fck-nat? I've been experimenting with IPv6-only private subnets ever since AWS announced that there will be charges for Public IPv4 addresses starting in 2024 and NAT64 seems like a requirement.

Thank you.

[apparentorder]

I asked the same thing last week and got this reply.

I have a proof of concept NAT64 Linux box running on AWS, and it works as expected (thankfully, AWS VPC supports DNS64 out of the box and for free!). I hope to take a look at integrating this with fck-nat over the next 1-2 weeks.

[AndrewGuenther]

@LazerGrieves @apparentorder I just want to make sure you're aware of Egress Only Internet Gateways which provide NAT64 in VPCs for free. If you're already aware of that feature, is there a reason it doesn't work for your use case?

[apparentorder]

I'm still pre-first-coffee right now, but I'm pretty sure that EO-IGW does not provide NAT64; the link above does not contradict that, and the DNS64/NAT64 docs support that (the NAT64 route 64::ff9b::/96 is supposed to point to a NAT Gateway). NAT64 is a feature of Managed NAT Gateway. Do you have additional resources, or have you tried yourself?

[RaJiska]

Unless I am mistaken, one of the core features of NAT64 is allowing communication from IPv6 (our instance), to IPv4 (remote server). Egress-Only IGW seem to be able to communicate only from IPv6 to IPv6 addresses, hence requiring NAT64 to offer translation when one wishes to have an IPv6 <> IPv4 communication.

[AndrewGuenther]

Ah, yep, you're both correct. Had it in my head that EO-IGWs did NAT64 but I was mistaken. @apparentorder was pre-first-coffee and I was post-time-for-bed

[RaJiska]

@LazerGrieves @apparentorder I fully implemented this feature into fck-nat, this really wasn't a piece of cake. I implemented this using Tayga which comes with it's lot of constraints (therefore probably not expected to be a on-by-default feature) that I will elaborate on in the PR.

Have been able to make this work with both IPs as well as domain names, even for those not supporting AAAA fields, leveraging AWS' integrated DNS. To note, AWS DNS64 is very slow for some reason with requests taking up to 3 seconds.

I will make a PR for this feature either sometime today or tomorrow.

[apparentorder]

Very cool! My proof of concept was with Jool, which is a kernel module, hence more performant – and it seems to be "more maintained" than tayga. But I really wasn't sure how to best combine building a kmod from source with fck-nat's current packer infrastructure, so I'm really glad that you went ahead :-)

Regarding this:

AWS DNS64 is very slow for some reason with requests taking up to 3 seconds

I have seen EC2 IPv6-only VMs that were deployed with a broken resolver config. The resolv.conf actually had an IPv4 resolver listed first. I have observed the same DNS lookup delay and assumed it's because the VM tries to query the IPv4 resolver first, and only proceeds to query the IPv6 resolver address after a 3s timeout. I didn't dig into the issue, so I cannot say if this theory is correct, and if it only affects AL2023, or "all" AWS-provided AMIs. But the DNS64 support in itself was not slow for me. It worked great once I removed the IPv4 resolver.

[RaJiska]

Thanks @apparentorder for sharing! Jool is indeed a much better alternative than TAYGA. In addition to not having the various constraints TAYGA is riddled with, it also runs as a kernel module which indeed is more yields better results.

As for the slow DNS issue you are right as well, the resolv.conf had the IPv4 resolver listed first which caused the issue in the first place. Removing it entirely fixed the problem. This issue is therefore also happening on AL2 and is probably worth looking into further.