I am running Nextcloud AIO (Nextcloud 32.0.6.1) behind a reverse proxy (Nginx PM) and it works very well. Additionally I am using Pihole as my internal DNS server.
The idea was to access Nextcloud AIO internally (faster, lower latency) over the identical domain by creating an DNS record that contains my Nextcloud domain pointing to my reverse proxy.
As explained here: One domain, externally and internally used
Everything seemed to work fine until I looked into the Security & Setup Warnings.
If I access Nextcloud AIO internally I get a lot of warnings in Security & Setup Warnings. If I remove the DNS record from my Pihole (external access) the warnings are gone.
Is there a way to fix this?
I don’t want to damage anything.
Thanks.
Edit: The additional warnings I get with internal access (Sorry, German only)
Datenverzeichnis geschützt
Unterstützung für JavaScript-Quellkarten
JavaScript-Modulunterstützung
OCS Anbieter-Auflösung
WebDAV-Endpunkt
.well-known URLs
Laden der Schriftartdatei
HTTP-Header
For my setup, I ended up using Pi-hole as the internal DNS override for the same public Nextcloud domain, and it works correctly for both internal and external access.
My setup looks like this:
Nextcloud AIO behind Nginx Proxy Manager
Public domain: cloud.example.net
Internal IP of the reverse proxy NPM: 192.168.50.10
Pi-hole IP: 192.168.50.5
In Pi-hole, I configured (do not forget switch settings from Basic → Expert):
With this in place, internal DNS resolution returns only the internal reverse proxy IP, while external clients still resolve the public IP through public DNS.
Example internal result:
nslookup cloud.example.net 192.168.50.5
Result:
Name: cloud.example.net
Address: 192.168.50.10
I also verified it locally with:
dig cloud.example.net
and it returns:
192.168.50.10
The web interface also loads correctly internally via:
https://cloud.example.net
So in my case, this gives me:
one domain for both WAN and LAN access
internal access that goes directly to the local reverse proxy
no need to rely on hairpin NAT
continued LAN access to Nextcloud even if the internet connection is unavailable, as long as LAN, Pi-hole, NPM and Nextcloud are still running
DNS connection to Pi-hole can either be configured manually only on selected devices, or distributed centrally through the network device that provides DNS/DHCP for the LAN.
I also do not see any errors in the Nextcloud logs with this configuration.
Thank you very much for your quick and detailed response.
My configuration matches yours except I did not set the FQDN in Pihole’s “DNS domain settings”. I have never changed this setting, still set to “lan”.
I set my FQDN in Pihole’s “DNS domain settings” and disabled “Expand hostnames” as you showed in your example but unfortunately nothing changed. I expected that it would not make any difference but was worth as shot.
I am still getting the mentioned warnings as soon as I add the DNS record to Pihole for my Nextcloud public domain pointing to my Nginx PM reverse proxy. As soon as I remove this DNS record and return to external access, the warnings disappear.
In my case, changing that setting actually made a difference.
Originally, Pi-hole was still using the default lan value in DNS domain settings, and with that setup I was not getting a clean internal resolution for my Nextcloud domain. It kept returning both the internal IP and the public DNS result.
I changed that setting from lan to my actual domain, and after that Pi-hole started resolving the Nextcloud hostname internally only to the local reverse proxy IP.
So for me, that change was important, not just the local DNS record itself.
After that:
internal resolution worked correctly
the web interface loaded fine internally
and I do not see warnings or related errors in Nextcloud with this setup
So at least in my environment, leaving that value as lan was not enough.
I only started working on the Pi-hole redirection a few days ago. Before that, I was accessing Nextcloud only through the normal external/public path, so this is also a fairly new setup for me.
Something must be different in our setups. But setting Pi-hole’s DNS domain settings permanently to my public domain would cause additional problems in my network. But from what I was able to research regarding this setting, it makes sense to use it in this case but should not be necessary.
It is good to know that I am not doing something completely wrong because our configurations are very similar. I will research the problem further but I can live with the default public access only solution. The internal access would be nice to have but not essential. I am happy how Nextcloud AIO works how it is.
If I find a solution in my network within the next 3 months I will report back here.
Likely the warnings are not “real” but simply a result of Docker issues when container can not access services running on the host network (like AiO accessing your reverse proxy).
My best solution for this was to duplicate the split-brain DNS config inside Docker so all internal communications (e.g. from Nextcloud to Collabora) doesn’t go outside of the system but hits the reverse proxy internally. Look at Probably DNS help with NC Docker + Collabora + Wireguard tunnel
Thank you for this tip, I didn’t think of the problem that Nextcloud loops through the internet to reach itself in my network.
I added the local DNS record for my Nextcloud public domain to my local DNS server (Pi-hole) pointing to my reverse proxy ip.
If I reload the administration page in the browser, all warnings disappear.
I disabled the port forwardings 80/443 for the reverse proxy (Nginx PM) in my router and now all the mentioned warnings appeared again and stay after reloading the page repeatedly. I enabled the port forwardings again and the warnings were gone.
So, it is obvious that the presumed local access has been routed through the internet.
I am afraid I do not understand your approach described in your post.
My reverse proxy is in a macvlan network and a bridge network but also in the nextcloud-aio network. In the Nextcloud AIO compose file I added the reverse proxy bridge network to the Apache container (additional network for Apache).
But obviously that is not enough to keep all Nextcloud traffic purely local.
Traffic is not actually routed through the public internet. With hairpin NAT aka NAT loopback, the client sends traffic to your router’s public IP address, and the router then redirects it back to the internal Nextcloud server.
This usually works fine, but it has a few disadvantages. The traffic has to pass through the router twice, which adds some overhead. On weaker consumer routers, this may reduce performance. In addition, many routers perform source NAT as part of hairpin NAT. In that case, Nextcloud will see the connection as coming from the router’s internal IP address rather than from the actual client device. This can make logs less accurate, or cause issues with Nextcloud’s built-in brute force protection.
A cleaner alternative, as @wwe already said is split-horizon DNS: inside your network, the domain name resolves directly to the internal IP of the Nextcloud server or reverse proxy, instead of the public IP. That avoids the extra NAT steps.
But this configuration leads to the mentioned warnings and I am not sure whether this is a serious problem or not.
@wwe suggested a docker internal Split-Horizon DNS which sounds reasonable but I have not the appropriate knowledge to implement his interesting suggestion.
As said I can live with the classic public access only solution, pure local access would be nice to have but I am still not sure how to accomplish it without potential problems.
setup warning are result of checks failing.. the system itself remains the same if you only add the split-brain DNS records so you don’t cause any harm.. the only issue could be if you learn to ignore the warnings and later a real problem arise and you don’t notice it.
I would like to sincerely thank you all for your kind, patient, and informative responses.
I have learned a lot from your explanations and did some more research on my own regarding NAT, NAT loopback and my router (Fritz Box).
I tried the Docker alias solution @wwe suggested, thank you Willi, but it made no difference, at least it seemed that way, no difference regarding the warnings or latency.
With the local DNS record in my Pi-hole, my Nginx PM configuration and the NAT loopback in my router the whole Nextcloud traffic should be handled locally. So, I am happy.
If I call the Nextcloud administration page the first time, I will get only the WebDav warning. If I reload the page in my browser, the WebDav warning disappears.
