Cannot connect to Let's Encrypt using IPv6

Help
1

Hey there, I think I'm having a similar issue. I was going to renew my certs today but wacs was giving me an "operation timed out" error.

I did some looking around and found this thread, and found an issue I can't explain: I can ping the IPV4 address of acme-v02.api.letsencrypt.org, but not the IPV6 address.

Curl output (abridged):

curl -v https://acme-v02.api.letsencrypt.org
* Host acme-v02.api.letsencrypt.org:443 was resolved.
* IPv6: 2606:4700:60:0:f53d:5624:85c7:3a2c
* IPv4: 172.65.32.248
*   Trying [2606:4700:60:0:f53d:5624:85c7:3a2c]:443...
*   Trying 172.65.32.248:443...
* schannel: disabled automatic use of client certificate
* ALPN: curl offers http/1.1
* ALPN: server accepted http/1.1
* Connected to acme-v02.api.letsencrypt.org (172.65.32.248) port 443

Note that it attempted the IPV6 address, then moved on to the IPV4 address.

Pinging the IPV6 address:

ping 2606:4700:60:0:f53d:5624:85c7:3a2c

Pinging 2606:4700:60:0:f53d:5624:85c7:3a2c with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 2606:4700:60:0:f53d:5624:85c7:3a2c:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)

Versus pinging the IPV4 address:

ping 172.65.32.248

Pinging 172.65.32.248 with 32 bytes of data:
Reply from 172.65.32.248: bytes=32 time=15ms TTL=55
Reply from 172.65.32.248: bytes=32 time=15ms TTL=55
Reply from 172.65.32.248: bytes=32 time=20ms TTL=55
Reply from 172.65.32.248: bytes=32 time=15ms TTL=55

Ping statistics for 172.65.32.248:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)

So, I'm pretty much stumped and am guessing the problem is not on my end. Any advice? I'm not a network guy for the most part, but I do need to renew the certs...

2

I found a workaround, at least: I temporarily disabled IPV6 on my network adapter. On Windows 10, this is via Settings > Network and Internet > Change Adapter Options > Properties (Ethernet) > Uncheck IPV6.

Obviously this does not allow the ping to the IPV6 address to succeed, but it does allow wacs to connect and run.

Would still be interested in figuring out what the underlying issue is.

3

@willpowered I moved your posts to their own thread. We prefer each unique problem to be their own. The same symptom is often caused by different things and this allows us to more easily focus on your specific issue.

That said, it looks like your outbound IPv6 was not working correctly. I very much doubt this was unique to Let's Encrypt API servers. We don't generally help with comms setups but if you re-enable IPv6 what do these show?

curl -4 https://ifconfig.io
curl -6 https://ifconfig.io
curl -6 https://google.com

The first two should return your public IPv4 and v6 address. The last just helps you to better identify where the problem lies :slight_smile:

4

I might also suggest a more general site for debugging outgoing IPv6 connectivity, which might be helpful:

5

I moved your posts to their own thread. We prefer each unique problem to be their own.

Hey, no prob. First time here.

That said, it looks like your outbound IPv6 was not working correctly. I very much doubt this was unique to Let's Encrypt API servers. We don't generally help with comms setups but if you re-enable IPv6 what do these show?

I re-enabled IPV6 after finishing my cert renewal through wacs. The output appears normal, aside from an odd response from Google.

curl -4 https://ifconfig.io
73.62.147.118

curl -6 https://ifconfig.io
2601:447:c201:1020:8019:e130:f252:7724

curl -6 https://google.com
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://www.google.com/">here</A>.
</BODY></HTML>

Additionally, since re-enabling IPV6 on my network adapter, I can successfully ping the IPV6 address of acme-v02.api.letsencrypt.org. This is great of course, but kind of annoying because I'm still interested in what caused the problem.

While I was trying to figure it out initially, I checked Down For Everyone Or Just Me, which reported that acme-v02.api.letsencrypt.org was unreachable. That service is still unable to connect to it: https://downforeveryoneorjustme.com/acme-v02.api.letsencrypt.org?proto=https

I might also suggest a more general site for debugging outgoing IPv6 connectivity, which might be helpful: https://test-ipv6.com/

Thank you! I've bookmarked that in case I encounter the problem again.

6

Well, you don't have problems reaching it now nor have I. Nor have we seen other reports indicating a failure with those servers. Let's Encrypt issues millions of certs each day. Problems at the LE side are very rare and (usually) quite obvious :slight_smile:

LE has monitoring which alerts them to system wide trouble. These are reported here: https://letsencrypt.status.io/

From time to time there are network "backbone" problems that can affect a group of people. But, we don't see evidence of that yet either. Comms problems are possibly the most common problem reported here and the vast majority are on the requesting side.

If you get another problem with IPv6 try those other commands I suggested to determine whether it is unique to one destination.

7

Problems at the LE side are very rare and (usually) quite obvious

This is what I would also assume! Thank you for your help on this oddity and for the resources- I'm hoping it's smooth sailing from here. I've marked your most recent response as the solution.

If you get another problem with IPv6 try those other commands I suggested to determine whether it is unique to one destination.

This is a good idea- It's true that I only checked the Let's Encrypt IPV6 and no other IPV6 addresses. If they also failed to connect then that would have indeed indicated the problem was on my end. What a weird problem to have, though- I've never heard of being able to connect via IPV4 but not IPV6.

8

That's happened to me a couple times this year from my home network :slight_smile:

Only my PC notices that because I connect to an IPv6-only server for some things so I notice right away. All other devices happily connect to their services with IPv4 when that happened.

I think I needed to reboot my router each time but one time may have only needed a Windows reboot - not sure. My current router has been a lot more stable than my old one which regularly got "stuck" for all traffic. The new router has never lost IPv4. In a job I had long ago I worked in comms. Weird stuff of one kind or another is pretty common :slight_smile: