Lehnux.net Unblock Server IP Address

Help
1

Hello,

I am trying to get certificates with Traefik ACME Client for lehnux.net domain but I cannot ping or curl on acme-v02.api.letsencrypt.org but it doesn't work on one server but from 5G Mobile it works.

My WAN IP Address (where it doesn't work): 82.66.178.6
Could you please check if the IP Address is blocked by Let's Encrypt API ?

Network Subnet for this server is 192.168.20.0/24

My domain is: lehnux.net

I ran this command from Fiber WAN: ping acme-v02.api.letsencrypt.org

It produced this output from Fiber WAN:

PS C:\Users\e002531> ping acme-v02.api.letsencrypt.org

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

I ran this command from mobile: ping acme-v02.api.letsencrypt.org

It produced this output from mobile 5G:

PS C:\Users\e002531> ping acme-v02.api.letsencrypt.org

Pinging ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com [172.65.32.248] with 32 bytes of data:
Reply from 172.65.32.248: bytes=32 time=12ms TTL=50

My web server is (include version): using traefik on docker latest version

The operating system my web server runs on is (include version): Debian 13

My hosting provider, if applicable, is: Self-hosted

I can login to a root shell on my machine (yes or no, or I don't know): YES

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): NO

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): using traefik ACME Client on docker latest version

Best Regards,

Lehnux

2

What's the IP network for your LAN? Does it also start with 172 by any chance?

1 Like
3

Hello @Osiris

My Network Subnet for this server is 192.168.20.0/24

Could you please check if the IP Address is blocked by Let's Encrypt API ?

4

Please show these outputs:
traceroute -T -p 443 www.google.com
traceroute -T -p 443 acme-v02.api.letsencrypt.org

3 Likes
5

If it was blocked on Let's Encrypt's side, that's not the symptoms that you'd see.

It looks like your network (or your ISP's network) might not be routing to 172.65. correctly. We've seen a few times around here networks that somehow thought that IP should be treated like private 172.16.0.0/12 space even though it isn't. (ARIN specifically notes that people sometimes have this problem.)

3 Likes
6

Here is the requested output

I have an OPNsense Firewall at 192.168.20.252 Maybe this is a possible root cause?

~# traceroute -T -p 443 www.google.com
traceroute to www.google.com (216.58.214.68), 30 hops max, 60 byte packets
1 192.168.20.252 (192.168.20.252)  0.151 ms  0.166 ms  0.167 ms
2 192.168.1.254 (192.168.1.254)  0.815 ms  0.788 ms *
3 194.149.169.93 (194.149.169.93)  11.146 ms * *
4 194.149.166.62 (194.149.166.62)  10.794 ms  10.767 ms  10.797 ms
5 72.14.221.62 (72.14.221.62) 10.715 ms 72.14.211.26 (72.14.211.26)  10.751 ms  10.664 ms
6 * 72.14.233.77 (72.14.233.77) 9.680 ms 108.170.244.161 (108.170.244.161)  9.764 ms
7 142.250.224.93 (142.250.224.93)  10.485 ms * *
8  * * *
9 * * par10s39-in-f4.1e100.net (216.58.214.68)  9.936 ms

1:~# traceroute -T -p 443 acme-v02.api.letsencrypt.org
traceroute to acme-v02.api.letsencrypt.org (172.65.32.248), 30 hops max, 60 byte packets
1 192.168.20.252 (192.168.20.252)  0.140 ms  0.143 ms  0.121 ms
2  * * *
3  * * *
4  * * *
5  * * *
6  * * *
7  * * *
8  * * *
9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

# netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0 192.168.20.254  0.0.0.0         UG        0 0          0 ens192
172.17.0.0 0.0.0.0 255.255.0.0     U         0 0          0 docker0
172.18.0.0 0.0.0.0 255.255.0.0     U         0 0          0 docker_gwbridge
172.19.0.0 0.0.0.0 255.255.0.0     U         0 0          0 br-0aaf92b1c989
192.168.20.0 0.0.0.0 255.255.255.0   U         0 0          0 ens192
8

Please show the routing table on that system.
OR
Possibly the firewall rules are blocking that destination network.

3 Likes
9

Please find the route that would be used for the OPNSense Firewall Master (192.168.20.252) to go to acme-v02.api.letsencrypt.org

# route -n get 172.65.32.248
route to: 172.65.32.248
destination: 172.0.0.0
mask: 255.0.0.0
        fib: 0
  interface: wg1
      flags: <UP,DONE,STATIC>
recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      1420         1         0
 #

And the full routing table below

 # netstat -rWn

Routing tables

Internet:
Destination        Gateway            Flags   Nhop#    Mtu      Netif Expire
default            192.168.1.254      UGS        24   1500       vmx0
127.0.0.1          link#3             UH          2  16384        lo0
172.0.0.0/8        link#15            US         22   1420        wg1
172.20.192.16/28   link#15            U          16   1420        wg1
172.20.192.31      link#15            UHS        21  16384        lo0
192.168.1.0/24     link#1             U          17   1500       vmx0
192.168.1.50       link#1             UHS        20  16384        lo0
192.168.2.0/24     link#2             U          18   1500       vmx1
192.168.2.252      link#2             UHS        19  16384        lo0
192.168.2.254      link#2             UHS        19  16384        lo0
192.168.10.0/24    link#8             U           1   1500 vtnet1_vlan10
192.168.10.252     link#8             UHS         3  16384        lo0
192.168.10.254     link#8             UHS         3  16384        lo0
192.168.15.0/24    link#9             U           4   1500 vtnet1_vlan15
192.168.15.252     link#9             UHS         5  16384        lo0
192.168.15.254     link#9             UHS         5  16384        lo0
192.168.20.0/24    link#10            U           6   1500 vtnet1_vlan20
192.168.20.252     link#10            UHS         7  16384        lo0
192.168.20.254     link#10            UHS         7  16384        lo0
192.168.25.0/24    link#11            U           8   1500 vtnet1_vlan25
192.168.25.252     link#11            UHS         9  16384        lo0
192.168.25.254     link#11            UHS         9  16384        lo0
192.168.30.0/24    link#12            U          10   1500 vtnet1_vlan30
192.168.30.252     link#12            UHS        11  16384        lo0
192.168.30.254     link#12            UHS        11  16384        lo0
192.168.35.0/24    link#13            U          12   1500 vtnet1_vlan35
192.168.35.252     link#13            UHS        13  16384        lo0
192.168.35.254     link#13            UHS        13  16384        lo0
192.168.40.0/24    link#14            U          14   1500 vtnet1_vlan40
192.168.40.252     link#14            UHS        15  16384        lo0
192.168.66.0/24    link#16            U          23   1420        wg3
192.168.66.2       link#16            UHS        26   1420        wg3
192.168.66.252     link#16            UHS        25  16384        lo0
192.168.67.0/24    link#17            U          27   1420        wg4
192.168.67.254     link#17            UHS        28  16384        lo0

Internet6:
Destination                       Gateway                       Flags   Nhop#    Mtu    Netif Expire
default                           2a01:e0a:189:cb80::1          UGS        12   1500     vmx0
::1                               link#3                        UHS         1  16384      lo0
2a01:e0a:189:cb80::/64            link#1                        U          13   1500     vmx0
2a01:e0a:189:cb80::2              link#1                        UHS        10  16384      lo0
2a01:e0a:189:cb81::/64            link#8                        U           5   1500 vtnet1_vlan10
2a01:e0a:189:cb81::2              link#8                        UHS         4  16384      lo0
2a01:e0a:189:cb81::3              link#8                        UHS         4  16384      lo0
2a01:e0a:189:cb82::/64            link#10                       U           7   1500 vtnet1_vlan20
2a01:e0a:189:cb82::2              link#10                       UHS         6  16384      lo0
2a01:e0a:189:cb82::3              link#10                       UHS         6  16384      lo0
2a01:e0a:189:cb83::/64            link#12                       U           9   1500 vtnet1_vlan30
2a01:e0a:189:cb83::2              link#12                       UHS         8  16384      lo0
2a01:e0a:189:cb83::3              link#12                       UHS         8  16384      lo0
fe80::%vmx0/64                    link#1                        U          11   1500     vmx0
fe80::20c:29ff:feb0:edba%vmx0     link#1                        UHS        10  16384      lo0
fe80::%lo0/64                     link#3                        U           3  16384      lo0
fe80::1%lo0                       link#3                        UHS         2  16384      lo0
fe80::%vtnet1_vlan10/64           link#8                        U           5   1500 vtnet1_vlan10
fe80::20c:29ff:feb0:edc4%vtnet1_vlan10 link#8                   UHS         4  16384      lo0
fe80::%vtnet1_vlan20/64           link#10                       U           7   1500 vtnet1_vlan20
fe80::20c:29ff:feb0:edc4%vtnet1_vlan20 link#10                  UHS         6  16384      lo0
fe80::%vtnet1_vlan30/64           link#12                       U           9   1500 vtnet1_vlan30
fe80::20c:29ff:feb0:edc4%vtnet1_vlan30 link#12                  UHS         8  16384      lo0
~ #
10

^ there is the problem

5 Likes
11

Hello,

I found out the reason, it was due to a Wireguard tunnel for DN42 on the OPnSense Firewall that had a range of 172.0.0.0/8 in AllowedIP instead of 172.20.0.0/14

After changing the AllowedIP value in the wg1 tunnel, the traceroute now works

~# traceroute -T -p 443 acme-v02.api.letsencrypt.org
traceroute to acme-v02.api.letsencrypt.org (172.65.32.248), 30 hops max, 60 byte packets
1 192.168.20.252 (192.168.20.252)  0.348 ms  0.232 ms *
2 192.168.1.254 (192.168.1.254)  0.656 ms  0.515 ms *
3 194.149.169.85 (194.149.169.85)  10.270 ms  10.130 ms *
4  * * *
5 prs-b3-link.ip.twelve99.net (62.115.46.68)  10.860 ms  65.294 ms  11.112 ms
6 prs-bb2-link.ip.twelve99.net (62.115.118.62) 11.420 ms 11.927 ms prs-bb1-link.ip.twelve99.net (62.115.118.58)  11.393 ms
7 prs-b1-link.ip.twelve99.net (62.115.125.167) 11.404 ms prs-b1-link.ip.twelve99.net (62.115.125.171)  12.637 ms  11.685 ms
8 cloudflare-ic-375100.ip.twelve99-cust.net (80.239.194.103)  28.289 ms  12.782 ms  23.563 ms
9 172.71.128.4 (172.71.128.4) 12.871 ms 172.71.124.2 (172.71.124.2) 16.818 ms 141.101.67.54 (141.101.67.54)  14.709 ms
10 172.65.32.248 (172.65.32.248)  11.032 ms  11.629 ms  11.460 ms
~#

Thank you all for your time, we can close this issue.

Regards,

Lehnux

4 Likes
12

What's that for kind of range? Because if you meant to implement the private range, it's 172.16.0.0/12.

14

It's not a firewall rule.
It's a route entry to reach the defined [private] networks in use.

3 Likes
15

Ah, so they subnetted the172.16.0.0/12 into multiple /14's.

16

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