I’m working for an hosting provider and we noticed that out class 188.8.131.52/24 can’t connect to letsencrypt server (acme-v01.api.letsencrypt.org 184.108.40.206).
We already checked with our connectivity provider and they confirm that the packets are dropped letsencrypt side (an hop before acme-v01.api.letsencrypt.org).
We are also quite sure doesn’t done anything to deserve a block.
Asked on IRC and they suggested to open a post here to check it with Akamai’s CDN.
Full traceroute https://pastebin.com/YWqXxmUX
Thanks for support
Thanks, I’ve flagged our operations team to investigate & respond on-thread.
If you need more test/traceroute/etc please ask.
Using a diagnostic tools provided by our CDN I was able to attempt an MTR from the Akamai edge 220.127.116.11 to an ip in your /24. It was unsuccessful and failed a few hops after it started. I have opened a ticket with the CDN to confirm the results and look for a solution. I will reply here if there are any questions from their networking team.
First, I’d like to confirm that since your /24 cannot make it to the letsencrypt server, you have not seen any reference errors returned at acme-v01.api.letsencrypt.org. I’d also like you to test some more of your /24 to confirm the scope of this connectivity issue.
Next, I would like you to run
curl -I https://acme-v01.api.letsencrypt.org -H "Pragma: akamai-x-cache-on, akamai-x-get-cache-key, akamai-x-get-true-cache-key, akamai-x-get-request-id" from a few vantage points and provide the result here.
Once I have that information I can coordinate furhter with our CDN on a resolution.
tried from some ip and the issue looks jeopardized.
Also tried from some server in other IP classes and found a couple of blocked IPs
In the pastebin you can find:
- 2 test on 18.104.22.168/24, one failed, one ok
- 2 failed test on IPs from another classes
Thanks for providing more results and running those commands. Our CDN has has confirmed that the failed requests were not blocked by Akamai and in fact never reached Akamai.
those failed requests had a ping result of acme-v01.api.letsencrypt.org resolving to an Akamai IP 22.214.171.124. However, the curl results indicated failure to reach 2a02:26f0:ad:289::3d5
This looks to be a problem with your network provider and I suggest consulting with them to get it resolved.
Also, a general network debugging tip I suggest is to check your ipv6 configuration. It’s interesting that your ping resolved to an ipv4 address but your curl attempted to connect over ipv6.
our Network Carrier send to us these 2 traceroutes
the Hops are the same, but when they “customize” the source with 126.96.36.199 they are unable to arrive to 188.8.131.52
For my Network Carrier seems that our IPs are filtred by you (or your CDN ) and we do not have any evidence to prove the opposite, so i must assume that it is true.
Now, what can we do to solve this issue? Can you double check your system and with CDN for any block? Any other idea?
Thanks for support
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.