Problem with WAN access following a new VM installation

Hello everyone,

I apologize for posting something that is probably pilot error, but which hopefully can be quickly sorted out by someone with more expertise. I hope that this is a proper place to make this posting.

I have installed Nextcloud on a mac mini (2014 with 4 Gb memory, 1 TB SSD) running the latest version of Catalina 10.15.4. I first installed VirtualBox 6.1.6 and then installed Nextcloud 18.0.4 to run as a VM. I got a domain name from NoIP (, for my dog Bruce! ) and set up the router to forward ports 80 and 443 to the IP I have chosen for the VM running Nextcloud ( Using a web site like yougetsignal on the LAN confirms that the ports are open for bruceshouse, as did the Nextcloud installation script.

The installation (including running Let’sEncrypt) seems to complete without issues, I can access Nextcloud via the local IP, i.e. But when using the domain name (bruceshouse, still on the LAN, it times out. The strange thing is that the browser says that the website is not secure, and that there is an invalid certificate. When I check the certificate at the browser it shows that it is valid, but for bruceshouse (why bruceshouse is associated here with the VM IP I don’t understand). Checking with ssllabs ssltest also confirms that the certificate for bruceshouse is A+ okay for the WAN IP address, as expected.

Starting and stopping the Nextcloud VM made no difference. I removed and reinstalled Nextcloud and then a complete uninstall of VirtualBox also after various attempts to get the proper web access failed (actually VirtualBox crashed, every time, when directed to completely remove all files of the Nextcloud OVA). Perhaps I set something incorrectly during the first install (it might have been that Let’sEncrypt failed during the first installation - it’s been days ago…) and something (in Ubuntu or Apache?) that has been causing the problem wasn’t cleared out with the attempted removal of Nextcloud from VirtualBox, or from the removal of VirtualBox itself. But I have no idea of what or where the culprit might lurk.

A thing which puzzled me was that nslookup of bruceshouse on the VM after the install showed that the IP address was and that the nameserver was, while nslookup on OSX gave the correct WAN IP for bruceshouse. So I as a last attempt I added additional nameservers on the VM using
sudo nano /etc/resolvconf/resolv.conf.d/head
adding the lines
and restarted the Nextcloud VM. Nslookup on the VM now shows that bruceshouse has the correct WAN IP address, but the behavior of the browser is the same with no access via the domain name. The behavior is and has been the same with both chrome and safari, and the Nextcloud client running on a macbook air can also only access via the Nextcloud VM LAN IP after the security complaints. Finally, out of concern that particular LAN IP address had been mucked up, I made one more attempt at a clean install choosing a different Nextcloud VM IP address as with port changes. The install completed successfully with new certificate but ending with the exact same final behavior. Now when I open the Nextcloud web page at it says that it is insecure with an invalid certificate, while checking the certificate indicates that it is valid, but associated to bruceshouse, while simply times out.

Probably this is some stupidity on my part, but I have now spent too much time on it and am about to give up on installing Nextcloud. Thanks for your attention.

Two things I will mention here:

Hi Karl,

Thanks for the very quick response. I did the suggested change to the config.php file i.e. adding
‘overwritehost’ => ‘
but that didn’t change the behavior. I had already nosed around in this file based on some googled suggestions, but didn’t consider this change because there are no proxies involved in my LAN.

As I mentioned, I am puzzled by the behavior - as you say I would have thought the using the bruceshouse domain would have sent the request to the router which would have been resolved via it’s DNS server which would then have sent it back to the Nextcloud server via portforwarding. (I agree that this isn’t a very efficient way to use the network, but I would have expected that it should work, although by unreliable do you mean that one can’t expect it to work for all routers? Out of curiosity, not knowing that much about network traffic. I presume that the Nextcloud VM does see the bruceshouse domain name going out on the LAN but doesn’t respond to it directly, although it apparently does make the connection to the bruceshouse domain name and it’s IP when it claims the SSL certificate is invalid). I haven’t tried to access Nextcloud outside the LAN (staying at home these days…) but I am skeptical that it will work on the outside network if it isn’t working on the LAN with the domain name.

I do think that it is somehow a confusion on the part of Nextcloud and/or the VM. As I mentioned already, I was surprised that the nslookup of bruceshouse on the VM window has the wrong IP address, which maybe is okay? The behavior with the SSL certificate I think is a hint to the source of the problem, but I don’t know enough of the expected behavior to sort it out. The Nextcloud VM recognizes when it is being addressed when I use it’s LAN IP, but as I said the browser shows that there is a SSL certificate that is invalid, which when I check says that it is a valid certificate, but for bruceshouse. So I assume that it is the Nextcloud VM, where the certificate was generated, that somehow doesn’t realize that it is bruceshouse. When I start the Nextcloud VM it does report the correct WAN (=bruceshouse) and LAN IP address for itself. I also note that the config.php does list bruces house as a trusted domain at startup.

Again, thanks for the quick response, any other suggestion of things to check or try are much appreciated. As I said I’m about to throw up my hands. As it is, I can use Nextcloud strictly as a LAN server, but that would be a major concession.

I assume the reason for this is because you named the server with the same name. If that’s the case, then this behavior is expected. Some operating systems will resolve their own names to a loopback address due to an entry in their hosts file.

Yes, I mean exactly that. Many enterprise-grade firewalls will by default drop traffic that would ingress and egress the same interface. And some that allow it may exhibit strange behavior. It’s just not a good idea in general, especially when the solution of running split-horizon DNS is easy enough to do and beneficial in a number of other ways.

I would resolve this issue first before trying to troubleshoot further, to be honest.

Hi Karl,

Okay, I did finally check access to bruceshouse via the 5G phone network and it works as it should. So it is a router behavior issue as you suggested. Sorry about the wasted time on that - I should have tried that sooner but was too certain that it should work on the LAN.

Based on your comment about running a split-horizon DNS server I checked and saw that I could set up the router to resolve bruceshouse to the Nextcloud VM and that cured everything. I now have clean access via the Nextcloud desktop client as well as with Safari and Chrome, and the SSL certificate is valid.

Again thanks for your quick and helpful responses.