Accessing Nextcloud from LAN when Internet is down

ℹ️ Support 📦 Appliances (Docker, Snappy, VM, NCP, AIO)
,
1

I’ve set up Nextcloud with the fantastic AIO docker solution.

I think it’s a great tool.

In front of Nextcloud there is a Caddy reverse proxy. I can access “cloud.mycooldomain.com” with https just fine from the browser and from the WebDAV.

My only concern now is this: when Internet is down I can’t access Nextcloud even from machines in the same LAN.

My solution was adding “[my LAN server ip address] cloud.mycooldomain.com” in “C:\Windows\System32\drivers\etc\hosts”, but https fails if Internet is down (for obvious reasons). It works only if Caddy equips “cloud.mycooldomain.com” with a self-signed certificate. But at that point WebDAV access fails (Windows doesn’t accept self signed certs?).

Is there a cleaner solution for this problem?

2

Yes, see https://github.com/nextcloud/all-in-one#how-can-i-access-nextcloud-locally

1 Like
3

Thank you: I’ve already read that part.

But running a local DNS isn’t like editing “C:\Windows\System32\drivers\etc\hosts”? Even if my machine can correctly translate “cloud.mycooldomain.com” into an IP address, if the Internet is down then the https will fail, right?

4

Editing the hosts file is an alternative to running a local dns server. It should actually work automatically if the correct header is set as the certificate will keep working for your domain even without public internet.

5

Try setting up DNS on your router for the local nextcloud.

6

Here is what I get.

If I don’t edit “C:\Windows\System32\drivers\etc\hosts” and Internet is up, everything is perfect (a lock is show in the chrome address bar).

If I edit “C:\Windows\System32\drivers\etc\hosts” and Internet is up, I get a warning in chrome (a red exclamation mark is shown in the address bar), but everything runs ok, even WebDAV.

If I edit “C:\Windows\System32\drivers\etc\hosts” and Internet is down, chrome throws “NET::ERR_CERT_AUTHORITY_INVALID” and WebDAV kicks me out. I’m positive this is happening because my machine doesn’t have the ability to check if the Let’s Encrypt cert set up by Caddy reverse proxy is valid or not.

I’m pretty sure the DNS isn’t the issue here: the domain name is correctly translated to the correct ip.

7

Ok, here is my solution.

I’ve added the ability to reach nextcloud from 2 separate domains: “cloud.mydomain.com” and “cloud.local”.

Users will always use “cloud.mydomain.com”, but they will fallback to “cloud.local” when the Internet connection is down. The “cloud.local” will work only if nextcloud server is in the same LAN of the clients (of course).

Step 1: make it possible for the client(s) to correctly translate “cloud.local” to the IP of the local server.

You can follow these instructions GitHub - nextcloud/all-in-one: Nextcloud AIO stands for Nextcloud All In One and provides easy deployment and maintenance with most features included in this one Nextcloud instance. or simply add an entry in your local hosts file (C:\Windows\System32\drivers\etc\hosts for Windows machines).

Step 2: add an extra domain in your reverse proxy with a self signed certificate.

In my case I went from this Caddyfile:

https://cloud.mydomain.com:443 {
        reverse_proxy localhost:11000
}

To this Caddyfile:

https://cloud.mydomain.com:443 {
        reverse_proxy localhost:11000
}
https://cloud.local:443 {
        tls internal
        reverse_proxy localhost:11000
}

Step 3: add the new local domain to the trusted nextcloud domains.

Simply run:

docker exec --user www-data -it nextcloud-aio-nextcloud php occ config:system:set trusted_domains 2 --value=cloud.local

Caveats:

  • if you try to access nextcloud trough “cloud.local”, chrome will complain about security;
  • webDAV trough “cloud.local” doesn’t work (sort of, if you tinker a bit perhaps you can download and add the self signed certificate. Input welcome);
  • the main domain “cloud.mydomain.com” appears here and there in the web client.

I hope it helps.

8

The translation source and failing HTTPS are going to be unrelated issues triggered by the same event (loss of internet connectivity).

Loss of upstream connectivity would not directly impact HTTPS under normal circumstances.

It’s not the same thing at all, but both should work. The difference is running split-horizon DNS is a professional working solution, and editing the hosts file is just putting a bandaid on the problem.

Is Caddy providing the intermediate certificate? If so then it should still be able to verify it without internet access.

Is it the IP of Nextcloud or Caddy?

I would discourage this as a solution because it will probably come with other unintended consequences later, such as problems with sync clients. It would be better to find out why your cert won’t verify.

2 Likes