New user but my IP (actually whole block) seems blocked?

I can’t even connect to you from any IP in my range. No error just can’t connect at all. I’m also unable to do a traceroute or ping to you, fails one hop before.

tracert acme-v02.api.letsencrypt.org

Tracing route to ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com [172.65.32.248]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.100.1
2 1 ms 1 ms 1 ms 199.182.184.2
3 2 ms 9 ms 1 ms 208.103.116.105
4 1 ms 2 ms 1 ms 64.58.254.49
5 8 ms 5 ms 1 ms 64.58.254.226
6 1 ms 1 ms 2 ms te0-0-1-0.207.nr11.b016104-1.pit02.atlas.cogentco.com [38.104.120.229]
7 1 ms 1 ms 1 ms te0-7-0-4.rcr21.pit02.atlas.cogentco.com [154.24.22.113]
8 5 ms 4 ms 5 ms be2821.ccr21.cle04.atlas.cogentco.com [154.54.83.117]
9 12 ms 12 ms 11 ms be2993.ccr31.yyz02.atlas.cogentco.com [154.54.31.226]
10 17 ms 18 ms 17 ms 38.88.240.186
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
23 * * * Request timed out.
24 * * * Request timed out.
25 * * * Request timed out.
26 * * * Request timed out.
27 * * * Request timed out.
28 * * * Request timed out.
29 * * * Request timed out.
30 * * * Request timed out.

Trace complete.

Also this shows it as down too, so not sure if this is a more widespread issue?

Hi @ravanallc

that’s not a blocked ip address.

May be reduce your MTU - 1500 -> 1300 or 1100.

Try

ping -f -l 1500 acme-v02.api.letsencrypt.org
ping -f -l 1300 acme-v02.api.letsencrypt.org
ping -f -l 1100 acme-v02.api.letsencrypt.org

then you see, what works.

PS: Checked with my own domain:

ping -f -l 1500 www.server-daten.de

doesn’t work, 1300 works.

1 Like

The thing is if I update NAT in my FW and put my server behind a different public IP address it connects just fine.

No different pinging with different mtu. but like i said i flip the ip to a different ip in a different range and it connects fine…

C:>ping -f -l 1500 acme-v02.api.letsencrypt.org

Pinging ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com [172.65.32.248] with 1500 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

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

C:>ping -f -l 1300 acme-v02.api.letsencrypt.org

Pinging ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com [172.65.32.248] with 1300 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

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

C:>ping -f -l 1100 acme-v02.api.letsencrypt.org

Pinging ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com [172.65.32.248] with 1100 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

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

Flipped public ip and pings work (except 1500) and everything works. Problem is this is not the IP we need to use for the server.

C:>ping -f -l 1500 acme-v02.api.letsencrypt.org

Pinging ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com [172.65.32.248] with 1500 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

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

C:>ping -f -l 1300 acme-v02.api.letsencrypt.org

Pinging ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com [172.65.32.248] with 1300 bytes of data:
Reply from 172.65.32.248: bytes=1300 time=17ms TTL=54
Reply from 172.65.32.248: bytes=1300 time=17ms TTL=54
Reply from 172.65.32.248: bytes=1300 time=18ms TTL=54
Reply from 172.65.32.248: bytes=1300 time=17ms TTL=54

Ping statistics for 172.65.32.248:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 17ms, Maximum = 18ms, Average = 17ms

C:>ping -f -l 1100 acme-v02.api.letsencrypt.org

Pinging ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com [172.65.32.248] with 1100 bytes of data:
Reply from 172.65.32.248: bytes=1100 time=17ms TTL=54
Reply from 172.65.32.248: bytes=1100 time=17ms TTL=54
Reply from 172.65.32.248: bytes=1100 time=17ms TTL=54
Reply from 172.65.32.248: bytes=1100 time=18ms TTL=54

Ping statistics for 172.65.32.248:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 17ms, Maximum = 18ms, Average = 17ms

I’m pretty sure this isn’t a Let’s Encrypt issue, but a local network issue.

1 Like

Ok, going to keep troubleshooting on my end. If anyone things of anything else please let me know. I will post updates in case this helps anyone else in the future.

So that ip works, you should reduce your MTU to 1300 or (better) 1100. And the network of the other ip (timeout) is buggy.

1 Like

I’m curious and not such a network person: why would a MTU of 1100 bytes be better than 1300 bytes? Wouldn’t a MTU of 1100 bytes result in more fragmentation, which I thought isn’t a good thing?

So after combing through configs of firewalls, switches and routers I found that at some point 172.65.0.0/16 ended up on an acl for bad traffic we block. I’ve removed it and things are fine now. Sorry for wasting everyone’s time. Or rather double check your access lists!

2 Likes

Glad to know that youve resolved the issue.

1 Like

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