Local domains constantly time out according to Uptime-Kuma
from dataprolet@lemmy.dbzer0.com to selfhosted@lemmy.world on 18 Nov 13:25
https://lemmy.dbzer0.com/post/31738466

I followed this tutorial to set up local domain names with SSL-certificates using DuckDNS: notthebe.ee/blog/easy-ssl-in-homelab-dns01/

I have three local domains for my Nginx Proxy Manager running on a VPS, for my self-hosted Nextcloud and my Proxmox-WebGUI both running on my local Homeserver. They follow the scheme service.dataprolet.duckdns.org.

Now I use Uptime-Kuma to monitor my services including the three domains and for some reason those three domains constantly time out after 48 seconds. I already set up the retries to 3, but to no avail.

I also use Pi-hole and Unbound and thought, that might be an issue, but testing my DNS using dig, mtr, traceroute, nslookup and host all returned normal values and no errors.

Does anybody have any idea what could cause this? I’m kind of clueless at this point. Thanks in advance!

EDIT: I don’t get it.

  1. I can’t ping duckdns.org on my home server. I only get 100 % packet loss. I can open the website in my browser though. I also can’t ping www.duckdns.org, which redirects to appservers-duckdns-prod-1630339571.ca-central-1.elb.amazonaws.com. Also gets 100 % packet loss.
  2. I’ve added duckdns.org to my Uptime-Kuma and it got flagged as down because timeout of 48000ms exceeded but my other domains using DuckDNS were unaffected.
  3. I added another local domain to Uptime-Kuma to see the differences of having ignoring SSL errors tuned on or off and the number of retries:

Throughout the day only the newly added Homepage got flagged as down for 5 times. The 3 others were up the whole time.

#selfhosted

threaded - newest

rearview@lemmy.zip on 18 Nov 13:37 next collapse

  • Is your uptime kuma server on the same machine as your other services?
  • Are you using docker/podman? If so can you try to curl your services’ domain from inside the container and see if they resolve?
dataprolet@lemmy.dbzer0.com on 18 Nov 13:52 collapse

Yes, Uptime-Kuma is running on the same domain as the other services, except the Nginx-Proxy-Manager, which runs on a VPS which I access via WireGuard. And yes, I’m using Docker. I tried curl’ing one of the domains from the Uptime-Kuma container and got the folllowing error: curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to service.datenprolet.duckdns.org:443. So thanks, now I have an idea about what I should investigate.

alwayssitting@infosec.pub on 18 Nov 14:54 next collapse

If you ping the domain from inside the container, does it succeed?

dataprolet@lemmy.dbzer0.com on 18 Nov 18:38 collapse

Yep

alwayssitting@infosec.pub on 18 Nov 19:53 next collapse

Sorry I’m a bit confused. What kind of tracker are you using in uptime-kuma and what address is it pointing to?

dataprolet@lemmy.dbzer0.com on 18 Nov 20:30 collapse

What do you mean by tracker? I’m monitoring local domains, that point to local services and their respective web interfaces like Proxmox or Nextcloud. The local domains have a wildcard SSL certificate via DuckDNS.

alwayssitting@infosec.pub on 18 Nov 20:32 collapse

<img alt="" src="https://infosec.pub/pictrs/image/88d6e9c7-514a-41fd-b4cf-b6a36c0f7630.png"> Which one of those. You pick one when adding something new to monitor. Actually just send a screenshot of the uptime-kuma settings of one of the services that are giving you problems.

dataprolet@lemmy.dbzer0.com on 18 Nov 20:55 collapse

It’s HTTPS, what else should it be, when I monitor a domain?

alwayssitting@infosec.pub on 18 Nov 21:01 collapse

Well you keep saying monitor a domain, in that case a DNS monitor would make more sense than HTTP(s) since that’s for monitoring a service. That’s why I was a bit confused. But yeah try to enable the ignore SSL option and see if that changes anything. You didn’t include a screenshot of the settings which makes a bit difficult to diagnose the problem so I will leave it here.

dataprolet@lemmy.dbzer0.com on 19 Nov 15:08 collapse

Not sure how this helps, but here you go.

<img alt="" src="https://lemmy.dbzer0.com/pictrs/image/6fd45289-d4b3-491a-a250-70b38e7394e6.webp">

rearview@lemmy.zip on 18 Nov 21:16 collapse

seems like your DNS works fine but your certs doesn’t. Are you able to connect to your services on your browser normally, with SSL?

Edit: please also try curl -4 and curl -6 to your services from within the uptime kuma container to see if theres an ipv4/v6 issue

Another edit: seems like there is a dataprolet URL in your post and a datenprolet URL in your comments. It might just be a typo so also check that too.

dataprolet@lemmy.dbzer0.com on 19 Nov 11:42 collapse

Yeah, it works fine through my browser. Sometimes the websites load a little longer. I feel like it’s an issue with DuckDNS as it’s seemingly random when it works and when not.

IPv6 doesn’t work:

docker exec -it Uptime-Kuma curl -6 proxmox.datenprolet.duckdns.org
curl: (6) Could not resolve host: proxmox.datenprolet.duckdns.org

Besides that the issue has disappeares since last night. I automatically restart all containers at night and moved from uptime-kuma:1 to uptime-kuma:latest. That shouldn’t make a difference, but maybe it did?

And it’s not a typo in my config, but in my post. But good catch. ;)

rearview@lemmy.zip on 19 Nov 14:57 collapse

Could not resolve host

Then I guess you only define an A record in the DuckDNS panel. That’s fine.

A while back I ran a somewhat similar Wireguard tunnel and can’t connect. Turns out some MTU settings were lower than the docker’s MTU and that breaks big packets like SSL handshakes. Restarting makes it work fine until things start congesting again.

Suffice to say this would be something I’ll look at if the SSL errors reoccurs

dataprolet@lemmy.dbzer0.com on 20 Nov 16:00 collapse

Thanks, since I access my home network and server through the public IPv4 of a VPS via Tailscale this could actually be the issue. I’ll look into it, when I find the time.

schizo@forum.uncomfortable.business on 18 Nov 16:44 collapse

Are uptimekuma and whatever you’re trying to monitor on the same physical hardware, or is it all different kit?

My first feeling is that you’ve got some DNS/routing configuration that’s causing issues if you’re leaving your local network and then going through two layers before coming back in, especially if you have split horizon DNS.

dataprolet@lemmy.dbzer0.com on 18 Nov 18:39 collapse

Well, I’m monitoring the GUI of Proxmox on which I run a Debian VM which itself runs Uptime-Kuma and Nextcloud in Docker, so yes that’s on the same hardware.

retro@infosec.pub on 18 Nov 20:14 collapse

I’ve heard DuckDNS has become more unreliable. You could try another service like afraid.org and see if it makes a difference.

dataprolet@lemmy.dbzer0.com on 19 Nov 11:42 collapse

Yeah, I suspect it’s simply an issue on the side of DuckDNS. :/