I don’t know what else to check. Setup is nginx/Debian 9. I have both A and AAAA records for my domain (tor.enallt.unam.mx), I’m seeing what I suppose is Let’s Encrypt reaching my server, but the connection is very weird:
10:06:50.067043 IP 18.104.22.168.60630 > 22.214.171.124.80: Flags [S]
10:06:50.067285 IP 126.96.36.199.80 > 188.8.131.52.60630: Flags [S.]
10:06:50.116606 IP 184.108.40.206.60630 > 220.127.116.11.80: Flags [.]
10:06:50.116711 IP 18.104.22.168.60630 > 22.214.171.124.80: Flags [F.]
10:06:50.117349 IP 126.96.36.199.80 > 188.8.131.52.60630: Flags [F.]
10:06:50.166579 IP 184.108.40.206.60630 > 220.127.116.11.80: Flags [.]
So the standard three way handshake, and then… Let’s Encrypt sends a FIN/ACK? Not one HTTP request in there. It’s not the firewall, otherwise there wouldn’t be responses from my server. And it’s not nginx, I don’t think, because there’s not even a GET/POST in there anywhere.
It’s like LE is giving up before even requesting the challenge. Can anyone give me any insight on this? I have multiple certs with LE, in this and other networks, FWIW.
From our side I'm seeing the error as: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
I've seen this issue once in the past when something between the Let's Encrypt validation authority and the remote server is doing a bad 6to4 translation. That specific error message indicates to me that the VA did make a request but that no response was received.
FWIW I'm also unable to reach the host on the IPv6 address that the VA resolved and observe a timeout with curl (testing from a random IPv6 box I have laying around):
curl: (7) Failed to connect to 2001:1218:4000:20:1000:600:0:1 port 80: No route to host