# "Timeout during connect" on renewal
**URL:** https://community.letsencrypt.org/t/timeout-during-connect-on-renewal/174261
**Category:** Help
**Created:** [March 22, 2022, 2:05am UTC](https://community.letsencrypt.org/t/timeout-during-connect-on-renewal/174261 "2022-03-22T02:05:04Z")
**Posts on this page:** 15
**Page:** 1
### Author:  [@anarcat](https://community.letsencrypt.org/u/anarcat)
#### Post date: [March 22, 2022, 2:05am UTC](https://community.letsencrypt.org/t/timeout-during-connect-on-renewal/174261/1 "2022-03-22T02:05:05Z")
My domain is: mirror.anarc.at
I ran this command: `certbot renew`
It produced this output:
```nohighlight
- The following errors were reported by the server:
Domain: mirror.anarc.at
Type: connection
Detail: Fetching
http://mirror.anarc.at/.well-known/acme-challenge/5_CpOCx38guwL_I9Gd1x5VaNopxi_rCUwobYJehbsFg:
Timeout during connect (likely firewall problem)
```
I have also tried:
```nohighlight
root@marcos:/etc# certbot certonly -d mirror.anarc.at --webroot -w /var/www/mirror/
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Cert is due for renewal, auto-renewing...
Renewing an existing certificate for mirror.anarc.at
Performing the following challenges:
http-01 challenge for mirror.anarc.at
Using the webroot path /var/www/mirror for all unmatched domains.
Waiting for verification...
Challenge failed for domain mirror.anarc.at
http-01 challenge for mirror.anarc.at
Cleaning up challenges
Some challenges have failed.
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: mirror.anarc.at
Type: connection
Detail: Fetching
http://mirror.anarc.at/.well-known/acme-challenge/B1k-K3ozfrJ5hQx7d5lLhLzUD3C8w1jNxrnRGZIxSLY:
Timeout during connect (likely firewall problem)
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you're using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
```
And I can reproduce the issue on [Let's Debug](https://letsdebug.net/mirror.anarc.at/959020) (although debugging shows the webserver _is_ reachable, see [Let's Debug](https://letsdebug.net/mirror.anarc.at/959020?debug=y)), but nowhere else: I have tried from [people.debian.org](http://people.debian.org) and other machines and they can all reach my server correctly. I am not firewalling port 80 or 443, although I am redirecting the former to the latter, which never caused problems in the past.
My web server is (include version): 2.4.52-1~deb11u2
The operating system my web server runs on is (include version): Debian 11 "bullseye"
My hosting provider, if applicable, is: N/A
I can login to a root shell on my machine (yes or no, or I don't know): yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no
The version of my client is (e.g. output of `certbot --version` or `certbot-auto --version` if you're using Certbot): 1.12.0
* * *
I should also point out that I've been tracking my `/etc` directory in git for a while, with daily autocommit. Since around November, I started noticing an accumulation of CSRs in `/etc/letsencrypt/csr`, where I now have a whopping 1638 entries. Typically, I'd get new CSRs added there when new certificates are renewed, but because renewals have started breaking at some point in the past, I'm now adding dozens of CSRs a day in there. It seems that, around March 3rd, the Let's Encrypt servers have started having trouble reaching my server and I cannot clearly explain why this is happening anymore.
I've been using Let's Encrypt since at least 2017, and this is the first time I need to ask for help around a problem like this. Typically, the configuration issues are on my end: some expired DNS entry or misconfigured virtual host. But this is different: nothing changed on my end, and things seem to be working from other point of views on the network. I also tried to check the challenge by using `--debug-challenges` and `curl`ing the URL to see if the challenge is really available, and it is (with `curl -L`).
Is there something obvious I'm missing here? I looked at other issues like [HTTP challenge fails: Timeout during connect, DNS problem - #5 by JuergenAuer](https://community.letsencrypt.org/t/http-challenge-fails-timeout-during-connect-dns-problem/103139/5) and I don't seem to find anything that matches my experience there.
Thanks for any input.
---
### Author:  [@schoen](https://community.letsencrypt.org/u/schoen)
#### Post date: [March 22, 2022, 2:38am UTC](https://community.letsencrypt.org/t/timeout-during-connect-on-renewal/174261/2 "2022-03-22T02:38:34Z")
Hi @anarcat,
Is it possible that your hosting provider or ISP is blocking certain address ranges?
It does seem that most parts of the Internet can reach your server, but the Let's Encrypt validation consistently can't, which might suggest a hidden firewall rule or something.
---
### Author:  [@anarcat](https://community.letsencrypt.org/u/anarcat)
#### Post date: [March 22, 2022, 5:08pm UTC](https://community.letsencrypt.org/t/timeout-during-connect-on-renewal/174261/3 "2022-03-22T17:08:50Z")
Hi @schoen!
> [@schoen](#):
>
> Is it possible that your hosting provider or ISP is blocking certain address ranges?
It's possible, I guess i'll escalate with them now, but this is highly unusual: typically they don't block anything like this. I'll ask.
Could someone at LE get me a traceroute to see where the traffic gets drop? Is there a looking glass or something?
Also: I guess that a DNS-01 challenge could workaround such a problem, no?
---
### Author:  [@schoen](https://community.letsencrypt.org/u/schoen)
#### Post date: [March 22, 2022, 5:24pm UTC](https://community.letsencrypt.org/t/timeout-during-connect-on-renewal/174261/4 "2022-03-22T17:24:07Z")
> [@anarcat](#):
>
> Could someone at LE get me a traceroute to see where the traffic gets drop?
It's rare, you would usually have to attract the attention of a busy LE staffer. đ The LE staffer might first ask you to check with your ISP, as you're trying.
> [@](#):
>
> Is there a looking glass or something?
That could be _very_ useful in some cases, but it doesn't exist now and I don't know if there would be concerns about attack surface or resources in hosting it on the same infrastructure as the actual validation.
> [@anarcat](#):
>
> Also: I guess that a DNS-01 challenge could workaround such a problem, no?
Yes, it's pretty rare for DNS servers to refuse queries from anywhere.
---
### Author:  [@anarcat](https://community.letsencrypt.org/u/anarcat)
#### Post date: [March 22, 2022, 6:43pm UTC](https://community.letsencrypt.org/t/timeout-during-connect-on-renewal/174261/5 "2022-03-22T18:43:57Z")
> [@anarcat](#):
>
> It's possible, I guess i'll escalate with them now, but this is highly unusual: typically they don't block anything like this. I'll ask.
Oh dear, my ISP seems to have fallen down the trap of "our call is important to us" and redirect me to a "community support forum", where I posted this link:
[https://community.teksavvy.com/discussion/1498/timeouts-connecting-inbound-from-lets-encrypt/p1?new=1](https://community.teksavvy.com/discussion/1498/timeouts-connecting-inbound-from-lets-encrypt/p1?new=1)
What a nightmare... I suspect this will get about zero traction and will start looking at alternatives (ISP, and DNS-01 of course).
---
### Author:  [@anarcat](https://community.letsencrypt.org/u/anarcat)
#### Post date: [March 22, 2022, 7:09pm UTC](https://community.letsencrypt.org/t/timeout-during-connect-on-renewal/174261/6 "2022-03-22T19:09:49Z")
i actually got on the phone (remember those?) with them and they claim to not be blocking any port or any traffic on their side, so this would be some bizarre routing issue of some sort, which brings me back to needing some sort of traceroute from Let's encrypt to diagnose this further. Sigh.
---
### Author:  [@\_az](https://community.letsencrypt.org/u/_az)
#### Post date: [March 22, 2022, 7:17pm UTC](https://community.letsencrypt.org/t/timeout-during-connect-on-renewal/174261/7 "2022-03-22T19:17:08Z")
When I looked yesterday, Let's Encrypt was able to connect to other hosts in your /24 (e.g. to 206.248.172.208).
Based on that, it does seem most likely to me that you have some firewall rule on your machine which is causing this:
- Although your ISP could be blocking port 80 for your specific IP, I don't know why they would single you out. Unless there is some plan-based differentiation?
- Asking for a traceroute from Let's Encrypt probably won't be too helpful because AFAIU routing tables do not have anything smaller than /24.
Is this Debian server behind a NAT, or plugged directly in to your internet connection? Have you tried rebooting your router/modem, if any?
---
### Author:  [@anarcat](https://community.letsencrypt.org/u/anarcat)
#### Post date: [March 22, 2022, 9:37pm UTC](https://community.letsencrypt.org/t/timeout-during-connect-on-renewal/174261/8 "2022-03-22T21:37:33Z")
> [@\_az](#):
>
> Is this Debian server behind a NAT, or plugged directly in to your internet connection? Have you tried rebooting your router/modem, if any?
It's behind NAT with port forwarding for that host, and I must admit I haven't tried rebooting the router, this is the nex step.
---
### Author:  [@anarcat](https://community.letsencrypt.org/u/anarcat)
#### Post date: [March 22, 2022, 11:07pm UTC](https://community.letsencrypt.org/t/timeout-during-connect-on-renewal/174261/9 "2022-03-22T23:07:34Z")
well this is embarrasing, rebooting the router actually fixed this issue.
my hunch was this was IPv6 related, and I think it was spot on in the end. this IPv6 setup has a tendency of falling apart upstream after a while. reconnecting the IPv6 interface (or rebooting) typically fixes it, so my guess is that Let's Encrypt was trying to connect over IPv6 and failing to fallback.
is that a known issue? nothing confirmed on my end of course, just a hunch. in fact, i still can't quite reliably renew the domains... some did go through, but some still get timeouts...
sorry for the noise, and thanks for the stellar support.
---
### Author:  [@\_az](https://community.letsencrypt.org/u/_az)
#### Post date: [March 22, 2022, 11:42pm UTC](https://community.letsencrypt.org/t/timeout-during-connect-on-renewal/174261/10 "2022-03-22T23:42:48Z")
> [@anarcat](#):
>
> rebooting the router actually fixed this issue.
Hooray for shoddy CPE!
> [@anarcat](#):
>
> so my guess is that Let's Encrypt was trying to connect over IPv6 and failing to fallback.
I don't think IPv6 was involved here. If we look at the authorization details ([https://acme-staging-v02.api.letsencrypt.org/get/authz-v3/1982674078](https://acme-staging-v02.api.letsencrypt.org/get/authz-v3/1982674078)), we can see that Let's Encrypt only resolved an IPv4 address for your domain, and failed to connect on that address.
> [@anarcat](#):
>
> some did go through, but some still get timeouts...
We've also previously seen "helpful" router features which throttle traffic as a sort of anti-DoS feature. Let's Encrypt challenge requests tend to arrive all at once, which can trigger a blocking response.
---
### Author:  [@anarcat](https://community.letsencrypt.org/u/anarcat)
#### Post date: [March 23, 2022, 1:07am UTC](https://community.letsencrypt.org/t/timeout-during-connect-on-renewal/174261/11 "2022-03-23T01:07:51Z")
> [@\_az](#):
>
> Hooray for shoddy CPE!
The thing is: that's not supposed to be some shoddy random SOHO router. This is the [turris omnia](https://www.turris.com/en/omnia/overview/), with a real Linux (OpenWRT) under it. It should be able to handle, you know, port forwarding. đ
> [@\_az](#):
>
> I don't think IPv6 was involved here. If we look at the authorization details ([https://acme-staging-v02.api.letsencrypt.org/get/authz-v3/1982674078](https://acme-staging-v02.api.letsencrypt.org/get/authz-v3/1982674078)), we can see that Let's Encrypt only resolved an IPv4 address for your domain, and failed to connect on that address.
That is really, truly bizarre then. I really don't understand what the heck happened here...
If this was a situation where the site was just down, I'd get it, but the traffic was blanking out only for let's encrypt! I didn't find another site that had those timeout issues. And even now that _most_ (but not all!) of my certs have renewed, there's still one more left that's stumbling upon itself:
```nohighlight
Domain: analytics.anarc.at
Type: connection
Detail: During secondary validation: Fetching
http://analytics.anarc.at/.well-known/acme-challenge/VXVDzedJ_MTPxKKaA8K-c7u8coBdlIOkItkROTqLeXE:
Timeout during connect (likely firewall problem)
```
Notice how it's failing in the secondary validation now. Also note that _all_ those DNS records are basically CNAMEs to the same host right now, so if they were able to route for some, it should route for all, no?
> [@\_az](#):
>
> We've also previously seen "helpful" router features which throttle traffic as a sort of anti-DoS feature. Let's Encrypt challenge requests tend to arrive all at once, which can trigger a blocking response.
That could actually be something the Turris does. And lo and behold, there's this "[Dynamic firewall](https://docs.turris.cz/basics/sentinel/dynfw/)" thing that I seem to have naively enabled in there. Disabling it seems to make that final cert just go through fine.
Sigh, thanks, and sorry again for the noise, I feel quite silly.
---
### Author:  [@\_az](https://community.letsencrypt.org/u/_az)
#### Post date: [March 23, 2022, 1:58am UTC](https://community.letsencrypt.org/t/timeout-during-connect-on-renewal/174261/12 "2022-03-23T01:58:47Z")
> [@anarcat](#):
>
> And lo and behold, there's this "[Dynamic firewall](https://docs.turris.cz/basics/sentinel/dynfw/)" thing that I seem to have naively enabled in there
Interesting! One of the Let's Encrypt validation servers is listed on today's Turris greylist as an "http" attacker.
---
### Author:  [@anarcat](https://community.letsencrypt.org/u/anarcat)
#### Post date: [March 23, 2022, 3:08am UTC](https://community.letsencrypt.org/t/timeout-during-connect-on-renewal/174261/13 "2022-03-23T03:08:32Z")
oh wow, that sounds like something we (who?) should fix.
---
### Author:  [@anarcat](https://community.letsencrypt.org/u/anarcat)
#### Post date: [March 23, 2022, 6:01pm UTC](https://community.letsencrypt.org/t/timeout-during-connect-on-renewal/174261/14 "2022-03-23T18:01:42Z")
I reported the problem upstream here:
> **[Dynamic firewall blocks Let's Encrypt renewals](https://forum.turris.cz/t/dynamic-firewall-blocks-lets-encrypt-renewals/16876)**
>
> It seems Turrisâ âdynamic firewallâ tends to block letâs encrypt servers altogether. This was previously reported here: and here: ⌠neither of which were solved in any satisfactory way. The first answer just showed how to list the blocked IPs...
---
### Author:  [@system](https://community.letsencrypt.org/u/system)
#### Post date: [April 22, 2022, 6:02pm UTC](https://community.letsencrypt.org/t/timeout-during-connect-on-renewal/174261/15 "2022-04-22T18:02:32Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.