QNAP SSL certificates overrides Letsencrypt's in LAN?

[seaan]

Hello,
I've been scratching my head on this problem over the past two hours and I'm evidently missing something about the subject matter.

For the past two weeks I've been accessing my NAS remotely and deployed a number of docker containers delivering services like Nextcloud, a Jekyll blog, etc.
I've purchased a domain, generated Letsencrypt certificates and configured a reverse-proxy (Traefik) to forward all incoming requests to the appropriate service
Everything was and is working perfectly from the Internet or VPN: the Nextcloud client could connect to the server without issues, the browser was correctly handling https and showing my websites as secure, etc.

But today I'm back home and connected to my LAN and I'm getting all sorts of certificate errors while accessing the same services locally.
I'm trying to zero in into the possible culprit and I guess it's either the reverse-proxy server or the NAS itself.
I tend to think it's the latter because Traefik is not generating any log file when I'm trying to access the services from the LAN as if the requests are being trapped somewhere before they hit the reverse-proxy.

Take Nextcloud for example: when I try to open the site using the browser (I'm getting a similar error when launching the Netcloud client) at (say) https://nextcloud.mydomain.com the browser shows a MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT error. If I display the certificates that the browser sees I get QNAP's instead of my own!



Why the heck is my letsencrypt certificate not being delivered and QNAP's instead is??

Why is that error displayed if:
1) The browser (even in the LAN) is (or should be) still trying to reach the server via the FQDN domain name which resolves into my router's public IP
2) and then hit Traefik which forwards the request to the appropriate container using the domain SSL certificates
3) which finally responds to the original client (the browser)

It seems like the clients requests when running in the LAN are not handled via the 1-2-3 chain above and the correct SSL certificates are not correctly delivered.
Like I said: everything works perfectly when I am connecting from the internet and not from the LAN.
I'm completely clueless and I'd appreciate some help.

Thanks
Regards

[Mousetick]

What is the result of a DNS lookup of nextcloud.mydomain.com when inside your LAN? Is the correct public IP address returned?
Which service is listening to port 443 on the NAS? Is Internet port 443 forwarded directly to port 443 on the NAS by the router, or is it forwarded to another NAS port, such as 443 to 8443 for example?
What happens when you bypass Mozilla's MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT warning for https://nextcloud.mydomain.com and confirm the connection? What response do you get from which service? QTS web admin login page, your nextcloud UI, or something else?

[seaan]

Hi Moustick,
first of all, I have to amend a piece of information I gave in the previous post.
The certificate that is provided to my browser is not QNAP's but is my router's (a Sercomm router provided by Vodafone).
I had overlooked the Provider's Organization in the certificate page, spotted "Country CN" and immediately thought it was the QNAP's certificate when in fact is the router's.
So it is likely that the culprit is none of the NAS or the reverse-proxy but rather the router.

However, see answers below:

What is the result of a DNS lookup of when inside your LAN? Is the correct public IP address returned?
The result of the lookup is the public IP address of my router (tried with ping nextcloud.mydomain.com), exactly as it happens when outside the LAN.


Which service is listening to port 443 on the NAS?
The only service listening on port 443 on the NAS is the reverse-proxy Traefik.

Is Internet port 443 forwarded directly to port 443 on the NAS by the router, or is it forwarded to another NAS port, such as 443 to 8443 for example?
Port 443 is forwarded directly to 443 on the NAS.

What happens when you bypass Mozilla's MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT?
For the Nextcloud service I cannot bypass as:"nextcloud.mydomain.com has a security policy called HTTP Strict Transport Security (HSTS), which means that Firefox can only connect to it securely. You can’t add an exception to visit this site".
However, for other services (e.g. a Jekyll-based blog) I can bypass and in these cases something weird happens: the browser is forwarded to a web page on my router at URL: https://192.168.0.1/interception.html (that's the local IP address of my router) which says "There is no Internet connection".

What response do you get from which service?
All services that are served by the reverse-proxy give the same error MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT.
I have a DAV application on my mobile (DAVx5) that synchronizes the Nextcloud calendar with my phone's which gives a different error (HTTP 501 Not implemented) but I guess that the certificate problem gives way to all sorts of issues.

Thanks for your help
Sergio

[Mousetick]

first of all, I have to amend a piece of information I gave in the previous post.
The certificate that is provided to my browser is not QNAP's but is my router's (a Sercomm router provided by Vodafone).
I had overlooked the Provider's Organization in the certificate page, spotted "Country CN" and immediately thought it was the QNAP's certificate when in fact is the router's.

Well in that case that changes everything

So it is likely that the culprit is none of the NAS or the reverse-proxy but rather the router.

Yes. Most consumer-grade NAT firewall/routers don't forward connections when accessed from the LAN using their global public IP address, they just respond themselves. This is a software limitation on the router itself. Some models are capable of Hairpinning aka NAT loopback, but when it comes to ISP-provided devices, you have no choice and it's just the luck of the draw.

Possible workarounds:
- If your ISP provides IPv6 service to your home/office, you can use IPv6 in your LAN as well, making sure your NAS's global IPv6 address is registered in DNS for nextcloud.mydomain.com. It's the cleanest solution, as all devices have their own unique IPv6 accessible from anywhere (as permitted by firewalls), being LAN or WAN, without going through NAT nor port forwarding.
- If you're stuck with IPv4, you need to override the DNS for nextcloud.mydomain.com with the LAN IP address of your NAS on each of the clients on your LAN. This is accomplished by editing the 'hosts' file. Google 'how to edit hosts file for whichever OS you're using' for instructions. For example, if your NAS local IP address is 192.168.1.23, you need to add this entry in the hosts file:

Code: Select all

192.168.1.23 nextcloud.mydomain.com

After that connections to nextcloud.mydomain.com will go directly to your NAS instead of going through your router, when accessed from a client on your LAN.

[seaan]

Hi,
IPv6 is unfortunately not supported by my ISP and using the host file for name resolution might be then the only option, even if it requires some tinkering with my virtual switches as the requests should be forwarded via host-file to the traefik container is now NAT-ed and not bridged and as such does not have an IP address exposed in the LAN: should be easy to set it up.

But I am clearly off-topic now and I renamed the subject of this thread.

Many many thanks for helping with the troubleshooting.

Regards

Sergio

[dgmckenzie]

Use a VPN

That way you will be coming from the outside.

[seaan]

Use a VPN

That way you will be coming from the outside.

Yes, this is also an option but I'd rather use something that does not require me to remember to switch VPN on or always keep it on.
I read about using Split DNS via dnsmasq, I'll give it a try

Thanks!

[seaan]

I finally managed to setup Split DNS using Pi-Hole which can be configured as a Local DNS server.
I created entries in its domain resolution register for my subdomains pointing to the IP of the Traefik reverse-proxy.
When devices are connected to my LAN they use Pi-Hole as the DNS Server.

Problem solved.