curl -v https://acme-v02.api.letsencrypt.org/
* Trying 172.65.32.248:443...
* Trying 2606:4700:60:0:f53d:5624:85c7:3a2c:443...
* Immediate connect fail for 2606:4700:60:0:f53d:5624:85c7:3a2c: Network is unreachable
* connect to 172.65.32.248 port 443 failed: Connection timed out
* Failed to connect to acme-v02.api.letsencrypt.org port 443 after 130912 ms: Connection timed out
* Closing connection 0
curl: (28) Failed to connect to acme-v02.api.letsencrypt.org port 443 after 130912 ms: Connection timed out
My web server is (include version): Nginx 1.18.0 ubuntu
The operating system my web server runs on is (include version): Ubuntu 22.04 LTS
I can login to a root shell on my machine (yes or no, or I don't know):
yes
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
certbot 1.29.0
Here's my iptables firewall settings:
Chain INPUT (policy DROP 810 packets, 47175 bytes)
pkts bytes target prot opt in out source destination
147K 270M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
12 704 ACCEPT tcp -- * * $$$$$$$$$/24 0.0.0.0/0 tcp dpt:22 state NEW,ESTABLISHED
1199 77855 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * * 0.0.0.0/0 172.16.0.0/12
317 16222 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 state NEW
150 9000 ACCEPT tcp -- * * $$$$$$$$$/24 0.0.0.0/0 tcp dpt:443 state NEW
Chain OUTPUT (policy DROP 4325 packets, 296K bytes)
pkts bytes target prot opt in out source destination
6100 862K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:22 state ESTABLISHED
44383 133M ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
87423 137M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
615 36860 ACCEPT all -- * * 172.16.0.0/12 0.0.0.0/0
334 24443 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
I can connect to it with Chrome https://nevermind.com/ and I can ping it; I am on IPv4 only.
$ ping nevermind.com
PING nevermind.com (45.55.233.218): 56 data bytes
64 bytes from 45.55.233.218: icmp_seq=0 ttl=38 time=84.227 ms
64 bytes from 45.55.233.218: icmp_seq=1 ttl=38 time=84.907 ms
64 bytes from 45.55.233.218: icmp_seq=2 ttl=38 time=84.128 ms
64 bytes from 45.55.233.218: icmp_seq=3 ttl=38 time=83.924 ms
Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is:
I ran this command:
It produced this output:
My web server is (include version):
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don't know):
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
Possible cause of this time out is the incorrect routing of a too wide IP address space in the 172.0.0.0/8 block. The private IP address space related to the 172 prefix is 172.16.0.0/12, but often people don't set up the /12 correctly, but a wider address space, such as the entire 172.0.0.0/8 range. This would mess up connections to public IP addresses outside the 172.16.0.0/12 range, but inside the 172.0.0.0/8 range.
Please double check your routing for the 172.0.0.0/8 address space and make sure you have the subnet mask correctly set if you're using 172.16.0.0/12 as private address space.
I would have tough INPUTs bein DROPped and allowing OUTPUT, but I do not always see things and think the same as others. Let's see what good advice you get from the rest of the community.
thanks, buddy, my INPUT default police is set to DROP with allowed http, ssh e.t.c and it is working great, since i've changed OUTPUT default policy to ACCEPT it is started to reissue the certificates, that's great, but the task i have wants from me to have OUTPUT chain be DROPped by default. So there's gotta be a rule to allow connection to letsencrypt....