So the MTU of Tailscale is actually 1280, but is the connection even going through the VPN or rather through my VPS, when Uptime-Kuma is trying to connect to my local domain?
Formerly know as u/Arjab.
Anarchist | Antifascist | Anticapitalist.
Arch Linux | FOSS | Piracy | Security & Privacy
Looking for a Mastodon instance?
Check out @[email protected].
So the MTU of Tailscale is actually 1280, but is the connection even going through the VPN or rather through my VPS, when Uptime-Kuma is trying to connect to my local domain?
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. ;)
Yep
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.
After changing the MTU to 1200 I have no timeouts anymore, but a lot of
read ECONNRESET
errors. -.-