Don't forget the home router. Although NAT is not applicable, most home router devices have a restrictive IPv6 firewall for incoming connections.
Well, as I edited, most home ISPs don't even bother offering ipv6 connectivity where I am.
Luckily, ISPs in The Netherlands do
(Yeah, I have an actual glass strand in the house that brings me a 2500down 500up mbps link, and no ipv6. Italy.)
You're right. I had the home router IPv6 address in AAAA record. Now changed it to the webserver's IPv6 address. And there are no external ports opened for IPv6 on my home router either. Not sure yet on how to configure that.
The web server is running multiple virtual hosts on different port numbers. For IPv4, in the home router, there are port forwardings for 80 and 443 to the virtual host actual port numbers. Not sure if I can achieve something similar for IPv6.
It is all getting pretty complicated. I'm considering removing the AAAA record completely and only allow IPv4 traffic to the web server.
That's always an option if IPv6 won't work. The average visitor of your site probably has IPv4 connectivity. Not many users are IPv6 only, although I believe it's increasing in Asia.
I come to your house, knock on your door, you answer, I ask for some information, you send me away to another address - which is merely another door to your house (instead of just giving me the answer).
Then I get to that other door, knock and either no one answers or they don't have an answer for me.
Do you see the missed opportunity now?
If HTTP via IPv6 fails, LE will try HTTP via IPv4.
When HTTP via IPv4 redirects to HTTPS, it starts over.
If HTTPS via IPv6 connects, then it better have the answer [but it doesn't = FAIL].
Why should Boulder only retry using IPv4 when the protocol is HTTP? One should think the rules of retrying are the same for HTTP as for HTTPS.
Huh?
We seem to agree that it starts over with IPv6 as preferred.
[maybe my little "s" confused you - changed it to a big "S" - Who doesn't like a big "S" ? LOL]
It should check all of them. Don't forget you can have multiple A records and multiple AAAA records.
But it doesn't.
It is NOT a whichever one completes makes a WIN!
It's IPv6 first.
If that is unable to complete (no decision), then try IPv4.
[if the IPv6 decision was a fail, then everything stops]
I don't know.
It makes 4 connections, I would imagine it makes them to different IPs if it can, and any difference between them is a failure.
You say that the validation fails when the HTTPS connection is tried using IPV6 without retrying using IPv4, while you also state that when HTTP fails over IPv6, it does retry using IPv4. Why retrying over IPV4 with the HTTP protocol, but don't retry using IPV4 with the HTTPS protocol? That's just weird.
What is the difference between unable to complete and fail?
I just set firewall to block all inbound IPv6 traffic and a certbot --dry-run
failed with timeout even though IPv4 remained fine. Interesting, if the --dry-run started but was still hung / waiting for timeout and I re-opened IPv6, the --dry-run would complete.
Because HTTP did not fail, it redirected to HTTPS.
Thus, HTTP is now off the table.
And we begin again with HTTPS (IPv6 first).
Nevermind.
Well, the documentation says it's "To keep our CA software simple":
To keep our CA software simple we only perform an IPv6 to IPv4 retry on the first request when validating “http-01” challenges. If you use redirects, the redirects will not get retry treatment.
Ah, I see, that explains it. Thanks.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.