Timeout during connect (likely firewall problem) after changing internet provider

Don't forget the home router. Although NAT is not applicable, most home router devices have a restrictive IPv6 firewall for incoming connections.

3 Likes

Well, as I edited, most home ISPs don't even bother offering ipv6 connectivity where I am.

3 Likes

Luckily, ISPs in The Netherlands do :wink:

5 Likes

(Yeah, I have an actual glass strand in the house that brings me a 2500down 500up mbps link, and no ipv6. Italy.)

4 Likes

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.

3 Likes

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.

5 Likes

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].

2 Likes

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.

2 Likes

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]

2 Likes

It should check all of them. Don't forget you can have multiple A records and multiple AAAA records.

2 Likes

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]

2 Likes

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.

2 Likes

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.

2 Likes

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.

3 Likes

Because HTTP did not fail, it redirected to HTTPS.
Thus, HTTP is now off the table.
And we begin again with HTTPS (IPv6 first).

2 Likes

Nevermind.

2 Likes

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.

6 Likes

Ah, I see, that explains it. Thanks.

3 Likes

2 posts were split to a new topic: Timeout during connect problem

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.