0

I installed a nextcloud service on my NAS in a docker container and the service is reachable from the internet via a FQDN for which I generated wildcard Letsencrypt certificates. A reverse proxy (Traefik) is dispatching requests to the service and handles http/https.

Everything works fine while outside of my LAN but connecting to nextcloud from the local network gives certificate errors. For instance, trying to open the nextcloud home page from Firefox gives:

nextcloud.yourdomain.com uses an invalid security certificate.
The certificate is not trusted because it is self-signed.
Error code: MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT
View Certificate

Clicking on "View Certificate" actually shows the router's own certificate.

As an additional information, my nextcloud service FQDN is correctly resolved to my router's public IP address even from within the LAN, i.e.

ping nextcloud.yourdomain.com

correctly returns the public IP address of my router.

How can I avoid this? Why is the router using its own certificates for https traffic to hosts that are inside my LAN instead of my my domain's Letsencrypt certificates, exactly as it's happening from outside the LAN?

Evidently the reverse-proxy or the NAS are not to be blamed as https requests are not even reaching them.

Could you help me with some additional troubleshooting? Thanks PI

Sergio
  • 25
  • 3

1 Answers1

0

The external IP address you use is actually the IP address of your router. For traffic from outside (i.e. the internet) there is a port forwarding rule which forwards this traffic to the internal server. For traffic from inside this port forwarding will not be applied - this is how your specific router works. And since there is actually a service running on the same port (the admin interface of the router) and this is reachable from inside it will be used instead.

Note that this is how this particular router works. A different router might apply the port forwarding to both internal and external traffic. It would need to support NAT loopback too in this case though.

A workaround would be to use split DNS, i.e. access the nextcloud from outside by the public IP address and from inside by the internal IP address. If such a setup can be done with the systems you already have is unknown.

Steffen Ullrich
  • 114,247
  • 10
  • 131
  • 172
  • Hi Steffen, NAT loopback is indeed the issue here, I came to the same conclusion while doing further research. I have a consumer router (Sercomm) provided by the telco and I'm quite positive it does not support NAT Loopback, so I would have to resort to use split DNS techniques as you suggest. I am already using PiHole in my LAN: would that serve the purpose, any resource you may point me to, besides googling? Thanks – Sergio Jan 10 '21 at 11:44
  • @Sergio: Based on a short search pi-hole should support something like local DNS records, which probably can be used for this service. I.e. just resolve your public domain to your internal IP on pi-hole, no matter if it has a different IP when resolved on the internet. – Steffen Ullrich Jan 10 '21 at 13:11
  • Done. I defined local DNS settings in Pi-Hole and I configured it as the DNS server for my devices when connected to the wifi LAN. Works perfectly – Sergio Jan 10 '21 at 18:51