$ curl -4 https://acme-v02.api.letsencrypt.org/directory
curl: (28) Failed to connect to acme-v02.api.letsencrypt.org port 443: Connection timed out
$ curl -4 ifconfig.co
212.23.72.121
or google
$ traceroute google.com
traceroute to google.com (173.194.73.139), 30 hops max, 60 byte packets
1 _gateway (192.168.0.1) 0.295 ms 0.353 ms 0.198 ms
2 212.23.72.122 (212.23.72.122) 1.968 ms 2.019 ms 2.066 ms
3 10.254.8.1 (10.254.8.1) 2.076 ms 1.837 ms 2.140 ms
4 copyco.dial.sovam.com (194.67.13.77) 2.348 ms 194.67.44.169 (194.67.44.169) 1.814 ms copyco.dial.sovam.com (194.67.13.77) 2.253 ms
5 pe05.KK12.Moscow.gldn.net (79.104.225.15) 27.224 ms pe05.KK12.Moscow.gldn.net (79.104.225.13) 26.878 ms pe05.KK12.Moscow.gldn.net (79.104.225.15) 27.143 ms
6 be10.tf01-02.Moscow.gldn.net (81.211.45.63) 68.930 ms 67.768 ms 68.083 ms
7 pe03.KK12.Moscow.gldn.net (79.104.235.215) 27.757 ms pe03.KK12.Moscow.gldn.net (79.104.235.213) 27.352 ms pe03.KK12.Moscow.gldn.net (79.104.235.215) 27.407 ms
8 72.14.213.116 (72.14.213.116) 26.974 ms 26.936 ms 72.14.205.76 (72.14.205.76) 27.316 ms
9 108.170.250.34 (108.170.250.34) 27.839 ms * *
10 142.251.49.24 (142.251.49.24) 40.731 ms 172.253.69.174 (172.253.69.174) 27.832 ms 172.253.69.92 (172.253.69.92) 27.769 ms
11 108.170.250.34 (108.170.250.34) 28.414 ms 172.253.65.159 (172.253.65.159) 58.212 ms 74.125.253.94 (74.125.253.94) 38.801 ms
12 142.250.56.15 (142.250.56.15) 47.551 ms 216.239.51.32 (216.239.51.32) 41.815 ms 142.250.56.221 (142.250.56.221) 42.560 ms
13 216.239.48.224 (216.239.48.224) 47.746 ms * 142.251.237.146 (142.251.237.146) 42.103 ms
14 209.85.254.179 (209.85.254.179) 44.761 ms 142.250.56.13 (142.250.56.13) 41.612 ms 172.253.79.237 (172.253.79.237) 41.571 ms
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * lq-in-f139.1e100.net (173.194.73.139) 45.829 ms 45.747 ms```
This doesn't look like anything intentional on Let's Encrypt's part!
That address 172.65.32.248 is a Cloudflare CDN instance that is hosting the Let's Encrypt API. The fact that you can't get even one hop past your local gateway with a traceroute suggests a (somewhat severe) routing problem related to this, particularly because—as you can see in your traceroute to Google—a traceroute should normally pass through several routers in your ISP's own infrastructure before it even reaches the rest of the Internet. Neither Let's Encrypt nor Cloudflare would have any way to stop your traceroute from at least passing through your own ISP's routers, or its upstream ISPs' routers (even if either wanted to do so).
I suggest asking your ISP to help diagnose the connectivity problem with Cloudflare (if you're confident that your gateway device itself isn't dropping these packets for some reason). Alternatively, you could ask on the Cloudflare community forum for advice or ideas about the connectivity to Cloudflare, maybe one of
No; Not from the output shown.
That output indicates a routing problem within your control.
If you have control of the router, show us the route table it is using.
Yeah, we've seen a few times around these parts routers or firewalls that were misconfigured and somehow thought that 172.65. was a private IP, rather than the "normal" public IP that it is.
What exactly can I calculate?
I forgot to say that icmp packets pass through, unlike udp:
$ traceroute -I acme-v02.api.letsencrypt.org
traceroute to acme-v02.api.letsencrypt.org (172.65.32.248), 30 hops max, 60 byte packets
1 _gateway (192.168.0.1) 0.401 ms 0.402 ms 0.451 ms
2 212.23.72.122 (212.23.72.122) 3.012 ms 3.048 ms 3.053 ms
3 10.254.8.1 (10.254.8.1) 2.379 ms 2.366 ms 2.603 ms
4 copyco.dial.sovam.com (194.67.13.77) 2.473 ms 2.530 ms 2.521 ms
5 pe02.Ekaterinburg.gldn.net (79.104.240.165) 2.718 ms 2.809 ms 2.910 ms
6 213.221.36.103 (213.221.36.103) 2.726 ms 1.893 ms 2.253 ms
7 172.65.32.248 (172.65.32.248) 1.561 ms 1.381 ms 1.350 ms
traceroute -T -p 443 www.google.com
traceroute to www.google.com (64.233.163.147), 30 hops max, 60 byte packets
1 _gateway (192.168.0.1) 0.302 ms 0.376 ms 0.464 ms
2 212.23.72.122 (212.23.72.122) 4.118 ms 5.583 ms 5.627 ms
3 10.254.8.1 (10.254.8.1) 3.143 ms 3.359 ms 3.293 ms
4 copyco.dial.sovam.com (194.67.13.77) 3.414 ms 1.819 ms 194.67.44.169 (194.67.44.169) 1.746 ms
5 pe03.KK12.Moscow.gldn.net (79.104.235.215) 32.492 ms pe03.KK12.Moscow.gldn.net (79.104.235.213) 29.298 ms 29.135 ms
OK, my best guess it that it is NOT a routing issue.
But a very close cousin to that: It is a firewall policy issue.
Your local gateway OR (more likely) 212.23.72.122 is blocking HTTPS access to IP 172.65.32.248.
[OR likely blocking to the whole 172.0.0.0/8 network]
