I have running the linuxserver-io letsencrypt image, the linuxserver-io nextcloud and many other conatiners in my docker. And in general, those are all working fine, thank you
Coming to my problem.
My nextcloud is accessable from outside world via https and my domain cloud.domain.com
Certificates issued and working.
When I upload something to my nextcloud within my network at home (where nextcloud and docker an so on is physically located), it is incredibly slow. I think this is directly linked to slow upload speed of my internet. 10MBit upload speed. So I have the same upload speed when I am uploading from the internet or while I am at home.
So I added the cloud.domain.com to my FritzBox as DNS rebind, but there was no improvement. Still the same slow uplaod speed ~1.2MB/sec.
In my network I have a Pihole running. There I added as “local DNS entry” my domain linked to local IP.
After that, I can’t access my nextcloud anymore from local network. Neither via cloud domain com nor via IP directly.
is your letsencrypt container running on port 80/443 or did you remap it?
when you nslookup cloud.domain.com from an internal machine, do you see the internal ip or the external ip?
my letsencrypt container is running on port 81/444 and is linked to 80/443 outside world.
local DNS entry in pihole:
With nslookup cloud.domain.com I get the lokal IP back
DNS rebind in FritzBox only:
I get the public IP back with nslookup cloud.domain.com
If you want it to work internally, you can’t remap the ports. Externally it works because you port forward 443, so when you go to https://cloud.domain.com it hits 443 on your router, forwards to 444 on your docker host, forwards to 443 in letsencrypt. When you go to https://cloud.domain.com internally, you hit the IP of your docker host on port 443 which is NOT letsencrypt (letsencrypt is 444). You would need to do https://cloud.domain.com:444 internally if you do not change things.
To make it work how you want, you need to use port 443 and not remap it. If something else is using 443, remap that and then reverse proxy to it using letsencrypt.
Prior to putting in your local dns entry (which broke things because of the 444) you said internally you had very slow speed. This is likely due to hairpin nat on your router and the subsequent packet inspection.
Next, is this, you’ve generated a cert for cloud.domain.com, so if you are seeing this, but only when going internally, you’re either using the IP, a different name than you made a cert for, or you put a self-signed cert somewhere. Look at the cert and see what thing it is, this may help you find what the deal is.
You’ve got a few issues here, so i tried to segment them out, but the issues I saw you report are
my nextcloud is running on machine A with IP x.x.x.3 and port 443
letsencrypt on Machine B with IP x.x.x.4 and port 81/444 internally and 80/433 externally.
my local DNS entry for cloud . domain . com is linked to x.x.x.3
Do I have to access the nextcloud also via machine B internally? Than I would agree that I have to change the letsencrypt port to 80/443.
Is this the case?
So the local DNS entry would be cloud . domain . com x.x.x.4 instead of x.x.x.3
The certificate issue is only present, while the local DNS entry is set.
If there is no local DNS entry, the connection is fine, no cert issue but all the traffic routed through the internet
