[Solved] Nextcloud 19 snap installed but not online

I am using a Raspberry Pi 4 with 8gb of ram. Running Ubuntu 20.04 LTS arm64.

I had no issue installing Nextcloud via snap and I am able to access and login to my server from my local network by simply typing the the IP address of my host machine.
My issue is that when I try to access Nextcloud from the internet (external IP and configured dns) I get no response. I have forwarded ports 80 and 443 on my router and still the problem persists. I am able to access both my ssh and vpn server from the internet so I know there must be something i’m missing.

I also ran the command "sudo ufw allow 80,443/tcp but it didn’t seem to help.

Any insight would be greatly appreciated and if there is additional information I can provide please let me know.

Some ISPs sadly block those ports. Any chance you fall into that category? Your being able to SSH into your server but not visit ports 80/443 makes me think maybe so. You can change the ports used by the snap, but then you can’t use the built-in Let’s Encrypt integration (which requires port 80), so that’s not awesome.

This was the issue. I was able to redirect the port on my router to 81 and keep the Nextcloud snap on port 80 to get it working.
I contacted my ISP, but they said that they can’t/won’t change the port. Is there any way I can secure with lets encrypt or another service? Surely there is a way people can secure services on other ports as well…

Change your provider.

Is that really the only option?
surely there is a more practical solution…

No, that’s not the only option, don’t worry. That is pretty annoying though, I’m sorry. The solutions are not great either, I’m afraid.

  1. The easy solution: use self-signed certificates instead of Let’s Encrypt (sudo nextcloud.setup-https self-signed). You’ll get browser warnings, but you can use non-standard ports this way and it will still be encrypted.

  2. The only way to work around this and NOT use non-standard ports (at least, not user-facing) is to use a reverse proxy from somewhere ports 80/443 are NOT blocked (e.g. Amazon AWS, DigitalOcean, etc.). Terminate SSL there using Let’s Encrypt on your own, and proxy back to your local Nextcloud install (on ports 81/444) with a self-signed cert. You’ll need to trust it on the proxy end.

This said, given that your ISP is blocking these ports, it seems they explicitly do not want you hosting web applications. It’s entirely possible you’ll be breaking your contract by doing this.

Thank you for the thoughtful replies :slightly_smiling_face:
Are the browser warnings the only downside to using self signed signatures? I was under the impression that it was a compromise to security, though I will fully admit I’m still learning these things.

I will also look into the reverse proxy solution…

If I a understanding correctly, I cannot use the same digital ocean instance for providing reverse proxy to multiple home servers from different IP addresses?

I really hope these sort of issues can have more solutions when it comes to decentralization. I want to get my entire town on Self hosted Nextcloud servers and other rights respecting software.

Hey, that’s why I’m here :slight_smile: .

HTTPS certificates operate using the concept of a chain of trust. For example, Facebook talks to a entity called a Certificate Authority (CA). Specifically, they talk to DigiCert, but there are lots of CAs. CAs are responsible for verifying that a particular entity actually controls a given domain. So DigiCert goes through a process to verify that Facebook actually owns facebook.com, and then hands them a certificate that they signed (we’re talking crytographic signatures here, not something that can be faked). When you visit facebook.com, your browser looks at who signed the certificate, and says “Okay yeah, I trust DigiCert to actually verify that Facebook owns facebook.com and everything is on the up and up.” Then you don’t see a warning.

This is good, because consider the following scenario. I’m on the same network as you. I fool your computer into thinking that I’m the gateway instead of the ACTUAL gateway (this is called a man-in-the-middle attack). You then try to visit facebook.com, but you’re actually talking to me, and I’m talking to facebook.com for you. I create a certificate of my own for facebook.com and hand it to you, which means your traffic will still be encrypted, but I can decrypt it before sending it onto facebook.com for you, thereby allowing me to read all your passwords. There’s one big flaw in this attack: I won’t be able to convince any legit CAs (i.e. CAs that are trusted by Firefox) that I actually own facebook.com, so I’m going to have to hand you a certificate that is signed by someone else (probably just me, i.e. a “self-signed” certificate). Well, Firefox doesn’t trust me, so it shows you the big “HEY this is untrusted, you sure you want to do this?” You don’t typically see that when visiting facebook.com, so you should definitely click the “get me the heck outta here” button. In some cases due to other security features you may not even have the option to continue anyway, but that’s not important for this discussion.

For that type of scenario, browsers do a good job of terrifying people away from self-signed certificates, and I think you’ll agree it’s for good reason. If you think you’re visiting a legit website and you see a certificate warning, you should run the other way.

That all said, there’s nothing inherently wrong or unsafe with self-signed certificates. They can be abused, yes, but it’s all about the chain of trust. If you’re using a self-signed certificate (or any certificate for that matter that is not signed by a trusted CA), you trust yourself. Tell your browser “Hey, I trust this CA.” And voila, no security downside. Everything is encrypted properly, it’s just about trust.

Does that clear things up a little?

Your DigitalOcean droplet will probably only have one IP address. However, you can create as many domains names as you want pointing to that same IP address, and you can proxy by domain name to as many backends as you want.

Okay I feel better about using a self signed certificate now. I mostly just want the security and also the features that are disabled without https like nextcloud talk.

I used the command:
sudo nextcloud.enable-https self-signed

This seemed to successfully generate a certificate. However before self-signing I was able to go to mynextcloudurl:81 to access my server from the web. After signing however, the only way I can access my server is through the local IP.

Since my original quest was answered here I am asking this follow up question here: