Closed anna-is-cute closed 4 years ago
I've seen this intermittently on other cloud providers as well.
@davidemyers up to you how you want to do it, but I spent a lot of time figuring out the peculiarities of ipv6 on DO the past couple days. Maybe consider adding some of this comment should be added to troubleshooting, this area isn't my specialty but I'm certain people hit the issue. Commenting here because the first part is pertinent to this specific issue.
alternative_ingress_ip set to false leaves (for me) a broken ipv6 setup on DO. I have to switch the v6 rule from -j SNAT --to whatever to -j MASQUERADE to get working network through the server's ipv6. If this is set to true, things work as they should.
The resolution seems therefore to always use a MASQUERADE instead of SNAT even though (like NAT66) this is discouraged if the provider doesn't support this option or users on DO set/leave it to false. It would eliminate issues with providers that only give a single ipv6 address to their VPS's.
As for updating the troubleshooting page. I noticed under all circumstances my clients hard prefer ipv4 even when dual-stack ipv6 is working. There's a workaround for linux using glibc, but basically systems are hardcoded to realize a NAT66 setup usually means someone screwed up the network. This article had the best information I've seen on the issue: https://blog.apnic.net/2018/02/02/nat66-good-bad-ugly/
Algo used to use MASQUERADE
for IPv6 before the alternative_ingress_ip
feature was added. Jack has tagged this issue as a bug and I imagine he'll fix it by going back to using MASQUERADE
when alternative_ingress_ip: false
.
Describe the bug
When deploying algo to an existing Ubuntu 19.10 or 18.04 LTS fresh install on Linode,
/etc/iptables/rules.v6
ends up containing this snippet:Notice how the egress IP is missing after
--to
. The box has working IPv6 connectivity.To Reproduce
Steps to reproduce the behavior:
Expected behavior
Successful deploy with
/etc/iptables/rules.v6
containing an egress IP for--to
.Full log