Acme-v02.api.letsencrypt.org sends RST right after connecting

Help
41

This ended up being resolved on the client side by doing some routing changes. Similar to the other post, cloudflare.com was unreachable.

5 Likes
42

Cloudflare is unable to locate any problems on their end and don’t think the RSTs are coming from them. They think it may be a firewall or something, but I don’t have much more to go on.

5 Likes
43

Did you send then the Wireshark trace? How can the firewall send the RST? BTW, the request from the different IP, which went though the same firewall gets the proper response, while that one from this IP gets RST.

45

Just generate a TCP packet with the RST flag set? Not that hard to do. E.g.:

iptables -p tcp [...] -j REJECT --reject-with tcp-reset

Also, may I suggest you provide more meaningful words than "boolshit"? Thank you.

6 Likes
46

The word you mentioned refers to the @_az answer which suggests doing routing changes on client side without any further explanation.

47

You might want to consider politely pointing that out and request further details instead of making an insulting post.

5 Likes
48

My response was not intended as advice, it was to let Matthew know not to wait for further details from me. Thanks and good luck.

5 Likes
49

would ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com name be better name to ask? both version of them (ipv4 and ipv6 2606:4700:60:0:f53d:5624:85c7:3a2c is sending rst to me.
other ip addresses on 2606:4700:60.0::/44 (cf block)that doesn't have website behind returns same tcp reset back to us, while IPs that do have website behind is not, so I think some firewall on CF side didn't notified that thoses IP have something behind it and not drop it.

5 Likes
50

Can you provide me the output of https://www.cloudflare.com/cdn-cgi/trace along with a pcap showing the RST? I’m going to need more data to convince cloudflare to look into this further

5 Likes
51

I found now https://acme-v02.api.letsencrypt.org/cdn-cgi/trace (mark http"s") opens. just other port sent RST, but cdn-cgi/trace showing 404, not any actual trace on them.

on cloudflare.com/cdn-cgi/trace

fl=34f157
h=cloudflare.com
ip=59.5.131.245
ts=1667704617.379
visit_scheme=https
uag=Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:106.0) Gecko/20100101 Firefox/106.0
colo=ICN
sliver=none
http=http/2
loc=KR
tls=TLSv1.3
sni=plaintext
warp=off
gateway=off
kex=X25519

but it didn't go to same DC so it's no valid for LE endpoin, ping to cloudflare.com and acme-v02.api is too different to be same DC (3ms vs 35ms). KIX I guess.

anyway about data failed:
tcpdump80.pcap (13.5 KB)

5 Likes
52

Only https is supported by the acme-v02.api endpoint. All other ports will fail. (see post #17)

And, the /cdn-cgi/trace URI is only for Cloudflare domain. A 404 is expected when tried with acme-v02.api

6 Likes
53

guess I was knocking on a empty wall then :frowning: I expected it will redirected to https

6 Likes
54

Please show:
traceroute -4 -n -T -p 443 acme-v02.api.letsencrypt.org
traceroute -6 -n -T -p 443 acme-v02.api.letsencrypt.org

4 Likes
55

The problem is still here. Is there anyone who can help?

56

Cloudflare claims the problem is happening before your connection gets to them, so without additional pcaps from other affected users, we don't have much more we can do.

6 Likes
57

If that is true, it would mean our ISP is blocking it. Can we get pcap from CF side, so I can present it to our ISP?

58

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.